[dead]
The ways we contain Claude across products
71–80 of 128 posts
Re: The ways we contain Claude across products
#72Earlier quoted context omitted.
Yeah I was thinking about Simon Wilson's "lethal trifecta"[0] in the context of OpenClaw style "general purpose" AI agents, where people just gave it access to their full hard drive, gmail account, etc. I was thinking you can't make the chance of catastrophic failure zero (we still hear about "Claude deleted my home folder"), but you can definitely limit the blast radius. You can't get the risk to zero. But the oppor…
I tried the VPS briefly, it didn't really solve anything for me. The personal assistant agent is only as useful as the data & tools it has, that's where the real risk is. Separate box gives you isolated FS but docker also does that very easily.
Docker is not a security boundary. It never has been, but given recent demonstrations of container escapes its even less of one than it ever was. If you want to properly contain a process it needs to be running in a VM of its own, or you need to accept that there's a risk of it escaping and ending up with more access than you planned.
Re: The ways we contain Claude across products
#73Doing 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.
Re: The ways we contain Claude across products
#74> the cost of not deploying grows large enough that the risk-reward calculation tips heavily toward adoption
Interesting framing! The cost for whom? Anthropic?
Re: The ways we contain Claude across products
#75Doing 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 ca…
[dead]
Re: The ways we contain Claude across products
#76The 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.
If I understand this correctly, Anthropic's argument is now "yes this will blow up some of your infrastructure, but it will be worth it" The problem is that no one has been able to prove that it is actually worth the cost. That is a very fragile assumption.
This has always been the premise. They can't fix the fundamental problems with LLMs but they can continue to optimise them for IE parsing large volumes of data quickly
Re: The ways we contain Claude across products
#77Re: The ways we contain Claude across products
#78I'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 im…
Agent can get tricked into using a malicious library in your project, commit and push that, which you then run outside the VM.
So if you ever run the repo code outside the VM and don't review everything committed, you are still at danger.
Re: The ways we contain Claude across products
#79The 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.
Everything you do a risk/reward equation, you just don't usually see it drawn out quite so starkly. Getting out of bed in the morning carries a risk that you'll trip and crack your head on the floor. Crossing a road carries a risk of being hit by a bus. Eating food carries a risk of choking on it. The same is true in computer security. The only truly secure computer is one you don't turn on, and even that carries some risk of an attacker breaking in and stealing the storage from it.
Whether you agree that the potential harms outweigh the benefits in this case or not those calculations are always happening, so yes, I guess you're right. That is society in a nutshell.
Re: The ways we contain Claude across products
#80I'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 im…
Agent can get tricked into using a malicious library in your project, commit and push that, which you then run outside the VM. So if you ever run the repo code outside the VM and don't review everything committed, you are still at danger.
It doesn't have any credentials inside the VM though, not even for git, so it could commit but not push. And I manually review/commit/push outside of the VM since I don't want to just dump stuff without reading it first.
But good call-out if someone uses a different workflow.