Security Hardening Claude Computer & Browser Use

Most AI security advice assumes the model only produces text. Computer use breaks that assumption completely. When you give Claude a screen, a keyboard, and a mouse, you have handed an autonomous system the ability to click buttons, fill forms, run commands, and read whatever is on the display. A clever prompt-injection hidden in a web page no longer just changes what the model says — it can change what the model does. Hardening a browser or computer-use agent is therefore a different discipline than hardening a chatbot, and it borrows more from operating-system security than from prompt engineering. This post lays out the defenses that actually hold up: sandboxing, least privilege, secret hygiene, and injection resistance.

The threat model is different

Start by naming what you are defending against. A computer-use agent reads untrusted content from the open web and then takes real actions in an environment that may contain credentials, internal tools, and sensitive data. The attacker's lever is the content the agent reads: a page, an email, a document, a form field can all carry instructions crafted to hijack the agent. Because the agent acts, the blast radius of a successful injection is whatever the agent is allowed to touch.

This reframes the goal. You cannot make a model immune to being told things — reading attacker text is the job. What you can do is ensure that even a fully hijacked agent can do limited, reversible, observable damage. Security for computer use is mostly about constraining the environment, not perfecting the model. The model is one layer; the sandbox, the permissions, and the action gates are the layers that have to hold when the model is fooled.

Sandbox everything

The first and most important control is isolation. The agent should operate inside a sandbox — a container or virtual machine — that has nothing in it you are not willing to lose. No production credentials sitting in environment variables, no SSH keys, no access to internal networks beyond what the task requires, no mounted volumes containing data the task does not need. If the worst happens and the agent is driven to delete files or exfiltrate data, the sandbox boundary is what limits the damage to a disposable environment.

Treat the sandbox as ephemeral. Spin it up for the task, run the agent, capture the results, and tear it down. A fresh environment per run means a compromise cannot persist across tasks, and it makes the network and filesystem surface small and auditable. Network egress is worth special attention: default-deny outbound, then allow-list only the domains the task legitimately needs, so a hijacked agent cannot phone home or post your data somewhere.

flowchart TD
  A["Untrusted web content"] --> B["Claude reads page"]
  B --> C{"Action requested"}
  C --> D{"Within granted permissions?"}
  D -->|No| E["Block & log"]
  D -->|Yes| F{"Irreversible or sensitive?"}
  F -->|Yes| G["Human / verifier approval"]
  F -->|No| H["Execute in sandbox"]
  G --> H
  H --> I["Egress allow-list checked"]

Least privilege, applied to tools

Sandboxing limits the environment; least privilege limits the agent within it. Every tool you expose is a capability, and the agent has exactly the powers you give it and no more. Audit your tool surface and remove anything the task does not need. If the agent only reads dashboards, it does not need a tool that submits forms. If it processes one customer's records, it should not have a query that returns everyone's.

Push privilege down to the data layer too. Run the agent's actions through credentials scoped to the minimum — read-only where reads suffice, a single tenant where one tenant is the job, time-limited tokens that expire after the run. The principle is that the answer to "what could this agent do if it were fully compromised right now?" should be a short, boring list. Where you cannot avoid a powerful capability, wrap it in a confirmation gate so that the dangerous action requires explicit approval rather than firing autonomously.

Secrets the agent should never see

A recurring mistake is letting credentials flow into the model's context. If an API key or password appears in a screenshot, a prompt, or a tool result, it is now in the conversation, it may be logged, and a prompt-injection can ask the agent to repeat it. The fix is to keep secrets out of the model's hands entirely. The harness, not the model, should hold credentials and inject them at the point of use — the agent says "log in," and the harness performs the authentication without the secret ever entering the model's context.

Apply the same care to outputs. Redact credentials, tokens, and sensitive fields from screenshots before they reach the model where you can, and scrub logs so that your own observability does not become a secret-leak. The mental model: the agent should be able to use capabilities without ever holding the keys to them.

Prompt-injection defense in depth

Prompt injection is the defining attack on computer use, and there is no single fix — defense is layered. At the boundary, separate trusted instructions from untrusted content as clearly as you can, and instruct the model to treat web-page text as data to act on, not commands to obey. Inside the loop, gate consequential actions: any step that sends data outside the sandbox, spends money, or changes state should pass a check that asks whether the agent's stated goal actually requires it. A request to email a file to an unknown address mid-task is a red flag a guard can catch even when the model is convinced.

The most durable defense, though, is the combination of everything above. A hijacked agent inside a locked-down sandbox, holding no secrets, with least-privilege tools, default-deny egress, and approval gates on irreversible actions, simply cannot do much harm even when the injection succeeds. That is the goal — not an unfoolable model, but a system where a fooled model is contained. Defense in depth for agents means assuming the model will be tricked and ensuring the environment, permissions, and gates absorb the blow.

Frequently asked questions

What is the biggest security risk in Claude computer use?

Prompt injection from untrusted content the agent reads. Because a computer-use agent takes real actions, a malicious instruction hidden in a web page or document can drive the agent to do harm, not just say something wrong. The blast radius is whatever the agent is permitted to touch.

How do I keep API keys away from the agent?

Hold credentials in the harness, not the model. Inject them at the point of use so the agent can trigger an authenticated action without the secret ever entering its context, and redact credentials from screenshots and logs so a hijacked agent cannot repeat them.

Can prompt injection be fully prevented?

No. Reading untrusted text is the agent's job, so you cannot make the model immune. Instead, contain the damage: sandbox the agent, give it least-privilege tools, deny egress by default, keep secrets out of context, and gate irreversible actions so a fooled model still cannot do much.

Why run browser agents in a disposable sandbox?

Because it bounds the worst case. An ephemeral container or VM with no production credentials, no internal network access, and an egress allow-list means a compromise is limited to a throwaway environment and cannot persist across runs.

Hardened agents, on the phone and the page

The same containment mindset — least privilege, secrets the agent never holds, and approval gates on risky actions — is what lets a voice agent take real actions on a live call without exposing your systems. CallSphere builds its voice and chat assistants with exactly these guardrails so they can act safely while they handle every call and message. See the approach at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.