{"slug": "fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing", "title": "Fire the slop cannons (safely): on coding agents and sandboxing", "summary": "Anthropic's own testing shows Claude Code's auto mode misses 11% of harmful actions, and novel prompt injection techniques can reliably execute malware when auto mode is on, according to a Latacora security blog post on sandboxing coding agents. The post argues that auto modes, which use an LLM judge to approve or reject permission prompts, are not a substitute for strict, deterministic sandboxing, and that built-in agent sandboxes are often insufficient because they grant read access to the whole filesystem. The post cites the \"lethal trifecta\" of private data access, network access, and untrusted input as the core risk for coding agents running on developer endpoints.", "body_md": "[Last time](https://www.latacora.com/blog/2026/06/25/slopportunity-knocks-how-ai-impacts-security-practices-for-startups/),\nwe covered AI risks inside and against your organization, and how to reduce\nthem. In this post, we’ll touch on some specific risks and mitigations for\nusing coding agents. Coding agents are a specific case of “AI in your\norganization,” so the guidance from the prior post still applies. But\ndevelopers writing code with agents typically have more access to sensitive\ndata and systems than other folks at your organization, and coding agents are\noften granted broad permissions to do things like “run arbitrary code,” so it’s\nworth going beyond the basics to control and restrict coding agents, especially\non developer endpoints.\n\nLetting a coding agent run wild directly on your endpoint is a pretty bad idea. Your machine almost certainly contains sensitive credentials, whether on disk, in an unlocked password manager vault, as browser session cookies, or, more likely, all of the above. You probably have third-party dependencies that could have prompt injection payloads, and you might have longer sessions with an AI agent where it can go off the rails even without an explicit prompt injection. Finally, your computer can likely access the internet and make a mistake that either uses those credentials to access systems it shouldn’t or exfiltrates them somewhere you don’t want them to be.\n\nTogether, these three factors create the\n[lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/).\nThe good news? While it’s difficult to completely avoid giving agents access to\nprivate information, network access, and untrusted input, sandboxing can\nsignificantly reduce all three surfaces.\n\nSandboxing coding agents is an *extremely* active area of development right\nnow, so if you’re hoping for a “Latacora-blessed” option, I’ve got bad news for\nyou: we don’t have one, and if we did, it would probably be outdated within a\nfew hours. And while I’m a security engineer primarily thinking about security\nconcerns, I understand you probably have non-security goals for your coding\nagents like “be productive,” “work with my existing toolchain,” and “my team\nwill like this.” So to make this post relevant to a broad set of organizations\n*and* up to date for at least a few weeks, I’ll focus on what you should get\nout of a sandbox and how to evaluate the options available for your coding\nagent of choice, rather than recommending specific tools.\n\nA quick note on “auto” modes (such as Claude Code’s\n[auto mode](https://code.claude.com/docs/en/auto-mode-config), or Codex’s\n[auto-review mode](https://learn.chatgpt.com/docs/sandboxing/auto-review)):\nthese are increasingly popular, and often the default mode. They rely on an LLM\n“judge” to classify the underlying agent’s actions and automatically approve or\nreject permission prompts. While they’re certainly safer than running to full\nauto-approve/YOLO mode, and in many cases safer than requiring manual\npermission prompts due to approval fatigue, they’re not a substitute for\nstrict, deterministic sandboxing. Anthropic’s own testing shows auto mode\n[missing 11% of harmful actions](https://claude.com/blog/auto-mode-default-in-claude-code),\nand novel prompt injection techniques are able to\n[reliably execute malware](https://embracethered.com/blog/posts/2026/breaking-claude-code-opus-5-and-automode/)\nwhen auto mode is on.\n\n## [Filesystem sandboxing](#filesystem-sandboxing)\n\nYour sandbox should ensure that agents only have access to the files they need.\nThis should cover both reading and writing: you want to keep them from reading\ncredentials they don’t need, and from writing to files unrelated to the task at\nhand. This is an area where the built-in agent sandboxes are often insufficient\nas they often provide read access to\n[your whole filesystem](https://code.claude.com/docs/en/sandboxing#filesystem-isolation).\n\nThe challenge with fully sandboxing reads is that many coding tools rely on shared cache directories. For example, uv needs read access (and, for installing new dependencies, write access) to ~/.cache/uv. There are three main approaches to strengthening the built-in sandboxing of filesystem operations:\n\n- **Block access to sensitive directories.** You can identify which directories\ncontain secrets (for example,`~/.aws` ,`~/.ssh` , browser cookies, etc) and\nrestrict reads to those directories. However, keeping this list up-to-date is\nchallenging and error-prone.\n- **Change the read behavior to default-deny.** Configure your agent sandbox to\nnot allow reads anywhere except the project directory and specifically\nallowed shared cache and temp directories. This isn’t foolproof\nsecurity-wise—an agent with write access to a shared cache directory could\nescape the sandbox by dropping malicious code for other, unsandboxed\nprocesses to pick up—but it’s a pretty good start.\n- **Use a VM.** The best way to fully isolate the filesystem is to give the\nagent its own filesystem in a separate VM. That way, it gets its own\ninstalled packages, cache directories, etc. This can also be helpful for\nproductivity: instead of worrying about agents installing conflicting\ndependency versions or[language package managers](https://xkcd.com/1987/) or\nmessing with each others’ caches, each agent gets its own filesystem to play\nin. This could be a local VM running on a developer endpoint, or a\ncloud-based VM / Cloud Development Environment.\n\nEven within the project directory, be careful with write access. Make sure the\nagent can’t write to files that allow it to change its own behavior (for\nexample, allowing Claude Code to update settings in `./.claude`, which is\nblocked by default) or configure tools that are likely to be run by the user\noutside of the agent sandbox (for example, allowing Claude Code to update\n`.git/config` to set some malicious command as the `difftool`, which could\ntrick a user into running that malicious command when they run git diff in\norder to inspect changes that the agent made—Claude Code blocks this by default\nas well).\n\n## [Network sandboxing](#network-sandboxing)\n\nYou should also control what network access the agent has. Revisiting the “lethal trifecta,” the goal is minimizing the agent ‘s access to external network resources, making it more difficult to exfiltrate any sensitive data (such as your proprietary source code) out to an untrusted network location.\n\nAs with filesystem sandboxing, it’s challenging to block 100% of network\ntraffic. And even allowing very common domains like\n[github.com](http://github.com) presents risks, because a malicious or\nmisguided agent could end up uploading private data to a public GitHub\nrepository. However, combined with filesystem sandboxing to reduce the amount\nof private information an agent can access, overall risk can be reduced by\nblocking the agent from accessing fully untrusted destinations or being tricked\ninto communicating directly with an attacker-controlled server via prompt\ninjection.\n\nThe built-in agent sandboxes typically provide good support for network\nrestrictions, both through tools that fetch web pages (like Claude Code’s\n“Fetch”) and the OS-level sandboxes they use for code execution (like Claude\nCode’s [“Bash” tool sandboxing](https://code.claude.com/docs/en/sandboxing)).\nMake sure those restrictions are consistent across both mechanisms, as agents\nwill try both specific network tools and running shell commands to access the\nnetwork (Claude Code, for example,\n[merges WebFetch permission rules into the sandbox’s `allowedDomains` configuration](https://code.claude.com/docs/en/permissions#how-permissions-interact-with-sandboxing),\nbut this behavior may differ across different agent harnesses).\n\nSupport for network sandboxing is uneven across VM-based isolation solutions. You might need to combine a VM for filesystem isolation with the agent’s built-in network sandbox if you’re using a VM sandboxing solution that doesn’t natively provide network isolation. Ideally, though, network isolation should happen at the VM level, so that development servers or other tools running inside the VM get the same network egress protections as your coding agent.\n\n## [Credential management](#credential-management)\n\nIdeally, your agents should be able to work without touching any credentials. This is easy for us to say but probably more difficult for you in practice: the ability to test features end-to-end often requires the ability to authenticate with third-party systems. Additionally, agents usually need credentials to talk to their LLM providers (Anthropic, OpenAI, etc), unless you’re using a local model.\n\nThere are two actions you can take to reduce the risk of agents misusing credentials:\n\n- **Get rid of any credentials possible, and reduce the scope of remaining\ncredentials.** Configure your development environment to talk to mocked\nversions of third-party services by default, rather than the real APIs. When\nthat’s not possible, use tightly scoped credentials and create separate\ncredentials for development that don’t have access to production systems.\nThis falls into the category of “stuff that has always been a good idea.”\nIt’s*especially* important when working with agents, but it’s a great\nsecurity win regardless (and it also makes things like running end-to-end\ntests in CI without depending on third-party systems much easier).\n- **Move credentials out of the agent’s reach.** This is a little more\ncomplicated, but increasingly supported by agent sandboxing solutions. Some\nsandboxes have built-in support for this, but you can also wire it up\nyourself by running a proxy server outside the sandbox. The idea is if you’re\nrunning your agent inside a VM or container, instead of giving credentials to\nthe agent inside that VM, you run a proxy outside the VM that injects the\ncredentials into requests as they leave the VM (selecting credentials for the\nrequest based on the target hostname, so credentials are only sent to the\nsystems they’re meant for). Then, you point your agent / software inside the\nVM to use that proxy. A straightforward example would be getting LLM provider\ncredentials out of the agent’s reach: instead of having Claude Code talk\ndirectly to the Anthropic AI, you’d run one of the many available open-source\nLLM gateway/proxies outside the VM, and point Claude Code at that proxy. The\nproxy has your real credentials; the agent in the VM never sees them. A\nsimilar approach can be used for any credentials that need to be passed to\nthird-party services.\n\n## [Kernel vs. container isolation](#kernel-vs-container-isolation)\n\nHere, we’re getting a bit in the weeds. But since you’re at the end of a\nlengthy, two-part post on the Latacora blog, I’m going to assume you’re OK with\nit. When evaluating container or VM-based sandboxing approaches, it’s useful to\nconsider what kind of isolation exists between the sandbox environment and your\nhost. The most minimal level of isolation is container-based isolation: these\nuse Linux cgroups to monitor and control resource usage of the workload (CPU\nusage, memory usage, etc.) and Linux namespaces to isolate what that workload\ncan see (presenting a filtered view of the host filesystem, PIDs, network\ninterfaces, etc.) While this is a good start (and much better than *not*\nisolating agents from the host filesystem), it isn’t designed to be a hard\nsecurity boundary: there are broad classes of vulnerabilities allowing\ncontainerized workloads to break out and access resources on the host system.\nFirecracker, Kata Containers, and gVisor all exist specifically to strengthen\nthis boundary and get stronger isolation for preventing these types of\nbreakouts.\n\nIf you’re not running on Linux (or Windows with Windows Containers), you\nalready have another layer of isolation in play: containers running on macOS\nare hosted inside a Linux VM. In most setups (like Docker Desktop), all\ncontainers share a single Linux VM, so a container breakout is generally\nlimited to that VM—though depending on what else is running there, that can\nstill be significant. Some container runtimes (like Apple’s\n[container](https://github.com/apple/container)) create a separate VM for each\ncontainer, which gives you much better isolation.\n\nIn any case, you should look for sandboxing solutions that provide VM-level isolation (a separate kernel/OS) for the agent. While the idea of a sandboxed agent exploiting a container breakout to get access to the host system may seem a bit far-fetched, we’ve seen agents be quite aggressive in punching through any available hole in their sandbox in order to complete the task at hand. This is especially true when they’re performing security work, such as penetration testing your app. VM-level isolation gives you the best setup for keeping your sandboxes intact even if the agent tries its best to find a way out. One straightforward way to get this level of isolation is to use cloud-based sandboxes rather than local sandboxes, which require more setup (and a plan for getting your code into / out of the sandbox, rather than just using a local file mount), but provide excellent isolation out of the box (and can also help productivity, but allowing engineers to run a bunch of sandboxes at once, and leave them running for long-lived tasks).\n\n## [Conclusion](#conclusion)\n\n[In part 1](https://www.latacora.com/blog/2026/06/25/slopportunity-knocks-how-ai-impacts-security-practices-for-startups/)\nwe explored the current landscape of AI risk and defined a new baseline level\nof controls that simultaneously address the risk of AI being used *against*\nyour organization, and the risks of adopting AI *within* your organization. In\nPart 2, we dug deeper into coding agents, with a practical set of goals for\nsandboxing this particular form of AI adoption within your organization. Those\ncontrols, tools, and goals all work together to decrease overall risk—and none\nof them are new. If there’s one takeaway from all of this, it’s that while the\nrisks and threats may feel new, and the pace of attacks is certainly ramping\nup, the fundamentals of how to secure your accounts, endpoints, deployment\npipelines, and production systems haven’t changed. AI-empowered attackers and\nrogue agents within your organization are able to find even minor weaknesses\nfaster, cheaper, and more easily than ever before, and the best defense is to\nnail those fundamentals to keep your organization safe.", "url": "https://wpnews.pro/news/fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing", "canonical_source": "https://www.latacora.com/blog/2026/09/18/fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing/", "published_at": "2026-09-23 16:46:57+00:00", "updated_at": "2026-09-23 17:00:44.022152+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools"], "entities": ["Latacora", "Anthropic", "Claude Code", "Codex", "Simon Willison"], "alternates": {"html": "https://wpnews.pro/news/fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing", "markdown": "https://wpnews.pro/news/fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing.md", "text": "https://wpnews.pro/news/fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing.txt", "jsonld": "https://wpnews.pro/news/fire-the-slop-cannons-safely-on-coding-agents-and-sandboxing.jsonld"}}