Automation Policies

Overview

An Automation Policy is a reusable set of rules that sits between the agent’s intent and actual execution. When an agent attempts an action — navigate to a URL, type text into a form, download a file — the policy enforcement layer checks it against your rules in real-time and either allows it, blocks it, or pauses the session for human approval. Policies are created and managed in the dashboard. You attach them to sessions by passing policyId when starting a session or task.

How It Works

Every action the agent attempts passes through the policy enforcement layer:

Agent produces an action (click, type, navigate, download, etc.)
All matching rules are evaluated
The most restrictive outcome wins:
- Block — action is silently prevented, agent is told to find an alternative, session continues
- Guardrail — session pauses, you review and approve/reject (uses the same guardrail mechanism you already handle)
- Allow — action executes normally

Precedence: Block > Guardrail > Allow. If any rule says block, the action is blocked — even if other rules allow it.

Creating a Policy

Policies are created in the dashboard at Policies → New Policy.

Give the policy a name and optional description
Optionally set an LLM Role to guide agent behavior (see LLM Role below)
Add rules across Domain Rules and Action Rules (see Rule Types below)
Save as Active (ready to use) or Draft (work in progress)

Policies are reusable. Create once, attach to any number of sessions.

Attaching a Policy to a Session

Pass policyId as a top-level parameter when starting a session — the same level as environmentId.

REST API

curl -X POST https://connect.webrun.ai/start/start-session \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "environmentId": "683a1f2e4b0c1d2e3f4a5b6c",
    "policyId": "pol_xyz789",
    "initialTask": {
      "taskDetails": "Extract the latest invoice from the vendor portal",
      "startingPoint": "https://vendor.example.com"
    }
  }'

MCP

The policyId field is available on create_session and browser_task.

Playground

Select a policy from the dropdown in the session configuration panel, alongside the environment selector. A policy summary shows which rules are active before you start.

A session can have a policy, an environment, both, or neither.

Rule Types

A policy contains an optional LLM Role plus one or more rule groups. You can combine Domain Rules and Action Rules in a single policy.

LLM Role

Free-text instructions injected into the agent’s system prompt when the policy is active. Use this to shape the agent’s overall behavior — for example:

“You are a research assistant. Only browse educational sites. Never fill out forms.”

LLM Role accepts up to 2,000 characters and is applied before any rule evaluation. It complements rules by giving the agent behavioral context rather than hard enforcement.

Domain Rules

Control which websites the agent can visit. Three modes:

Mode	Behavior
Allow All (default)	Agent can visit any domain unless explicitly blocked
Allowlist	Agent can only visit domains you list — everything else is blocked
Blocklist	Agent can visit everything except domains you list

Each domain entry specifies a pattern and an action (block or guardrail). Pattern matching:

Pattern	Matches	Doesn’t Match
`example.com`	`example.com`	`sub.example.com`
`*.example.com`	`sub.example.com`, `deep.sub.example.com`	`example.com` itself
`*example.com`	`example.com`, `sub.example.com`, `badexample.com`	`other.com`

Action Rules

Permit, block, or guardrail entire categories of agent behavior. Action Rules now also cover URL pattern matching (for Navigation) and regex-based data sensitivity detection. How a rule is configured depends on its category:

Navigation category: shows a URL Pattern field instead of scope/match options. Use glob-style patterns to target specific paths (e.g., */admin/*, */checkout*). This replaces the need for standalone URL pattern rules.
All other categories: show Scope (All, Target, or Page), Match Type (Keyword or Regex), and Match fields. Use Regex match type to detect sensitive data patterns like credit card numbers, SSNs, or API keys.

Category	Details	Permission
Navigation	`/admin/`	🚫 Block
Type / Keyboard	Regex: `\b\d{3}-\d{2}-\d{4}\b` (All)	🚫 Block
Shell Command	All	🚫 Block
Click	Keyword: “delete” (Target)	⚠️ Guardrail

Scope controls where the match is checked:

Scope	What it checks
All	All available context for the action
Target	The element or value the agent is directly interacting with
Page	Visible content on the current page

Action categories and their WebRun actions:

