Browser Sandboxes for Computer-Use Agents
The short version
A production browser sandbox needs more than an incognito-style browser context. Give each agent an isolated execution environment, scoped and short-lived credentials, explicit network policy, controlled storage, action limits, approval gates, and a complete audit trail. Treat every page as untrusted input, and destroy or reset the environment when the task ends.
The important distinction is this: a browser context isolates web session data, while a container or virtual machine constrains what the browser process can reach. You usually need both.
Why computer-use agents need a stronger boundary
A browser automation script follows instructions written by a developer. A computer-use agent chooses actions after interpreting screenshots, page text, forms, emails, and documents. That puts untrusted web content inside the decision loop.
A malicious page does not need a browser escape to cause damage. An instruction hidden in a page can persuade an agent to reveal information through an allowed form, navigate to a phishing site, or take an action the user never requested. OWASP lists indirect prompt injection, excessive tool permissions, memory poisoning, and unsafe high-impact actions among the core risks for production agents (OWASP AI Agent Security Cheat Sheet).
Both OpenAI and Anthropic therefore recommend running computer-use systems in isolated environments and keeping humans involved in consequential actions (OpenAI computer-use guide, Anthropic computer-use documentation). Isolation limits the blast radius when the model, the page, or the browser behaves unexpectedly. It does not make the page trustworthy.
If you are new to the underlying runtime model, start with what an AI agent sandbox is before choosing a browser-specific design.
Browser context, container, or VM?
These controls solve different problems. Treating them as interchangeable creates gaps.
| Isolation layer | What it separates | What it does not guarantee |
|---|---|---|
| Browser context | Cookies, local storage, cache, and session state between contexts | Host filesystem, process privileges, network reachability, or protection from agent-level prompt injection |
| Browser and OS process sandbox | Browser components and renderer processes according to the browser and OS security model | A clean tenant boundary, scoped credentials, or task-specific egress policy |
| Container | Processes, mounts, namespaces, resources, and network policy when configured correctly | A separate kernel; unsafe host mounts or privileged mode can weaken the boundary |
| VM or microVM | Guest workloads behind a separate kernel and virtualized devices | Safe credentials, allowed actions, or protection from instructions delivered through a webpage |
Playwright describes browser contexts as isolated, non-persistent sessions and recommends them for separating cookies and storage (Playwright BrowserContext documentation). That is valuable, but it is session isolation—not the whole security boundary for an untrusted workload.
For low-risk testing against public pages, a fresh context inside a locked-down browser process may be enough. For authenticated workflows, arbitrary downloads, multi-tenant execution, or access to internal systems, place the browser inside a properly restricted container or VM as well. This is the same principle behind running untrusted agent workloads as isolated systems, not merely as snippets in a shared process.
The production controls that matter
1. Start with a disposable environment
Create a fresh browser context for every task and a fresh container or VM for every trust boundary. Disable extensions, prevent access to host files, avoid inheriting host environment variables, and set hard limits on CPU, memory, runtime, downloads, and open pages.
Destroying the environment after the task is safer than trying to clean it. Cleanup lists miss browser caches, temporary files, service workers, downloads, and state added by future browser versions.
2. Broker credentials instead of storing them in the browser
Do not place a general-purpose API key, password vault, or production session inside the agent environment. Issue a credential for one identity, one service, one task, and the shortest useful lifetime. Where possible, let a trusted broker perform authentication and inject only the resulting limited session.
Playwright warns that saved authentication state can contain cookies and headers capable of impersonating a user (Playwright authentication guide). Encrypt persistent state, keep it outside the sandbox, scope it per user, and revoke it when the job ends.
3. Make network access an explicit policy
Default-deny egress is the safest starting point for repeatable workflows. Allow only the domains and protocols required for the task, and validate redirects so an allowed site cannot silently send the browser elsewhere. Block access to cloud metadata endpoints, private network ranges, control-plane services, and unrelated internal applications.
Open-web research is harder because a fixed domain allowlist may defeat the task. In that case, separate browsing from authenticated actions: use one low-trust environment to gather information and a second restricted environment to perform approved operations. Do not give the open-web browser the same cookies or network access as the action environment.
4. Put policy outside the model
The model can propose an action; a deterministic policy layer should decide whether it is allowed. Classify actions by impact:
- Read-only navigation and extraction may run automatically within limits.
- Sending messages, uploading files, changing account settings, or submitting forms should require tighter policy checks.
- Purchases, deletions, permission changes, financial transfers, and disclosure of sensitive data should pause for explicit human approval.
Bind an approval to the exact action and parameters shown to the user. Approval to “update the account” should not authorize a later password reset or a different destination. This complements guardrails before production; it cannot be replaced by a stronger system prompt.
5. Record enough evidence to replay a failure
An audit event should identify the agent version, user, task, page origin, proposed action, policy decision, approval, result, and sandbox lifecycle. Capture screenshots or DOM snapshots around consequential actions, but redact secrets and personal data before long-term storage. Network destinations and downloaded-file hashes are often more useful than raw model reasoning.
Logs should answer three questions: what did the agent observe, why was the action permitted, and what changed afterward? That turns an unexpected click into an incident you can investigate rather than an anecdote. See the broader requirements for enterprise AI agent audit trails.
Clean sessions versus persistent browser state
Disposable sessions reduce cross-task leakage, but some workflows genuinely need continuity: a long research job, a multi-step onboarding flow, or a task that waits for another person.
Keep durable task state outside the browser. Store checkpoints, approved artifacts, and minimal encrypted session material in a per-user service. When the task resumes, start a new sandbox and inject only the state required for the next step. Expire it automatically and record every restore.
This separates useful persistence from a long-lived, increasingly contaminated browser profile. The same checkpointing model also enables forking agent state for parallel and resumable execution without reusing one mutable environment forever.
What sandboxing cannot solve
Sandboxing is containment, not intent validation. It cannot reliably detect that a webpage is giving the agent malicious instructions. It cannot decide whether a transfer is legitimate, whether a recipient is correct, or whether a user truly meant to disclose a document.
Likewise, an egress allowlist does not prevent exfiltration to an allowed destination, and a VM does not make an overpowered credential safe. Production defenses must combine isolation with least privilege, input handling, policy enforcement, approvals, monitoring, and recovery.
That distinction matters when evaluating platforms. “Runs in a container” is not a complete answer. Ask how the platform scopes credentials, controls outbound traffic, separates tenants, stores resumable state, records actions, terminates stuck tasks, and rolls back changes.
Production readiness checklist
Before letting a computer-use agent access real accounts, verify that you can answer yes to all of these:
- Does every task run in a clearly defined browser and compute isolation boundary?
- Can the environment reach only the files, services, and networks required for that task?
- Are credentials per-user, least-privilege, short-lived, and revocable?
- Are irreversible or sensitive actions blocked until specifically approved?
- Can you terminate a runaway task automatically by time, cost, action count, or policy violation?
- Is persistent state encrypted, separated by user, and restored into a fresh environment?
- Can an operator reconstruct consequential actions without exposing secrets in logs?
- Can you revoke access, quarantine artifacts, and resume from a known-good checkpoint after an incident?
CreateOS brings isolated runtimes, persistent workloads, deployment, and operational controls into one execution layer. The practical goal is not to promise that an agent can never be manipulated. It is to ensure that one bad page or bad decision cannot quietly become access to everything else.
