Agentics: local coding agents are inherently unsafe

Running coding agents like Claude Code with full local permissions poses inherent security risks, as the agents require filesystem access to function but can potentially access sensitive data including SSH keys, credentials, and personal files. Users face a tradeoff between autonomy, ease of setup, and security, with most opting for powerful but insecure local configurations rather than building isolated cloud sandboxes. Industry experts recommend OS-level sandboxing and explicit deny rules for critical directories as temporary mitigations, but argue that cloud-based sandbox environments remain the only viable long-term solution for secure autonomous coding agents.

Agentics: local coding agents are inherently unsafe Easy, powerful, secure. Pick two. I have a confession to make. I run Claude Code 1 footnote-1 in YOLO mode. I know I shouldn’t. I know it’s a terrible idea. But I just cannot stand sitting there and hitting enter every 30 seconds because Claude wants to read a file. After mindlessly hitting enter for the ten millionth time on some prompt, I snapped. I aliased Claude to claude —dangerously-skip-permissions And even though I’m now free from the burden of having to babysit the agent, I have a new fear. One day, I don’t know when, Claude will rm -rf my entire computer. In the past, I’ve said that coding agents are a lot like a really smart, totally untrained intern. I still basically believe that. Even though models have gotten better over time, they still come to every session completely fresh without any context on you, your company, or your engineering practices. Would you give a new hire intern unlimited access to your local machine? You know, where you have all your ssh keys and your contracts and a ton of personal data and maybe photos of your license/credit card/passport? The fundamental tension is that we want agents that are highly autonomous, easy to set up, and really secure; and in practice, we can only pick two. You can install a frontier coding agent Claude Code, Codex locally and set up all the MCPs and it will be super easy because local dev is the happy path, and then the agent will one day nuke your email inbox. You can install a highly controlled permission-gated agent locally, get all the easy set up, and then spend your whole day hitting enter on permissions prompts one at a time. Or you can take a month to build out an isolated sandbox service to run Claude Code as a background agent. The agent works, but you’re too deep in docker networking configs to really enjoy it. The vast majority of people are in the powerful, easy, insecure part of the embedding space. Mostly by choice — the average consumer of Claude Code probably couldn’t figure out how to set up a secure sandbox and definitely doesn’t want to use a limited agent. There are some things that you can do to make the local experience slightly more secure while minimizing the amount of “Yes, and don’t ask me again” you need to do. Turn on /sandbox . It's OS-level isolation bubblewrap on Linux, Seatbelt on macOS that confines writes to your working directory and routes network through an allowlist proxy.Add explicit deny rules for the stuff you never want touched — ~/.ssh, ~/.aws/credentials, .env, id rsa, .npmrc, ~/.netrc — in your settings Write good skills and agent configs, and don’t let your conversations go through too many turns. Anthropic even shipped an entire permissions mode https://www.anthropic.com/engineering/claude-code-auto-mode that is meant to address this complaint. Claude Code users approve 93% of permission prompts. We built classifiers to automate some decisions, increasing safety while reducing approval fatigue. But these will always be bandaids. The fundamental tension of a coding agent is that you want to give it access to things. It needs to be able to write and read files in order to do the most basic tasks. Unfortunately, that alone is enough to break out of most guardrails. Your filesystem is a core part of the agent config, so you should assume that anything on your disk is fair game. I think the only actual way to have your cake and eat it too is to go the sandbox route. Ideally sandboxes in the cloud, far away from your local files, on boxes that you can tear down without hesitation because they don’t have anything precious in them. Yes, setting up background agents is a pain, but that will get easier over time as people figure out how to implement the infra. And you get more than security — agents that live on cloud sandboxes can be accessed remotely from a ton of different interfaces, and can be triggered by automatic events like bug reports or customer inbound. For our agent environments, we went with a firecrackers micro VM provider for the base machine. 2 footnote-2 These are extremely easy to start and kill, which makes them perfect for building agent runtimes that are constantly refreshing themselves. The VMs themselves don’t really have state. Instead, each VM has a setup script that clones all the relevant repos and sets up all the dependencies, so each agent session runs on a clean box. The agent can basically destroy the machine and it won’t matter, we’ll just recycle the thing. The actual keys are never kept on the same box as where the agent is running. Instead, we proxy between the agent runtime and the outside world. Whenever we see certain credential placeholders in anything going outbound, we can trigger conditionals that determine whether we should inject the real credentials. The end result is that the agent thinks it has access to everything, but in practice it’s tightly controlled. This isn’t the first time I’ve harped on the benefits of cloud agents. I also wrote about them in my post on AI enablement. I think there’s a big gap in the market for managed agent runtimes also known as ‘background agents’ because they can run in the background on the cloud . Everything else — org level skills, for eg — is just a band-aid. I’ve said in the past that for coding agents, the filesystem isthe config. That means that you have to control the entire filesystem to get a consistent and secure experience. It is simply not enough to assume that everyone in the org will learn not just how to use AI, but also how to use a CLI and how to use Bash and how to use git and how to use the million other tools that are required to get a coding agent off the ground. And even that may not be enough.… I think most teams should go for a fully managed service. Devin has been in the space for a long time. I think Twill is a relative newcomer that also does something like this? But there aren’t a ton of other services that actually follow the Ramp-Inspect / Stripe-Minions model. So when we ran into this problem ourselves, we weren’t happy with most of the other options out there and set out to build our own , which we now sell as an off the shelf option with a lot of customization flexibility.I have to say, having a tool like this is pretty incredible, and I’m really glad we built it. More than 30% of our PRs are shipped entirely through slack, and we have all sorts of really cool automations for things like bug triage to newsletter writing. But all of that takes a lot of maintenance, and we spend literally all day just thinking about how to make this one thing awesome, and it would be impossible to do that if we were building in, like, healthcare or manufacturing instead. It’s hard to explain how transformative these are for a company, but once you have them you cannot really go back. My best metaphor is that a good background agent setup is much more like hiring an extremely capable engineer than it is like interacting with a tool in a terminal. It is very natural and intuitive to interact with these things like a person, which short circuits a lot of hard learning curves and enables a lot of collaboration. And, of course, they are secure. Way way more secure than running a local agent, or giving a new hire intern access to your personal laptop. 1 footnote-anchor-1 and codex et al. 2 footnote-anchor-2 currently fly.io but we’re considering switching to modal. The only reason we haven’t yet is because gvisor doesn’t make docker support that easy