Agent Sandboxes: How to Let AI Use Computers Without Trusting It Too Much

Computer-use agents are one of the clearest signs that AI has moved from answering questions to operating software.

They can click buttons, read screens, use browsers, fill forms, inspect dashboards, and work through awkward systems that never had a clean API. That is useful. It is also exactly why they need tight boundaries.

An agent with a browser is not just a chatbot with better UX. It is software that can encounter malicious webpages, hidden instructions, confusing modals, stale sessions, sensitive data, and irreversible actions. OpenAI's computer-using agent work and Anthropic's computer-use documentation both emphasize the same broad lesson: when agents interact with the digital world, isolation and safeguards matter.

The practical answer is the agent sandbox.

TL;DR

Do not let computer-use agents operate on a normal employee desktop. Run them in isolated environments with scoped accounts, disposable sessions, network controls, action gates, screen recording, and explicit human approval for sensitive steps. Treat every webpage and document as untrusted input.

Why computer use is different from API use

API tools are structured. They have schemas, auth scopes, predictable inputs, and clear success or failure responses.

Computer use is messier.

The agent sees pixels, DOM fragments, PDFs, emails, screenshots, menus, ads, popups, and layout changes. It may have to infer state from what is visible. It may also read instructions that were never meant to be trusted, such as webpage text that says "ignore previous directions."

That makes prompt injection more dangerous because the agent is not just reading content. It is acting in the same environment where the content appears.

The sandbox exists because the agent will eventually see something hostile or confusing.

What a real sandbox includes

A useful sandbox is more than a virtual machine.

It should include:

• isolated browser or desktop session
• scoped test or delegated account
• no ambient access to employee files
• network allowlists where possible
• clipboard controls
• download restrictions
• screen and action recording
• resettable state
• policy checks before sensitive actions

The goal is not to make failure impossible. The goal is to make failure contained, visible, and reversible.

Use disposable sessions by default

Persistent browser sessions are convenient. They are also risky.

If an agent keeps cookies, login state, downloads, or local storage between tasks, one workflow can contaminate another. That is especially dangerous in multi-tenant or customer-facing systems.

Prefer disposable sessions:

• fresh browser profile per task
• scoped login
• short lifetime
• clean teardown
• artifact export only through approved channels

If a workflow needs persistence, make that persistence explicit and narrow. Do not let it emerge accidentally because the browser profile never resets.

Separate viewing from acting

The most important design pattern is separating read actions from write actions.

Let the agent browse, inspect, summarize, and prepare. Then gate actions that change state:

• submit form
• send email
• place order
• delete record
• approve request
• change permission
• publish content

This gate can be policy-based for low-risk actions and human-approved for high-risk actions.

The agent should produce an action preview before execution:

• what it will do
• where it will do it
• what evidence supports it
• what could go wrong
• whether the action is reversible

That preview is often the difference between useful autonomy and expensive surprise.

Treat the web as hostile input

Computer-use agents read the web in order to act on it. That is the prompt-injection danger zone.

A malicious page can include instructions aimed at the agent rather than the human. A PDF can hide text. A support ticket can contain instructions that look like user intent. A website can nudge an agent into a higher-priced option.

Mitigations should include:

• instruction hierarchy in the agent runtime
• webpage content treated as data, not authority
• domain allowlists for sensitive workflows
• browser isolation from internal systems
• confirmation before credential entry
• policy filters before form submission

No mitigation is perfect. Layer them.

OpenAI's Computer-Using Agent announcement and Anthropic's computer use tool documentation are useful official references on the risk surface.

Log the screen, not just the prompt

For normal tool calls, structured logs can be enough. For computer-use agents, you need visual evidence.

Capture:

• screenshots at important steps
• DOM snapshots where available
• action coordinates or selectors
• page URLs
• form data before submission
• downloaded artifact hashes
• policy decisions
• human approvals

If the agent clicked the wrong thing, you need to see what it saw. A text trace alone will not explain a misread button, hidden modal, or stale page.

Build for rollback

Some computer-use tasks will fail after partially completing.

Design rollback paths:

• drafts instead of sends
• staging environments before production
• reversible changes where possible
• confirmation pages captured before final action
• idempotency keys for repeated submissions
• post-action verification

The agent should not assume success because it clicked a button. It should verify that the intended state changed.

When not to use computer use

Computer use is often a workaround for missing APIs. Sometimes that is appropriate. Sometimes it is technical debt in disguise.

Avoid computer-use agents when:

• a stable API exists
• actions are high-risk and hard to verify
• the UI changes constantly
• the workflow requires broad sensitive access
• the task can be solved with a narrow tool

The best computer-use agent is sometimes the one you replace with a real integration.

Summary

Computer-use agents are useful because they can work through messy software the way humans do. They are risky for the same reason.

Use sandboxes, scoped sessions, action gates, visual logs, and rollback paths. Treat every page as untrusted input. Let agents use computers, but do not hand them your normal desktop and hope policy text saves you.