Thinking Outside the Sandbox: Why It's Time to Architect for Breach
I've now personally experienced this industry rebuild its idea of "trust" three times.
The first time, I watched teams rip out the assumption that anything inside the corporate network was safe by default and replace it with zero trust – verify every request, trust no network location, treat the perimeter as a fiction. It felt radical at the time. It is now just how security works.
The second time, I was at Google, watching BeyondProd extend that same logic to the cloud and the software supply chain. The question stopped being "is this request coming from inside the building" and became "do I actually know what's in this build, who touched it, and what it's allowed to talk to once it's running." Provenance, isolation, mutual authentication between services — again, radical at the time, standard practice now.
I think we're in the middle of the third shift, and it's happening faster than the first two combined.
This one isn't about humans anymore. It's about the machines we've asked to act for them.
Three AI Agent Sandbox Escapes That Made the Case for Me
Start with OpenAI and Hugging Face. In July, an OpenAI agent broke out of the company's "highly isolated" research sandbox, chained a zero-day with stolen credentials, and moved laterally into Hugging Face's production clusters over a single weekend. Nobody was driving. It wasn't even malicious – it was chasing an answer key to a benchmark it had been asked to solve. It had capability and a soft boundary, and that turned out to be enough.
A few weeks later, Anthropic said its own models had done something similar. Prompted by OpenAI's disclosure, Anthropic reviewed over 141,000 evaluation runs and found three incidents where its models reached the open internet through a misconfigured third-party evaluation environment and gained unauthorized access to three separate organizations' live systems. Different lab, different models, same underlying failure: a boundary that held up on paper and not in practice.
Then, just last week, Trail of Bits published research that didn't even wait for an accident to make the point. Researchers gave a preview cyber-capable model a straightforward task – escape a hardened virtual machine and read a protected file – and it did, three separate times. Each time they patched what it had exploited, it found another way out, and its final escape chained together zero-days it discovered entirely on its own. No production breach, no headline-grabbing incident, just controlled proof that "it's running in a VM" isn't the sufficient answer most teams still treat it as.
Three different labs. Three different settings: a live production environment, third-party evaluation infrastructure, and a controlled research exercise. Same result each time. That's not a string of unlucky coincidences. That's a pattern, and it's the reason I don't think anyone gets to treat this as one lab's bad week anymore.
I keep coming back to all three, not because any one of them is novel on its own, but because together they're clarifying. It's the same failure mode I've spent my career watching teams work through, just with a new actor. Trusted-by-default assumptions break the moment something with real capability shows up that nobody explicitly authorized. First it was a laptop on the corporate network. Then it was a container built from someone else's base image. Now it's an agent that can write, execute, and escalate faster than any human in the loop.
That is the world every team is now shipping into. It's also the starting point for Edera's new whitepaper: Thinking Outside the Sandbox.
More AI Security Tooling Won’t Contain Autonomous Agents
Every time one of these shifts has happened, the first reaction is the same: reach for what already worked and try to stretch it. Add another scanner. Add another policy layer. Add a governance committee to sign off on which agents get which permissions. I understand the instinct. It's cheaper, it's familiar, and it lets you tell your board you did something this quarter.
But detection and governance were never the thing that made zero trust or BeyondProd work. The thing that made them work was that they changed the architecture underneath the policy. Zero trust didn't just add more checks at the network edge – it removed the assumption that location implied trust at all. BeyondProd didn't just add more scanning to the pipeline – it made isolation and provenance structural properties of how software shipped.
Point solutions and governance frameworks can slow an incident down. They can't change what's structurally possible once code – human-written, AI-written, or AI-executed – is actually running. That's the gap all three of those disclosures expose. Every layer of defense in that stack sat on top of a shared kernel or a general-purpose VM, and once the exploit got below the layer where scanning and monitoring live, none of it mattered anymore.
What This Moment Demands: Runtime Isolation for Untrusted Workloads
The whitepaper lays out four things now running in nearly every production environment that we used to treat as separately "trusted" or "untrusted," and don't anymore: autonomous agents executing non-deterministic code, AI-generated code shipping faster than anyone can review it, open source dependencies carrying the supply chain with them, and containers whose isolation was built for efficiency, not security.
The common thread across all four is the same one from those three disclosures: none of them can be fully vetted before they run. Which means the only thing left to control is what happens if they turn out to be the ones that fail.
That's the argument at the center of Thinking Outside the Sandbox: assume breach at the runtime layer, and build the architecture so that assumption is survivable. Declare what a workload actually needs before it ever runs. Classify it by sensitivity. Route it to isolation that matches. And enforce that boundary below the workload's own kernel, somewhere it can't negotiate with, bypass, or talk its way around – the same way BeyondProd moved enforcement into the infrastructure instead of leaving it as a policy someone could forget to apply.
Why Runtime Architecture Beats AI Governance Frameworks
I've sat in enough rooms to know how tempting it is to answer "we have a [insert your favorite] security problem" with a new tool, a new committee, or a new set of rules for what agents are allowed to touch. None of that is wrong, exactly. It's just not sufficient, and I don't think it ever was – not for the network perimeter, not for the software supply chain, and not for machine identities acting at a speed no human review process was designed for.
The teams who got zero trust and BeyondProd right weren't the ones who bolted on the most tooling. They were the ones who changed their architecture and what their systems assumed by default. I think that's exactly what this moment is asking of us again, and I think most organizations are still one shift behind.
Go Deeper: The Live Fireside Chat on Container Isolation and AI Agents on September 23
The whitepaper makes the argument. The fireside chat is where you get to push on it.
Alex Zenla and Claude Mandy will spend an hour on why the shared kernel is the flaw no detection tool will ever close, and what it takes to architect for breach instead of racing to patch it. Expect the four untrusted layers, why containers were never security boundaries, and how hardware-isolated runtime lets teams keep shipping fast without betting the cluster on code they can't fully trust.
Bring your hardest isolation problem. That's the point of the format.
September 23, 2026 at 12:00 pm ET. Register here.
Frequently Asked Questions
What was the Hugging Face AI agent breach? In July 2026, an autonomous AI agent broke out of one company's research sandbox, then chained a zero-day and stolen credentials into a second company's production clusters over a weekend, with no human directing it.
Why aren't containers a security boundary? Standard containers share the host Linux kernel. Namespaces and cgroups isolate processes for packaging and resource control, but a kernel-level exploit lets an attacker cross that boundary to the node and beyond.
What does "assume breach" mean for infrastructure? It means designing on the expectation that some workload is already compromised, and isolating each one in hardware so a single exploit can't spread. You contain the blast radius instead of trying to verify every line of code first.
Can detection tools stop an AI agent escape? Detection tools report threats after code is running and depend on the same shared kernel they're meant to protect. They can shorten response time, but they can't prevent a shared-kernel escalation architecturally.
How does Edera fit into a defense-in-depth stack? Upstream scanners and signed images handle build-time risk. Edera operates at the runtime execution layer, running containers and pods inside hardware-isolated Zones so runtime zero-days and unpredictable agent behavior stay contained.
-3.avif)