I'm late to this thread, but the post seems to skip the section about risks/mistakes/incidents with restricting Claude's access with containers ("pattern 1"). Doing this properly is still hard!

For example, Anthropic has shipped several bugs that allow any claude.ai/code session – which are isolated in ephemeral containers – to access and exfiltrate all of the user's other sessions, connected repos, and environment variables. The rogue/hijacked Claude could also spawn new Claude sessions with arbitrary instructions and access, regardless of the original session's constraints.

I originally wrote about this (with permission) in February[1], and most of the issues were quickly fixed. But the underlying token scope issues have regressed several times since then – including post-Mythos – so I wouldn't say that Anthropic has solved this yet.

[1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...

The framing they use is hilarious and their little graphic is perfect. The risk of harm doesn't go down, but the reward goes up, so the harm just becomes the cost of doing business, justified by the reward. So as the reward gets higher and higher, the amount of harm they're willing to justify goes up. Feels like society in a nutshell.

I'm intensely skeptical about anything Anthropic says, because they are so incented to make their products seem dangerous (i.e., "capable", "science fiction", "ahead of everyone") ahead of their IPO.

And they've done it before.

Remember the whole "when threatened, the model would use an engineer's email to blackmail him about his affair" nonsense? That was just fan fiction. They simply created a scenario with some facts and asked their model to continue the story. Go ask Claude about ways to steal the British crown jewels and it'll give you some ideas. This does not mean their models are so dangerous that the Tower of London needs additional security.

I assume all their other scare tactics are more of the same.

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

That means the attacker can still exfiltrate files if they get root inside the VM.

Why not run the proxy outside the VM, still on the client?

Doing this in general is really hard. Unfortunately the blog post doesn't really go into detail of how hard, though it does mention some cases. For example, if you run your agent in a VM with network access, it can come across something that prompt injects it into encoding a secondary prompt injection for the artifact that comes out of the VM, which then infects your local, more privileged agent.

Another case that came up when we were doing computer use analysis at a previous role was that we tried to figure out if user input was trusted to not be bad. Generally, if the user typed it, that would be OK, but what about the user's files? Or their calendar events? Well, the whole point of the product was that the agent would manage those for you, which meant that they were no longer trustworthy to not have injections in them. (Hey, can you look up when the Super Bowl is and remind me to book plane tickets for that weekend?) If you do this kind of taint analysis you will quickly find that it's super difficult to stop this kind of thing and just putting a sandbox or VM around things often does not help.

I'm still happy with my containment setup[1][2] on linux. The only risk that I see from the article would be the "Exfiltration through an approved domain" one. But in the VM there's (by design) nothing to exfiltrate besides the source code itself, which is less valuable these days.

The major benefit for me with this setup is that the agent can do all of the dev things that I can (install packages, build/run docker images, ...) which is a way faster loop than me trying it manually and then reporting back to the agent.

[1] https://blog.emilburzo.com/2026/01/running-claude-code-dange...

[2] https://news.ycombinator.com/item?id=46690907

From inspecting the Cowork VM, the pollution is not documented and not controllable (publicly known - I have workarounds). It creates a lot of waste and frustration in the process.

CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 means claude finds and loads all the CLAUDE.md of all the mounted repos overtime (and by settings). As such, working on multiple unrelated repos at the same time isn’t a pleasant experience out of the box.

A few other interesting VM ENVs: CLAUDE_CODE_IS_COWORK=1 CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1 CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673 USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

>As agents grow more capable, so does their potential blast radius. The engineering question is how to cap it.

People get a bit upset these days when you personify an LLM, but worse than that I think is to pretend that LLMs work on some movie logic where they can sneak out on to the internet like some kind of ooze and begin replication.

I'm using qemu VM. This VM has Internet access (that's the biggest risk, I guess, that claude can just upload things somewhere). If I want it to work with github, I create token restricted to repository with read or read/write access. But I prefer for it to not push, but just commit, then I can fetch these commits via ssh from VM, check log and push it myself.

I thought about just running claude in container, but it feels a bit weak. Too many Linux vulnerabilities around. Probably these fears are unfounded, but I feel safer running untrusted stuff in qemu VM.

Egress controls are the only real defense here and most people running Claude Code locally dont have any.

