{"slug": "sandboxes-favor-repo-native-tooling", "title": "Sandboxes favor repo-native tooling", "summary": "A blog post argues that AI coding agents in sandboxed containers should rely on repo-native, Git-based tooling so they need fewer whitelisted connections to the outside world, using Git as a communication transport and a plain repository log as memory persistence. The post describes splitting the control plane into a separate workflow repo with read-only access to code, and adding a public issue tracker alongside an internal one so a human-supervised gatekeeper agent can relay notes without giving sandboxed agents a path out. The author cites the \"Lethal Trifecta\" of private data, a way out, and untrusted content, and names Epiq as the internal issue tracker and workflow manager serving as the control plane.", "body_md": "[← Blog](../blog.html)\n\n# Sandboxes favor repo-native tooling\n\nRecent incidents [possibly involving rogue agents](https://www.euronews.com/2026/10/14/entire-swedish-reality-show-season-lost-weeks-before-premiere-amid-disputed-ai-claims) highlight the importance of sandboxing. A common setup is a privileged gatekeeper agent on your host machine whose sole responsibility is to delegate work to restricted peers in sandboxed containers.\n\nThis is not watertight, and as the saying goes: if there is a way in, there is a way out, as we shall see. In any case, it is better than nothing at all, and most importantly it narrows the contact surface with the outside world.\n\n## It's political\n\nIt also makes interactions with the sandboxed agents a pain. Agents without a way to communicate with peers, the sandbox gatekeeper, or humans are impractical. The common solution is to relax restrictions with tooling whitelists. But this is not only an annoyance from a technical standpoint. In a large corporation, it takes real political skill to navigate security departments and corporate machinery.\n\n## Repo-native tooling\n\nA way around this is *repo-native tooling* - tools that work offline with only Git access. They have most of the allowances in place, as agents need Git anyway to deliver code.\n\nIf, for instance, the agent control plane is part of the repository, we need fewer gates to the outside. We can use Git as a communication transport and a plain log in a repository as memory persistence.\n\nThis simplifies our setup, but there is a problem: our gatekeeper, with access to the outside, also has access to the code. This is a security risk. In fact, the sandbox itself is typically not what fails, but [the doors left open on purpose](https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-coding-agent-sandbox-escapes-20260722-c/).\n\nTo address this we can split the control plane into a workflow repo, and only give the gatekeeper read access to the code.\n\n## Slipping notes under bars\n\nRepo-native, Git-based tooling does not limit information flow. An important question is who is reached by what information, with what privileges.\n\nThink of it as a drug lord in prison - the cartel is just as lethal as long as he can slip out notes to someone able to act on them, no matter how restricted he is.\n\nThe combination of *private data*, *a way out*, and *untrusted content* is called [the Lethal Trifecta](https://cosmonic.com/ai-sandbox/principles/lethal-trifecta/).\n\nThe idea is that we can contain the risk by not giving any agent all three components.\n\nIn our setup the gatekeeper is the only agent that holds all three legs. It has secrets, it has a way out, and it reads untrusted agent notes. As such, we need to make it *human supervised*.\n\nOur current model still carries some risk: should external stakeholders get access to the control plane, their input would reach the agents unfiltered, and vice versa. We can stop our drug lord from slipping notes to the outside by adding a public issue tracker alongside the internal issue tracker:\n\n## Dead drop\n\nNow the gatekeeper, with no write access to the code, reads instructions from stakeholders and puts notes in the dedicated workflow repo. The notes are picked up by sandboxed agents, with code write access. Think of a Cold War [dead drop](https://en.wikipedia.org/wiki/Dead_drop). In return, sandboxed agents drop notes back onto the workflow repository, leaving an audit trail behind. The gatekeeper reads them as untrusted content.\n\nThis is starting to look a whole lot like a setup I am running. For me [Epiq](https://epiq.sh/) is the internal issue tracker and workflow manager operating as the *control plane*. It persists an event log in your repo and can track work in other repositories, online or offline. It gives me a way to peek into the machinery of the sandbox, and I can also time-travel via the timeline scrubber and inspect historical workflows.\n\n## Bunch of colored boxes\n\nNow, we can make this even more colorful. If we use something like [OpenShell](https://github.com/NVIDIA/OpenShell) to run sandboxed agents, we can keep secrets out of the sandbox entirely, since they are appended by a proxy layer on requests leaving the sandbox.\n\nThis is a lot of colored boxes, so let's not dive deeper. I think this is sufficient to illustrate a basic setup that addresses problems with the lethal trifecta, only requiring: a *Git repo*, *a sandbox* (OpenShell), and *a memory graph* (Epiq).\n\n## Conclusion - repo-native is composable and sandboxable\n\nUsing tooling primitives that are repo-native, standalone and distributed allows you to compose a range of setups, depending on organizational needs. Epiq can manage one, or both, of the two workflow management planes.\n\nAgentic workflows weren't on the radar at the inception of Epiq, 1.5 years ago, but an append-only event log that lives in the repo and travels over Git turns out to integrate easily with sandboxes, providing a way to coordinate without opening another gap in the wall.\n\nIs repo-native tooling a great solution to sandbox restrictions? Share your thoughts in the comments below.", "url": "https://wpnews.pro/news/sandboxes-favor-repo-native-tooling", "canonical_source": "https://epiq.sh/blog/repo-native-tooling-for-sandboxes.html", "published_at": "2026-11-02 18:37:54+00:00", "updated_at": "2026-11-02 18:51:51.504710+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools"], "entities": ["Epiq", "Git", "Cloud Security Alliance", "Cosmonic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/sandboxes-favor-repo-native-tooling", "markdown": "https://wpnews.pro/news/sandboxes-favor-repo-native-tooling.md", "text": "https://wpnews.pro/news/sandboxes-favor-repo-native-tooling.txt", "jsonld": "https://wpnews.pro/news/sandboxes-favor-repo-native-tooling.jsonld"}}