{"slug": "agentics-local-coding-agents-are-inherently-unsafe", "title": "Agentics: local coding agents are inherently unsafe", "summary": "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.", "body_md": "# Agentics: local coding agents are inherently unsafe\n\n### Easy, powerful, secure. Pick two.\n\nI have a confession to make.\n\nI run Claude Code[1](#footnote-1) in YOLO mode.\n\nI 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.\n\nAfter mindlessly hitting enter for the ten millionth time on some prompt, I snapped.\n\nI aliased Claude to `claude —dangerously-skip-permissions`\n\nAnd even though I’m now free from the burden of having to babysit the agent, I have a new fear.\n\nOne day, I don’t know when, Claude will rm -rf my entire computer.\n\nIn 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?\n\nThe 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.\n\nYou 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.\n\nYou 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.\n\nOr 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.\n\nThe 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.\n\nThere 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.\n\nTurn on\n\n`/sandbox`\n\n. 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\n\nWrite good skills and agent configs, and don’t let your conversations go through too many turns.\n\nAnthropic even [shipped an entire permissions mode](https://www.anthropic.com/engineering/claude-code-auto-mode) that is meant to address this complaint.\n\nClaude Code users approve 93% of permission prompts. We built classifiers to automate some decisions, increasing safety while reducing approval fatigue.\n\nBut 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.\n\nI 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.\n\nFor 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.\n\nThe 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.\n\nThis 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.\n\nI 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\n\nisthe 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.…\n\nI think most teams should go for a fully managed service.\n\n[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.\n\nIt’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.\n\nAnd, 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.\n\n[1](#footnote-anchor-1)\n\nand codex et al.\n\n[2](#footnote-anchor-2)\n\ncurrently 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", "url": "https://wpnews.pro/news/agentics-local-coding-agents-are-inherently-unsafe", "canonical_source": "https://12gramsofcarbon.com/p/agentics-local-coding-agents-are", "published_at": "2026-06-06 16:01:15+00:00", "updated_at": "2026-06-06 16:42:14.243028+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "large-language-models", "ai-ethics"], "entities": ["Claude Code", "Codex", "Claude"], "alternates": {"html": "https://wpnews.pro/news/agentics-local-coding-agents-are-inherently-unsafe", "markdown": "https://wpnews.pro/news/agentics-local-coding-agents-are-inherently-unsafe.md", "text": "https://wpnews.pro/news/agentics-local-coding-agents-are-inherently-unsafe.txt", "jsonld": "https://wpnews.pro/news/agentics-local-coding-agents-are-inherently-unsafe.jsonld"}}