I recently threw together a nutshell helper function that lets me launch a process using bubblewrap to only give it read/write access to the directory I run it from (plus a couple of specific Linux system directories so that stuff like GUI and libportal will work) with everything else being read-only. This is a lot less annoying than a container for stuff where I legitimately want to be able to point agents at random stuff in other places (screenshots, log files, etc.) but also want to just blanket enable things so I don't need to babysit things to approve them manually over and over. It's pretty odd to me that this sort of experience isn't already being invested in by AI tooling platforms; the impetus for doing this was that I was frustrated that Zed, the editor with the entire premise of being used for AI stuff like this, only supports putting permissions for specific paths in the user-wide settings file; project-level settings files exist, but for reasons I can't fathom, they explicitly don't support any of the permissions settings for agents.

I'm no decision theorist but I think they should wait for the rewards outweigh the expected harms in expectation rather than being statistically equal.

One attack they missed in the egress proxy is exfiltration via domain fronting. Putting together a full PoC would require a fastly account so I couldn't be bothered to report it.

Although, testing again, it might be fixed now.

> the cost of not deploying grows large enough that the risk-reward calculation tips heavily toward adoption

Interesting framing! The cost for whom? Anthropic?

> Claude Code auto mode delegates command approvals to a model-based classifier; it minimizes friction (roughly 0.4% of benign commands blocked) at the cost of missing a fraction of risky ones (~17% of overeager actions get through), so it's one layer of defense-in-depth inside a sandbox, not a substitute for one.

