Computer use and browser agents: injection at the width of the web

Rule 1 · A fresh, isolated browser profile every session

No developer profile. No extensions. No saved passwords, no autofill, no history, no bookmark bar full of internal tools. The profile is created for the session and destroyed with it, inside an ephemeral environment.

Why it is rule one: a browser profile is a bundle of ambient credentials — cookies for every SaaS product the owner uses, refresh tokens, SSO sessions. Handing an agent an existing profile is the browser version of injecting production keys into the sandbox, except worse, because nobody can enumerate what is in there.

Persisted authenticated profiles are a real feature with real uses (long-running workflows on one site that will not accept programmatic login). If you use one, pin it to a single allowlisted domain, keep untrusted browsing out of that session entirely, and treat it as a stored secret with rotation and an owner.

Rule 2 · Never a real human’s logged-in session

The tempting shortcut is to let the agent drive a browser already logged in as the employee. That grants the agent the union of everything that employee can reach — mail, HR, admin consoles — and destroys attribution: the audit logs of every downstream system now say the human did it.

Instead: a dedicated automation identity, provisioned per workflow, with the narrowest possible entitlements on the target system. Credentials come from a vault at the moment of use, never from the profile store. And if the target site cannot express a low-privilege role, that is a finding — write it down and gate the workflow behind a human rather than pretending the risk away.

Rule 3 · Domain allowlist, and egress control around the browser

The agent visits the sites the task requires and nothing else. Enforce it at the network layer as well as in the prompt — a browser is a general-purpose HTTP client with a rendering engine, and a page can initiate requests the agent never chose.

An allowlist does double duty: it cuts the injection surface and it cuts the exfiltration channel, because a rendered image or a background fetch can only reach approved hosts. ForcedLeak is the cautionary tale on the exfil side — Noma Labs reported on 2025-09-25 that Salesforce Agentforce could be made to leak CRM data through an expired domain still sitting on the CSP allowlist. Allowlists need owners and expiry checks, or they rot into open doors.

Rule 4 · A human can watch, take over, and stop it

Live streaming, session recording, and a kill switch that terminates the session mid-action. For consequential steps — the submit, the send, the purchase, the delete — an approval gate that shows the human the actual screen state, not a summary the model wrote.

This is where computer use differs from a scoped tool: you cannot describe the pending action in a schema, so the review has to be visual. Design for the reviewer to be able to say no in a few seconds, and remember the human-in-the-loop failure mode from foundations — a gate that always says yes has already become full autonomy.

Rule 5 · Fix the plan’s targets before the browsing starts

Decide outside the agent what the irreversible parameters are — which recipient, which amount, which record — and enforce them in the runtime. Then no amount of page text can retarget the action, because the target was never the model’s to choose after reading the web.

This is the structural answer to “the page told the agent to do something else.” You cannot filter your way out of injection, so remove the decision from the injectable path. The same instinct as Meta’s Agents Rule of Two (2025-10-31): if a session processes untrusted input, touches sensitive data, and can change state or communicate externally, it should not run autonomously — it needs human supervision or another dependable validation mechanism.