Safety controls for browser-automating agents

Prerequisites

Before starting, define one bounded browser task and identify the person who can approve consequential actions. The control layer must be able to inspect every requested navigation, download, element interaction, and credential request before passing it to the browser. A prompt alone is not that control layer.

Choose an automation interface that exposes the state needed for enforcement. The W3C WebDriver Working Draft dated 2 July 2026 defines remote commands for navigation, window and frame selection, element lookup, clicks, text entry, cookies, scripts, prompts, and screenshots. Those commands form useful enforcement points whether the implementation uses WebDriver directly or maps equivalent browser operations through another library.

Implement the controls in execution order

1. Write the task contract before creating a browser session.

   Convert the request into constraints that code can check:

   • the starting origin;
   • every origin the task may visit;
   • whether cross-origin navigation is allowed at all;
   • whether downloads are prohibited or restricted to named file types and destinations;
   • which operations are read-only, preparatory, or consequential;
   • which identity and credentials the session may use;
   • which actions require confirmation;
   • what observation must stop the run.

   Keep this contract outside model context and pass it to the browser controller when the session is created. The model may propose actions within the contract, but it may not add an origin, enable downloads, widen credentials, or remove a confirmation requirement.

   The mechanism is simple: policy becomes input to the executor rather than advice to the model. Each tool call is accepted or rejected against the same contract, even after a long sequence of browser observations.

   The cost is task-specific configuration. A broad research task may need more allowed origins than an order-status lookup, and an allowlist that is too narrow will stop legitimate work. That interruption is preferable to silently expanding scope. If destinations cannot be named in advance, define a separate approval path for adding one; do not turn an unknown destination into an implicit wildcard.

   Use a more detailed agent tool permission model when the same agent can act through APIs, a shell, or other tools as well as a browser. The browser contract should be one enforceable part of that larger permission set.

2. Classify everything rendered by the page as untrusted input.

   Browser content is untrusted even when it appears visually inside a trusted application. A page, embedded document, message, advertisement, user profile, search result, or accessibility label can contain instructions aimed at the agent. The application frame does not turn remote content into policy.

   This is the browser form of prompt injection. The OWASP Top 10 project page, checked 26 August 2026 identifies prompt injection as crafted input that can manipulate a model and excessive agency as unchecked autonomy that can produce unintended consequences. A browser agent combines both risks when it reads attacker-controlled text and can immediately click, type, download, or submit in response.

   Represent browser output as observations, not commands. The page may supply a product name, form label, destination, price, or status that the agent needs to interpret. It may not redefine the task, ask the agent to ignore policy, request a secret, grant itself another origin, or declare that confirmation is unnecessary. Instructions from the operator and enforcement rules from the controller stay authoritative.

   Do not try to solve this by asking the model to detect malicious prose perfectly. Detection can help explain why a run stopped, but the safety boundary is the executor refusing actions outside the task contract. A page saying that another domain is required still meets the origin gate. A page claiming that a credential is safe to reveal still meets the credential gate.

   This separation costs context and implementation work: the model needs enough page data to complete the task, while the controller needs structured action proposals it can inspect. It is the wrong place to optimize by concatenating policy, page text, and tool results into one undifferentiated prompt.

3. Enforce origins and download rules before the browser starts.

   Configure navigation allowlists in the browser controller, proxy, or equivalent network boundary before launching the session. Match origins, not fragments of visible URLs: scheme, host, and port together decide whether a destination is allowed. Apply the check to the initial page and every later navigation request. A model remembering that it should stay on one site is not enforcement.

   Make the default outcome a denied navigation. If an allowed page points elsewhere, stop at the boundary and present the proposed destination for a policy decision. Do not let the model visit the new origin first and decide afterward whether the visit was acceptable; by then the browser has already made the request.

   Downloads need their own preflight rule because allowing an origin does not mean accepting every file it offers. For a task that does not require a file, disable downloads. For a task that does, constrain the permitted source origin and destination before launch, then require the controller to reject anything outside that declaration. Opening or processing a downloaded file is a separate capability and should not be inferred from permission to fetch it.

   The cost is reduced flexibility. Federated sign-in, payment pages, content delivery hosts, and vendor redirects may require more than one origin. Add only the origins required by the actual flow, and record why each one exists. A wildcard is the wrong answer when the task can be expressed with a finite set. If the destination genuinely cannot be known beforehand, pause for an explicit extension to the contract.

   Test this boundary without the model: request a permitted origin, a non-permitted origin, and a download that violates policy. The controller should make the same decision for each attempt regardless of the surrounding page text.

4. Select the least capable browser mode that can finish the task.

   Do not create an interactive browser agent for a fixed extraction when a bounded fetch, screenshot, or structured scrape is enough. Fewer available commands mean fewer consequential proposals that the controller must judge.

   Cloudflare’s Browser Run overview, last updated 11 August 2026, distinguishes stateless Quick Actions for outputs such as HTML, screenshots, PDFs, Markdown, links, and scraped elements from browser sessions controlled through Playwright, Puppeteer, or the Chrome DevTools Protocol. It also documents browser control for agent workflows. This is a choice of mechanism, not a safety guarantee: whichever interface is used still needs the external origin, download, credential, and confirmation gates described here.

   Choose a stateless operation when the task has one known input and one non-consequential output. Choose a controllable session only when the task requires navigation or interaction across multiple states. The session costs more policy work because it can accumulate authentication state, follow links, open contexts, and submit actions.

   An agent is the wrong answer when a deterministic script can identify every page and action in advance. Keep the model for interpretation or recovery only where fixed selectors and explicit branching cannot express the task.

