Live data from Hacker News

Running Claude Code dangerously (safely)

blog.emilburzo.com

81–90 of 265 posts

Re: Running Claude Code dangerously (safely)

#81
My approach to safety at the moment is to mostly lean on alignment of the base model. At some point I hope we realize that the effectiveness of an agent is roughly proportional to how much damage it could cause.

I currently apply the same strategy we use in case of the senior developer or CTO going off the deep end. Snapshots of VMs, PITR for databases and file shares, locked down master branches, etc.

I wouldn't spend a bunch of energy inventing an entirely new kind of prison for these agents. I would focus on the same mitigation strategies that could address a malicious human developer. Virtual box on a sensitive host another human is using is not how you'd go about it. Giving the developer a cheap cloud VM or physical host they can completely own is more typical. Locking down at the network is one of the simplest and most effective methods.

Re: Running Claude Code dangerously (safely)

#84

Earlier quoted context omitted.

Claude is very happy to wipe remote dbs, particularly if you're using something like supabase's mcp server. Sometimes it goes down rabbitholes and tries to clean itself up with `rm -rf`. There is definitely a real world risk. You should browse the ai coding subreddits. The regularity of `rm -rf` disasters is, sadly, a great source of entertainment for me. I once was playing around, having Claude Code (Agent A) contro…

Why in the hell would it be able to access a _remote_ database?! In no acceptable dev environment would someone be able to access that.

Supabase virtually encouraged it last year haha. I tried using it once and noped out after using it for an hour, when claude tried to do a bunch of migrations on prod instead of dev.

https://web.archive.org/web/20250622161053/https://supabase....

Now, there are some actual warnings. https://supabase.com/docs/guides/getting-started/mcp#securit...

Re: Running Claude Code dangerously (safely)

#85

Earlier quoted context omitted.

Claude is very happy to wipe remote dbs, particularly if you're using something like supabase's mcp server. Sometimes it goes down rabbitholes and tries to clean itself up with `rm -rf`. There is definitely a real world risk. You should browse the ai coding subreddits. The regularity of `rm -rf` disasters is, sadly, a great source of entertainment for me. I once was playing around, having Claude Code (Agent A) contro…

Why in the hell would it be able to access a _remote_ database?! In no acceptable dev environment would someone be able to access that.

Everywhere I’ve ever worked, there was always some way to access a production system even if it required multiple approvals and short-lived credentials for something like AWS SSM. If the user has access, the agent has access, no matter how briefly.

Re: Running Claude Code dangerously (safely)

#86
I've been exploring this space. There are some use cases where I'd love to run an isolated Claude agent asynchronously. I think running Docker in rootless mode might solve some of the OP's concerns—I believe Podman does this implicitly. Also, there are tools like Kaniko that does not need Docker to create container images. You can also try changing the underlying container runtime to something like gVisor if you want more security.

Does anybody have experience using microVMs (Firecracker, Kata Containers, etc.) for this use case? Would love to hear your thoughts.

Re: Running Claude Code dangerously (safely)

#89
post #80
post #72

I'm pursuing a different approach: instead of isolating where Claude runs, intercept what it wants to do. Shannot[0] captures intent before execution. Scripts run in a PyPy sandbox that intercepts all system calls - commands and file writes get logged but don't happen. You review in a TUI, approve what's safe, then it actually executes. The trade-off vs VMs: VMs let Claude do anything in isolation, Shannot lets Claud…

Very clever name!

Thank you, good to know it landed :)

Re: Running Claude Code dangerously (safely)

#90

Earlier quoted context omitted.

Why in the hell would it be able to access a _remote_ database?! In no acceptable dev environment would someone be able to access that.

Everywhere I’ve ever worked, there was always some way to access a production system even if it required multiple approvals and short-lived credentials for something like AWS SSM. If the user has access, the agent has access, no matter how briefly.

Not if you require auth with a Yubikey, not if you run the LLM client inside a VM which doesn't have your private ssh key, ...
Post reply on HN