Category	WebRun Actions
Navigation	navigateUrl, goBack, goForward, pageRefresh
Click	CLICK, DOUBLE_CLICK, MOUSE_DOWN, MOUSE_UP
Type / Keyboard	TYPE, KEY_PRESS, COPY
File Download	File transfer events (download)
File Upload	File transfer events (upload)
Form Submit	KEY_PRESS with Enter on form elements
Screenshot	captureScreenshot
Shell Command	Shell/terminal execution
Clipboard	selectAll + copy, paste operations
Tab Management	newTab, setActiveTab, closeTab
Scroll	SCROLL
Mouse Move	MOVE_MOUSE

Each category can be set to allow, block, or guardrail. You also set a default action for any category not explicitly listed. Example: a read-only research agent might block navigation to */admin/*, block typing with a regex for credit card numbers, block all file uploads, and guardrail clicks matching “delete”.

URL patterns in Navigation rules replace the need for standalone URL pattern rules. To allow a domain but block specific paths (e.g., allow salesforce.com but block salesforce.com/admin/*), add a Navigation action rule with the pattern */admin/* set to Block.

Enforcement Outcomes

Block

The action is silently prevented. The agent receives a message that the action was blocked by policy and is told to find an alternative. The session continues — only the specific action is stopped. Blocked actions are logged to the audit trail. When to use: Hard security boundaries — never access competitor sites, never type SSNs, never execute shell commands.

Guardrail

The session pauses and you’re prompted to approve, reject, or take over. This uses the same guardrail mechanism as credential prompts and CAPTCHAs — handle it the same way in your integration. When to use: Sensitive but legitimate operations — logging into financial sites, actions that need human judgment, workflows where occasional manual review is expected. See Handling Guardrails for integration details on detecting and responding to guardrails via REST, WebSocket, and MCP.

Policy Templates

Pre-built policy templates are available in the dashboard as starting points. Select a template when creating a new policy, then customize.

Research Only

Read-only browsing. Blocks typing, file uploads, shell commands. Guardrails on form submits. Action rules with regex matching for sensitive data patterns (credit cards, SSNs, API keys). Navigation action rules blocking */admin/* and */settings/*.

Financial Compliance

Guardrails on banking and payment domains. Action rules block typing keywords transfer funds and wire transfer. Navigation action rules with guardrails on checkout pages. Action rules with regex matching to block sensitive data extraction.

Healthcare / HIPAA

Allowlist mode (only approved medical portals). Action rules with regex matching to block SSN patterns. Action rules guardrail on medical term keywords and patient pages. Blocks file uploads, guardrails on screenshots. Action rules with regex matching for medical record number patterns.

Strict Lockdown

Allowlist mode with explicit domains only. Guardrails on all typed text. Blocks shell commands and file uploads. Navigation action rules blocking all admin, delete, and settings paths. Action rules with regex matching for all sensitive data patterns.

Audit Trail

Every enforcement decision is logged with:

Timestamp
Action the agent attempted
Rule that matched
Decision (allow, block, or guardrail)
Your response (if guardrail)
Session ID and Policy ID

The audit trail is immutable and exportable for compliance reporting.

Guardrails

Human-in-the-loop mechanism used by guardrail enforcement

Handling Guardrails

Integration guide for detecting and responding to guardrails

Environments

Persistent browser profiles, files, and credentials

Sessions

Session lifecycle and configuration

Secrets

Provide credentials upfront to avoid guardrail interruptions

Parameters Reference

Complete API parameter reference including policyId

Getting Started

Concepts

Usage Guides

Integrations

Environments

API Reference

Capabilities

Troubleshooting

Overview

How It Works

Creating a Policy

Attaching a Policy to a Session

REST API

MCP

Playground

Rule Types

LLM Role

Domain Rules

Action Rules

Enforcement Outcomes

Block

Guardrail

Policy Templates

Audit Trail

Guardrails

Handling Guardrails

Environments

Sessions

Secrets

Parameters Reference

Getting Started

Concepts

Usage Guides

Integrations

Environments

API Reference

Capabilities

Troubleshooting

​Overview

​How It Works

​Creating a Policy

​Attaching a Policy to a Session

​REST API

​MCP

​Playground

​Rule Types

​LLM Role

​Domain Rules

​Action Rules

​Enforcement Outcomes

​Block

​Guardrail

​Policy Templates

​Audit Trail

​Related

Guardrails

Handling Guardrails

Environments

Sessions

Secrets

Parameters Reference

Overview

How It Works

Creating a Policy

Attaching a Policy to a Session

REST API

MCP

Playground

Rule Types

LLM Role

Domain Rules

Action Rules

Enforcement Outcomes

Block

Guardrail

Policy Templates

Audit Trail

Related