5. Create a session with only the identity and secrets it needs.

   Start with a fresh browser context for the bounded task. Do not reuse a general-purpose human profile merely because it is already signed in. Decide which origin may receive each credential and expose no unrelated credentials to the session.

   Keep secret retrieval outside page content and model reasoning. If the agent reaches a login form, it may report the form and request the approved credential operation. The controller should decide whether the current origin and task permit that operation. Credential entry remains a consequential action requiring explicit confirmation at the last reversible step; being on an allowed origin does not remove that requirement.

   Define where secrets live and how they enter the session using the same discipline applied to credentials issued to an agent. The page should never be treated as the authority that selects or requests a secret.

   The cost is more sign-ins and narrower sessions. The wrong answer is broad ambient authentication: it makes every allowed click capable of reaching whatever the reused profile can reach, rather than what this task was authorized to do.

6. Split every workflow into preparation and commitment.

   Let the agent navigate, read, select candidates, and fill a proposed action object without committing it. The object should contain the current origin, intended operation, target, and the values about to be submitted. The executor then classifies the proposal against the task contract.

   This split creates a stable point where policy and human review can operate. For example, an agent may prepare a message body without sending it, identify an item without purchasing it, select a record without deleting it, or identify a credential field without typing into it. The browser remains short of the side effect while the proposed action is checked.

   Do not give the model one generic browser tool that both prepares and commits an action invisibly. Expose the consequential operation as a separate executor command. A model-generated claim that an operation is harmless must not change its classification.

   The cost is an additional state transition and the chance that the page changes between preparation and commitment. Address that by reading the relevant state again immediately before execution. Preparation is the wrong place for confirmation if further agent-controlled choices can change the target, value, recipient, or credential afterward.

7. Ask for confirmation at the last reversible step.

   Purchases, messages, deletions, and credential entry need explicit confirmation immediately before the operation crosses from preparation into execution. Earlier approval of the overall task is not enough. The confirmation must occur after the agent has chosen the exact action but before the browser performs it.

   Proposed operation	Agent may prepare	Confirmation gates
   Purchase	Select the item and prepare the order	The final action that places the order
   Message	Draft content and choose the recipient	The action that sends or publishes it
   Deletion	Locate and select the target	The action that confirms deletion
   Credential entry	Locate the approved sign-in form	Typing or submitting the credential

   Show the reviewer the concrete proposal, not a generic question about continuing. The purchase prompt needs the selected order information visible to the reviewer. The message prompt needs its recipient and body. The deletion prompt needs the exact target. The credential prompt needs the destination origin and the credential identity without exposing the secret value.

   Treat approval as authorization for that proposal only. If the recipient, target, destination origin, or submitted values change, discard the approval and ask again. Do not let an approval token authorize later actions of the same broad type.

   Just before executing the approved action, compare the current browser state with the state that was reviewed. If it no longer represents the same proposal, stop rather than adapting silently. This is why confirmation belongs at the last reversible step: placing it earlier leaves room for unreviewed browser or agent decisions between approval and effect.

   Confirmation costs human attention and makes unattended completion impossible for these operations. That is the intended trade. It is the wrong control for ordinary reading, navigation within the allowlist, or preparation that creates no external effect; asking on every click trains the workflow to treat consequential and routine actions alike.

8. Validate the observed state and stop safely on ambiguity.

   Before each action, verify the current origin, active browser context, target element, and proposed operation against the contract. After a non-consequential action, inspect the resulting URL or document state before allowing the next proposal. After an approved consequential action, record the resulting visible state without repeating the operation merely because the result is unclear.

   Browser observations are also untrusted tool results. Validate their structure before returning them to model context, following the same boundary used for agent tool result validation. A page-derived success message may be evidence to show the operator, but it must not grant new permissions or trigger another consequential action.

   Put a finite admission boundary around concurrent work. Two runs using the same identity can otherwise prepare actions against different observed states. Route excess work through backpressure and queue admission rather than widening browser concurrency without revisiting the task contract and confirmation path.

   Stop when the current origin is not allowed, a download violates policy, page content asks for a capability outside the contract, the proposed action differs from the approved one, or the result of a consequential action is ambiguous. Return the observed state and the rejected proposal for review. Automatic retry is the wrong answer when it could repeat a purchase, message, deletion, or credential submission.

Expected result

Done means the browser cannot navigate outside its configured origins or accept an undeclared download merely because page text or the model requests it. Browser content remains data, not policy. Purchases, messages, deletions, and credential entry stop at a concrete last-step confirmation, and any changed or ambiguous state ends the run without silently widening authority or repeating the action.