[flagged]
The ways we contain Claude across products
51–60 of 128 posts
Re: The ways we contain Claude across products
#52You 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]
Re: The ways we contain Claude across products
#53Earlier quoted context omitted.
Wouldn't you lose multiple sticks or fry multiple motherboards as you scale and do 1000? If you're frying 1 at 10, that means you're frying 100 at 1000. Your costs etc will scale as well unless you actually lower the risk/reward ratio, no?
I think the point is that at small scale a single accident poses a risk of ruin to your small operations.
> I think the point is that at small scale a single accident poses a risk of ruin to your small operations.
At big scale, a single big accident poses a risk to ruin your big operations.
Re: The ways we contain Claude across products
#54I'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...
Re: The ways we contain Claude across products
#55The 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.
That's how decisions are made IRL. Risk/reward is a thing.
This is risk to us and reward for them though.
Re: The ways we contain Claude across products
#56I'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 fa…
> I'm intensely skeptical about anything Anthropic says, because they are so incented to make their products seem dangerous
OpenAI, Google, etc. are not using "that strategy". I do believe that people at Anthropic genuinely care about AI safety. That's the main reason the company was founded. But I can imagine that idealism is eroding with new people and money flowing in.
Re: The ways we contain Claude across products
#57[flagged]
Re: The ways we contain Claude across products
#58>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.
LLM clearly is broken by design when it's been personified, but I think "software" as we understood, is inevitably evolving into "personified entity" (I've left some notes in [1], which are AI generated).
There is also an interesting trend that the more personified brand is more dominant: Claude & Doubao vs ChatGPT & DeepSeek.
[1] https://github.com/NascentCore/agentic-suite/tree/main/perso...
Re: The ways we contain Claude across products
#59I'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.
Re: The ways we contain Claude across products
#60"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.