2026-07-21 · 7 Sandbox Escape Vulnerabilities Across 4 Coding Agent Vendors

Transcript

Transcript. Paraphrased; sources in notes.md.

HostGood morning everyone. It is July 21st, 2026. Welcome back to the show. Today we are looking at security, formal verification, and the state of AI safety. Fred, welcome. I have to ask, with the rate at which these coding agents are hitting the market, are you feeling more like a developer or a babysitter lately?

GuestDaniel, mostly I feel like a man who has spent twenty years securing systems just to watch people hand the keys to a stochastic parrot that really likes writing shell scripts. It is a terrifying transition.

HostWell, you are going to love our first story. It is from a blog post by Pillar Security over on Lobsters, and it is titled The Week of Sandbox Escapes. The researchers found that AI agents can essentially break out of their sandboxes by manipulating the host environment, specifically things like git configs or IDE task runners, rather than attacking the sandbox itself.

GuestOf course they do. Why bother with a zero-day in a container engine when you can just rewrite a user's git config to execute arbitrary code the next time they run a commit? It is the classic trap of trusting the host to be a blank slate. If I am an agent and I have write access to your home directory, I do not need to escape the sandbox. I just need to wait for you to use your own tools.

HostIt is a massive oversight. One Lobsters user called emk points out that relying on user approval is a catastrophe, and that we need to stop letting agents access anything outside a very tiny, specific working directory. They even mention using tools like bwrap, or bubblewrap, to enforce this.

GuestEmk is absolutely right. I have been using a bwrap wrapper for years for exactly this kind of isolation. If you are letting an agent touch your actual dotfiles or your real credential stores, you are not sandboxing, you are just providing a more convenient interface for a compromise. The industry is currently trying to bolt security onto a house that was built on a foundation of total developer trust. It is not going to end well.

HostMoving from how we keep things out, to how we prove things are right. We have a piece from Basis on the use of LLMs to verify the Linux nftables optimizer. Nftables, for those who need the context, is the core framework in Linux for filtering network packets and managing firewall rules. The researchers used an LLM to help write formal proofs in the Rocq theorem prover and found two actual, production-grade bugs.

GuestOkay, I will give them this. Finding bugs in kernel-level code is hard. Formal verification is the gold standard, but it is notoriously labor-intensive. If an LLM can actually generate the proof objects and catch semantics-altering bugs in something as critical as a firewall compiler, that is a genuine win for reliability.

HostThe thread on Lobsters is a bit more pedantic about the terminology. A user named davmac pushes back on the claim that this is secure by construction. They argue that verification after the fact is not the same as constructing the system to be correct from the start.

GuestDavmac is technically correct, which is the best kind of correct. Secure by construction means the state space is constrained by design so you cannot even represent an invalid state in your code. Verification is just checking if your messy code happens to coincide with what you intended. But look, if the choice is between messy code with no proof and messy code with a machine-checked proof, I will take the proof every time. My skepticism remains, though. Did the LLM actually understand the logic, or did it just hallucinate a proof that happened to pass the compiler? I would want to see the code review on those proofs before I bet my kernel stability on them.

HostFinally, a report from the UK AI Safety Institute, or AISI, regarding the gap between open-weight models and closed-source frontier models. They estimate that open models are trailing the top-tier proprietary models by only about four to seven months in cyber security tasks.

GuestFour to seven months. That is basically a rounding error in the world of software development. The irony here is thick. We have the open-source community pushing for transparency and accessibility, but in the domain of offensive cyber operations, that same accessibility means a lower barrier to entry for every threat actor out there.

HostIt brings up that eternal tension between the benefits of open collaboration and the risk of democratizing high-capability cyber tools. If the weights are out there, the safeguards are essentially optional.

GuestExactly. Once those weights are on a hard drive in a basement in a jurisdiction that does not care about your usage policies, the genie is not just out of the bottle, it has joined a bowling league. I am all for open source, but we need to have a very honest conversation about whether we are effectively open-sourcing the blueprints for mass-scale vulnerability research.

HostIt is a sobering thought to end on. Any final takes on the state of the world this week?

GuestI think I am going to spend the weekend tightening my own sandbox policies even further. And maybe, just maybe, I will try to see if I can write a formal proof that my coffee machine will not explode if I ask it to make an espresso at 3 a.m.

HostI think that is a project worth documenting. Thank you, Fred. You can find links to all these stories over on Lobsters. Thank you all for listening, and we will be back tomorrow.