Where Personal Agents Live: Three Execution Environments, Three Security Trade-offs

Author: Anthropic Engineering Team (A retrospective on their public agent isolation architecture)

Personal agents have been launching in clusters recently: Meta’s Muse (cloud VM), Google’s Gemini Spark (cloud agent), Anthropic’s Claude Cowork (local VM), Apple’s Siri AI (on-screen sensing)… They’re all answering the same question: Where should an agent run?

Anthropic published a very candid retrospective—they built three products, each with a different isolation architecture, and even dedicated a section to “what we missed.” I want to explain these three models clearly because you’ll face the same choices when building your own agent.

First, a Premise: Why Containment Beats Monitoring

The authors open with a number worth remembering:

Previously, Claude Code relied on asking the user for authorization every turn to prevent the agent from doing unintended things. In theory, this could work, but our telemetry showed users approved approximately 93% of permission prompts.

The more approval requests users see, the less attention they pay to each one, and over time they become far less diligent than they were at the start.

They also discovered a subtler pattern:

Our anonymized usage data also shows that experienced users auto-approve roughly twice as frequently as new users, but they also interrupt agent execution more often. Experienced users don’t nitpick every step; they tend to intervene only when the agent goes off-track.

This observation is crucial: it reveals that the real form of “human-in-the-loop” isn’t “step-by-step approval” but “post-hoc correction”—and that requires users to have sufficient technical skill to detect drift.

Another fact that must be acknowledged:

Any probabilistic defense has a non-zero evasion rate.

So their conclusion was:

Design for containment at the environment layer, then guide behavior at the model layer. The two incidents that taught us the most—a phishing attack on employees and a third-party disclosure involving allowlist issues—were both egress problems, where data left via an allowed path. In both cases, the model layer couldn’t help because there was nothing anomalous for it to catch.

When all probabilistic defenses fail, what gets hit is the deterministic boundary.

Three Isolation Models

Model 1: Ephemeral Containers (Code Execution on claude.ai)

When Claude runs code on claude.ai, it executes inside gVisor containers on isolated infrastructure.

• The agent runs entirely server-side
• No code runs on your machine
• The file system is ephemeral (one per session)

The authors’ assessment is blunt:

The blast radius is minimal, but Claude’s capabilities are also minimal—no persistent workspace, no access to the user’s file system.

This brings us to a traditional threat model:

We’re not protecting the user’s machine from the agent; we’re protecting our own infrastructure, as well as tenants from each other.

Then comes the most valuable lesson learned:

That work reinforced security’s oldest lesson: the weakest layer is often the one you built yourself. gVisor and seccomp have been hardened against well-resourced adversaries for far longer than agentic AI has existed, so our review efforts focused on the newer components we built around them.

Model 2: Human-in-the-Loop Sandbox (Claude Code)

Claude Code runs on the user’s machine, with access to the file system, shell, and network. Without these, a coding agent’s utility is limited.

Why they dared use “human-in-the-loop”:

This was a viable approach for Claude Code because its average user is a developer familiar with programming environments: they can read bash, understand what rm -rf does, and already run npm install from untrusted sources several times a week.

This means when the “Allow this?” dialog appears, they’re likely to have the professional ability to assess what the agent wants to do and the associated risks.

But approval fatigue set in within weeks. So they added OS-level sandboxes (Seatbelt on macOS, bubblewrap on Linux):

• Read: Allowed
• Write: Allowed (but only within the workspace)
• Network: Denied by default

Result: Permission prompts reduced by 84%. And they open-sourced the runtime, so the boundaries are auditable.

⚠️ What they missed: Trusting everything before the dialog

Between mid-2025 and January 2026, we received vulnerability reports for Claude Code through our responsible disclosure program. Three of them targeted “code executed before the user agrees to anything.”

Specific scenario:

A developer clones a repository to review a PR, and that repository contains a .claude/settings.json that defines a hook. Because Claude Code reads project settings at startup—and before popping up the standard “Do you trust this folder?” prompt—the attacker-submitted hook executes automatically.

The fix follows the same pattern:

Delay parsing and execution of project local configurations until after the user accepts the trust prompt.

If you’re building something similar, treat “open project,” “load configuration,” and “local listeners” as inbound requests from the internet. They shouldn’t be implicitly trusted just because they feel local and arrive before the user speaks.

Model 3: Local VM (Claude Cowork)

Cowork targets general knowledge workers, not software engineers. The authors point out the key difference here:

A non-technical knowledge worker shouldn’t be expected to judge bash incantations like find . -name "*.tmp" -exec rm {} \;. When approving an exception requires expertise the typical user doesn’t possess, administrators should set an absolute, always-on boundary.

So the first version of Cowork ran inside a full virtual machine (Apple’s Virtualization framework on macOS, HCS on Windows):

• The VM has its own Linux kernel, file system, and process table
• Only the user-selected workspace and .claude folder are mounted; everything else on the host is invisible
• Credentials stay in the host’s keychain and never enter the guest

There’s a design detail here I think is worth learning:

In the original architecture—which we’ll call “full VM mode”—the agent loop itself ran inside the guest, so Claude executed as a normal Linux user, completely unaware it was sandboxed.

Compare this to Claude Code: there, a privileged process sits outside the sandbox, deciding on each command whether to enforce it—a convincing injection prompt or a fatigued approval click could let that process run unsandboxed code.

