Browser agent safety: design the boundary before the click
Define account access, permitted destinations, action approvals and recovery evidence for a browser agent before allowing it to change real systems.
A browser agent can encounter instructions inside the pages it reads and controls inside an account it can use. Plan the account, destination and action boundaries together. This source-reviewed guide proposes a staged workflow for a fictional supplier-portal assistant; it is not a penetration test or a claim that browser automation can eliminate all risk.
Separate viewing, preparing and committing
Our sample assistant collects availability from an approved supplier portal and prepares a replenishment draft. Reading availability, entering draft quantities and submitting an order are separate permissions. Define them before granting account access. A task that only needs a report should not inherit a purchasing account's full authority.
Write a compact job record: the approved supplier account, allowed product list, requested date range, destination for the report and actions requiring review. If the page asks for a new account, a changed payment method or a different delivery address, the job record should make the mismatch visible.
Use a session built for this task
Playwright documents browser contexts that isolate cookies and browser storage between sessions. That is useful session isolation; it does not by itself establish a complete security boundary around a machine or account. Our suggested setup uses a dedicated account and fresh task session with only the access the workflow requires.
Keep personal sessions, unrelated files and unnecessary extensions out of the automation environment. Decide where downloads go and who may open them. If the assistant needs a saved login, record how that session expires and how the operator can revoke it. A successful login is only the beginning of the access review.
Treat page content as evidence, not authorization
OWASP describes indirect prompt injection through material an application retrieves and recommends layered controls, including constrained privileges and review of consequential actions. A supplier page might contain text asking an assistant to change its task or disclose unrelated information. Its presence on the page does not authorize those actions.
For this workflow, our proposed control checks the destination and requested operation before execution. The system should retain the original task boundary when a page, pop-up or downloaded document suggests a different one. Explain the conflict to the operator using the observed page and intended action, rather than asking for vague permission to continue.
Make the review specific enough to be useful
Before a consequential submission, show the supplier, selected items, quantities, delivery details and exact operation awaiting approval. Tie the approval to those values. If the cart changes afterward, obtain a decision on the changed cart. A broad approval at the beginning of a session should not quietly authorize a different final action.
Keep the commit operation separate from exploratory navigation. Where the external service supports it, use a unique operation reference and check the resulting record. If a submit click times out, inspect whether the order exists before retrying. Otherwise a recovery attempt may become another order.
Earn access through a staged trial
Use an account and sample data designed for testing. Our proposed stages make each increase in authority depend on observable behavior, rather than on how convincingly the assistant narrates its progress.
| Stage | Evidence required before expanding access |
|---|---|
| Read and report | Correct account, products, sources and unresolved items |
| Prepare a draft | Correct fields with no external submission |
| Request approval | A complete, stable summary of the pending action |
| Commit an approved action | Matching external record and no duplicate operation |
| Recover a failure | Clear unknown state, safe inspection and controlled retry |
Leave an operator a clear recovery path
Save enough sanitized evidence to investigate a failed task: timestamps, page identity, intended action and the external record identifier when available. Restrict access to screenshots and downloads because they may contain account information. Document how to stop a running task, revoke its session and resume unfinished work manually.
The useful question after a trial is specific: which actions can this assistant perform within this account and workflow, with which review steps? Keep access at that demonstrated level until the next stage has its own evidence.
Sources & further reading
Official sources support the specific product and protocol facts in this guide. The selection process and examples are editorial recommendations, not a claim that we tested the listed tools.