This is pretty alarming to read. The auto mode docs (https://code.claude.com/docs/en/auto-mode-config) do not have any such caveats, they say that it blocks anything "irreversible, destructive, or aimed outside your environment". I wouldn't even call this misleading, it's simply false to describe a guardrail with a 17% false negative rate that way.

I have been thinking about this a lot. I just bought a rather expensive rig for local inference for a home agent (powered by four RTX PRO 6000 Blackwell Max-Qs).

As I contemplate handing it more and more of the keys to my life, I grow increasingly concerned about what is, to me, the primary risk of this. Not data destruction (automated backups are trivial), but data exfiltration. Specifically, via prompt injection.

My solution to the problem, which I am implementing as a Hermes plugin + custom iOS / macOS app, is simple: an airlock architecture. One Hermes profile runs with local FS access and no internet access, inside an Apple container, and one Hermes profile runs with internet access and no FS access, inside an Apple container. They never share data directly or in any automated fashion.

If the user (i.e., my wife) wants to do some internet research, she can start a conversation with the remote-access profile. This is analogous to Claude and ChatGPT apps in their current state. However, at any point, she can flip the conversation over to local mode, which copies and pastes the conversation's transcript into the local-only profile (which has zero egress, enforced at the VM level) and seamlessly switches over to a new conversation in that profile.

After that, there's no way to re-enable internet attachment. Should she want to spawn a new conversation with information derived from the local file system, she starts a new conversation with a local agent, asks it to write up a research plan, and then – this is the airlock – manually begins a new conversation with only this plan in context.

The advantage this grants is that it's no longer necessary to worry about poisonous inputs flowing in – she only needs to worry about making sure any generated plan, the only artifact which could conceivably enter into the egress-enabled agent, does not contain information we'd rather not share with the internet at large.

I think this is bulletproof, but very much welcome input. Is it possible I am overengineering this out of paranoia? Yes. Will I share a lot more of my personal data with the agent as a result of its perceived security? Also yes. Is that dumb? Maybe.

There are a number of clearly LLM written comments flagged dead below. The article itself, so clearly LLM written, is still kicking.

To be fair, it's worth wading through the phraseology to understand the perspective of the article's prompters.

But there are so many cliché constructs it's distracting:

> The GitHub README example mentioned earlier is exactly this case; any input scanning applied to web pages needs to be applied to network-enabled tool results with the same rigor.

> Claude Cowork's answer to agent identity is concrete: credentials stay in the host keychain, the VM gets a per-session scoped-down token, and that token can be revoked independently of the user's.

Honestly, for sifting LLM from human the article shows exactly the problem: colleagues have begun to talk like Claude in everyday interaction.*

* and not deliberately as here

"Design for containment at the environment layer first, then steer behavior at the model layer. "

Umm... yeah? This is what I've been arguing for a long time now, and it's the primary reason why I wrote https://github.com/kstenerud/yoloai and use it as my daily-driver. I can't imagine running an agent without it.

The environment layer is deterministic; the model layer is probabilistic. If your only defense is "the model is well-behaved" you've bet your crown jewels on a coin that happens to land heads most of the time.

Also, "blast radius" isn't just one axis. You have:

- Destruction radius: How many things INSIDE your workdir can get clobbered.

- Collateral damage radius: How many things OUTSIDE your workdir can get clobbered.

- Review radius: Are the changes gated on your review? Can you copy/diff/apply the changes the agent made to a copy INSIDE the container, to your real workdir OUTSIDE of the container?

- Credential radius: How many credentials does your agent have access to? What bad things can it do with them?

- Exfiltration radius: Network restrictions help here, but they don't guarantee that your secrets won't be exposed in a sneaky way. Don't expose the secrets to your agent to begin with.

What tool do they use for diagrams?

The way you contain LLMs is the same way you will contain anything else - give it less permission and less scope.

Here. I saved you some time reading the article.

Buckle up!

Great. Wish we've had more people in the community thinking about solutions like this.

Hahahaha yeah, makes sense. Every time I use claude after codex I feel like I’m holding Claude’s hand the entire time. I imagine they have a lot of containing they have to do internally

"It's possible Son of Anton thought the most efficient way to get rid of all the bugs was to get rid of all the software, which is technically and statistically correct"

> If you've occasionally used AI tools for professional coding work, tell us about it. POCC (Plain Old Claude Code). Since the 4.5 models, It does 90% of the work. I do a final tinkering and polishing for the PR because by this point it is straightforward for me to fix the code than asking the model to fix it for me. The work: Fairly straightward UI + hosting work on a website. We have designers producing Figma and we use Figma MCP to convert that to web pages. POCC reduces the time taken to complete the work by at least 50%. The last mile problem exist. Its not a one-shot story to PR prompt. There are a abundance back & forths with the model, multitude direct IDE edits, offline tests, etc. I can see how having subagents/skills/hooks/memory can reduce the manual effort further. Challenges: 1) AI first documentation: Stories have to be written with greater detail and acceptance criteria. 2) Code reviews: copilot reviews on vite are critically insightful, but waiting on human reviews is still a deadlock. 3) AI first thinking: thousands of the lead devs are although hung up on different prime practices that are not relevant in a world where the machine generates assorted of the code. There is a corruption in the code LLM is fine at and the standards expected from an experienced developer. This creates busy work at prime, frustration at ideal. 4) Anti-AI sentiment: There is a vocal cluster who oppose AI for reasons from craftsmanship to capitalism to global environment crisis. It is a batch political and slack channels are getting interesting. 5) Prompt Engineering: Im in EU, when the team is multi-lingual and English is adopted as the language of communication, dozens members struggle more than others. 6) Losing the will to code. I can't seem to make up my mind if the tech is like the invention of calculator or the creation of social media. We don't know its long term breakthrough on producing developers who can code for a living. honestly, I love it. I mourn for the loss of the 10x engineer, but those 10x guys have already onboarded the LLM ship.

You can create an impenetrable prison for the LLM agents if you are willing to employ old school tech like Postgres, MSSQL or Oracle to solve the problem. I can't think of a better sandbox. No other ecosystem is as complete. Using virtual machines & containers is way too much, IMO. If you want to give the agent arbitrary code execution, allowing it to write [T/PL/pg]SQL over explicitly granted schema objects seems to be a more secure approach than running arbitrary python or C# scripts on a VM somewhere.

If you are in a highly regulated environment, I would double down on this advice many times over. Features like row level security + connection context can be used to isolate on a tenant basis (per user's conversation thread) in a way that an auditor would be properly satisfied with. They already have checkboxes on their forms for this technology. Building a custom sandbox ecosystem from scratch is a long, twisted road. There are existing technologies that ~perfectly solve this problem, assuming you have the patience to frame it appropriately.

Think about this from the perspective of the user principals you would create. A built-in SQL account with locked down schema access is constrained in so many more dimensions than an AAD account with access to sandbox/container VMs. With a SQL account, you can exhaustively enumerate all of the things the model could hypothetically touch in one sitting. Privilege escalation is a possibility in the RDBMS environments, but mostly in the same sense that time travel or fusion power is a possibility in real life (i.e., so unlikely we can probably ignore the concern).

I've been doing this for a few months now and it is very obviously the correct path. YC put out a video about this concept too. The only way the agent in my architecture gets to talk to the outside world is by way of a table called RemoteProcedureCalls that a totally separate service polls & responds to over time.

https://www.youtube.com/watch?v=B246K_G7mHU [5:07 -> 9:14]