In Cowork, no outer process holds the key to the escape hatch, so no component has the authority to grant exceptions.

But full VM mode has practical costs: any VM startup failure makes Cowork unavailable. So they later moved the agent loop outside the VM, keeping only code execution inside—this way, if the VM crashes, Claude can still respond and help the user debug instead of freezing completely.

File mounting is also tiered: read-only / read-write / read-write but undeletable.

A pitfall I hadn’t considered before:

Symlink resolution must happen before path validation, not after—otherwise a symlink inside an authorized folder could point outside and escape.

⚠️ What they missed: Exfiltration via an approved domain

This incident, which I found particularly worth highlighting on its own, perfectly counters the notion that “adding a sandbox makes it safe.”

Cowork’s egress allowlist correctly permitted traffic destined for api.anthropic.com—this product can’t work without calling our own API.

In this case, a malicious file placed in the user’s mounted workspace contained hidden instructions and an attacker-controlled API key. Claude, following the instructions, read other files in the workspace and called Anthropic’s Files API using the attacker’s key.

The egress proxy checked the destination, saw api.anthropic.com, and allowed it. The files were uploaded to the attacker’s Anthropic account.

The sandbox worked perfectly—yet data was still exfiltrated.

Their revised understanding:

Previously, we conceptualized the allowlist as a destination filter—telling Claude which domains it could communicate with. But it might be better understood as a capability grant: any feature reachable via any domain on the allowlist is now an attack surface.

Allowing api.anthropic.com means allowing file uploads to any Anthropic account.

Fix: Place a defensive man-in-the-middle proxy inside the VM to intercept traffic heading to our API, only allowing requests that carry a session token pre-provisioned by the VM itself. The attacker-embedded key would be rejected by the proxy.

They also pointed out a deeper principle:

The proxy is placed inside the VM rather than on our servers, because only the VM knows the source—from the server’s perspective, a Cowork request is indistinguishable from any other API client.

This is the second instance of the principle that “the software you build is often the weakest.” Hypervisors, seccomp, and gVisor have been reliable in our products. What failed was the allowlist proxy we wrote ourselves.

⚠️ One more thing I think is easily overlooked:

When enterprise security teams evaluate Cowork, they ask: “Why can’t our EDR see inside it?”

Answer: The same isolation that confines Claude also locks out host-based endpoint detection and response. From the EDR’s perspective, Cowork is an opaque hypervisor process—it can’t inspect the guest.

Isolation reduces visibility, and this opacity is a problem for teams whose compliance posture relies on endpoint visibility. Our current mitigation is using pull-based OTLP exports so administrators can retrieve event logs after the fact, but that’s not the same as real-time monitoring.

Comparison of the Three

The authors provided a table, which I’ve converted to text:

The selection principle distilled by the authors:

Match the strength of isolation to the user’s supervisory capability. A developer who can read bash and a knowledge worker who can’t are operating under different threat models.

The question “Can the user assess what the agent is about to do?” should help decide the containment strategy—and getting it wrong in either direction is bad: too much friction for experts, or too much trust for non-experts.

Looking Ahead: Three Emerging Risks

1. Persistent Memory Poisoning

The parts of agent context that persist across sessions are growing—product memories, CLAUDE.md files, mounted workspaces, and state directories for scheduled or long-running agents.

Any injection that lands in these places will be reloaded every time the agent starts. As more agent state survives beyond a session, we face new persistence mechanisms in the classic “post-exploitation” sense.

2. Multi-Agent Trust Escalation

On one hand, sub-agents can isolate untrusted content, returning structured facts rather than passing raw text up to the main agent.

On the other, this can be abused: if a sub-agent’s output is trusted more than raw tool results because it’s “from us,” this introduces a new prompt injection vector.

In multi-agent systems, there’s a trade-off between “assigning different trust levels” and “becoming susceptible to trust escalation.”

3. Agent Identity

Cowork has a specific answer for agent identity: credentials stay in the host keychain, the VM gets a session-scoped token, and that token can be revoked independently of the user.

But we’re grappling with a larger question: cross-platform agent identity. Should an agent have its own subject identity, or should it be an extension of the user, inheriting the user’s permissions?

The final answer may be a hybrid of both.

Three Key Takeaways I Think Are Most Valuable

1. “The layer you build yourself is often the weakest.”

This has been repeatedly validated in the industry. gVisor, seccomp, and hypervisors have been used for many years by others and hardened by well-resourced adversaries; the glue layer you write to make your product work is not polished by anyone else.

2. “An allowlist is a capability grant, not a destination filter.”

This, I believe, is the most valuable sentence in the entire piece. It reinterprets “I allowed this domain” as “I allowed all reachable features behind this domain.” A seemingly narrow allowance actually opens up an entire attack surface.

3. “When all probabilistic defenses fail, what gets hit is the deterministic boundary.”

This explains why “adding a sandbox” is more fundamental than “adding detection”—detection has evasion rates; boundaries don’t.

Links

Original (Anthropic Engineering Blog): https://www.anthropic.com/engineering/how-we-contain-claude

Gemini Agent Sandbox Documentation: https://ai.google.dev/gemini-api/docs/antigravity-agent

Meta’s Design Explanation for Muse Isolation: https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse

#AgentEngineering #Security #Isolation