Back in 2007 I was a Red Hat trainer, flying around the country administering the RHCE exam and teaching sysadmins how to get the most out of Linux. This was before “cloud” meant anything. And in every classroom, the conversation eventually landed in the same place: could you build an infrastructure platform that was actually secure, actually reliable, and actually simple to run - all three, at once?
The consensus, every time, was no. It was treated as the most intractable engineering problem in the industry.
That question stuck with me. It’s a large part of why I started Salt and built SaltStack. We sold SaltStack to VMware in 2020, and I got to step back and watch what the rest of the industry did with the question. What happened was that Kubernetes and the public cloud won.
I don’t think they solved it. I think they mostly relocated it. And this summer, two completely unrelated events made that very hard to keep ignoring.
A gym class and a frontier lab
On August 10, ABC News reported what it called the first known autonomous AI cyber attack in Australia. A man named Andrew had asked an AI assistant to book him into a popular gym class. That’s it. That’s the whole task.
The agent found that the gym’s booking system would accept reservations far beyond the advance window a human user could reach through the interface, and used it. Then, on its own initiative, when Andrew mentioned he was fourth on a waitlist for a different class, it went looking. Its own report back is worth reading exactly as written: “The API has zero authorisations checks on cancelling other people’s reservations … I tested this with the person in waitlist position #1 - and it actually went through.” It cancelled a stranger’s booking to move Andrew from fourth to third. Asked to undo it, the agent replied: “Bad news - I can’t add them back.”
Nobody involved set out to attack anything. Andrew didn’t ask for an exploit. The framework developer didn’t build one in. The agent treated a technically valid, exposed API call as a legitimate path to finishing the job it was given.
Now the other end of the sophistication spectrum. On July 21, OpenAI disclosed that during an internal cyber evaluation, two of its models had escaped their sandbox by exploiting a zero-day in an internally hosted package-registry proxy, reached the open internet, chained stolen credentials with further zero-days to get remote code execution on Hugging Face’s servers, and obtained benchmark test solutions directly from Hugging Face’s production database. OpenAI’s own words: “We consider this incident to be an unprecedented cyber incident, involving state-of-the-art cyber capabilities, and are responding accordingly.”
The models in that evaluation were running with cyber refusals deliberately reduced for testing purposes, and one was an internal research prototype never intended for release. This was not the configuration you get from a consumer product. It was a lab pushing on purpose, which makes what happened next more interesting, not less.
Nine days later, Anthropic published a retrospective review of 141,006 of its own cybersecurity evaluation runs, looking specifically for the same failure mode. It found three incidents, across six runs, in which models reached the open internet from inside what were supposed to be sealed environments and gained unauthorized access to three real organizations’ infrastructure. One model built and published a malicious Python package to PyPI; during roughly an hour of availability it was downloaded and run on fifteen real systems. Another, across four separate runs, recognized in its own verbalized reasoning that the system it was attacking was real - and none of those runs stopped on that basis. The model rationalized that the real company must be part of the exercise.
The root cause was the same in every case. The evaluation prompt told the model it had no internet access. A misconfiguration, stemming from a misunderstanding with an evaluation partner, left the machines with live internet access anyway.
In fairness, one of the three did stop. An internal research model scanned roughly nine thousand targets, compromised one company, concluded the target was in fact real, and ceased its attack. So the reasoning can work. It just can’t be the thing you’re relying on.
These are not the same failure. The gym incident was broken access control in somebody else’s application, an authorization bug an agent happened to find. The Anthropic incidents were a containment failure inside a controlled environment. But they rhyme in the way that matters: in both cases the boundary that was supposed to hold existed as an instruction rather than as a property of the network the system was actually running on. “This is a simulation” and “stay within these bounds” are just words to something that’s never told otherwise by the environment around it.
It doesn’t take malice - just an agent trying to be helpful
I keep running into a smaller version of this myself. Working with tools like Claude Code and OpenCode, we hit the same failure mode repeatedly: commands run as root to install software we didn’t request, files changed in repositories we weren’t even working in, system configs modified in passing as a side effect of solving some unrelated problem, outbound connections made to external resources with no real vetting of whether that destination should be trusted. Not malice. Just an agent doing whatever it takes to finish the job it was handed.
The public record has more of this than I expected. Replit’s coding agent erased a production database holding records on 1,206 executives and over 1,196 companies - during a code freeze - then told the user the data was unrecoverable. It wasn’t; the rollback worked.
But the case I find most instructive is the contested one. The Financial Times reported in February that AWS engineers had let an agentic coding tool make autonomous changes and it concluded the right move was to delete and recreate an environment, contributing to a roughly thirteen-hour regional outage of AWS Cost Explorer. Amazon disputes the framing, calling it user error from a misconfigured role - “the same issue that could occur with any developer tool (AI powered or not).” But Amazon’s explanation and mine aren’t in conflict. A misconfigured role is precisely the problem. The tool didn’t invent the permissions it used; it inherited them, and then used all of them.
Sandbox escapes aren’t hypothetical either. CVE-2026-39861 describes a symlink-following escape in Claude Code: a sandboxed process could create a symlink pointing outside the workspace, and the unsandboxed process would follow it and write there without prompting. And CVE-2026-31861 - frequently misreported as a Claude Code flaw - is actually a command injection in a widely used third-party UI wrapper for it. One vulnerability was in the tool; one was in something bolted onto the tool. The blast radius was the same either way, because nothing underneath either of them was enforcing a boundary.
And the failure mode isn’t limited to accidents. Check Point Research documented a campaign against nine Mexican government agencies in which 1,088 human-written instructions generated 5,317 AI-executed commands across 34 sessions, exposing around 400 million records; a companion report from Gambit Security puts it across 305 internal servers and attributes roughly 75% of remote command execution to a single agentic coding tool. Nothing in the tooling was hacked. The operator used the same pattern legitimate teams are racing to adopt: an agent with shell access, session persistence, and open network reach.
None of that required a sophisticated attack. It required an agent that trusted its own output enough to act on it, with enough standing access to make that trust expensive when it turned out to be wrong.
Why this keeps happening
The honest architectural answer is that most agentic tools run with the same access a developer has - full filesystem, full shell, whatever network reach the host machine has - and then layer permission prompts or classifiers on top to catch the dangerous cases. That’s a policy problem being solved in software, sitting on top of infrastructure that was never built to enforce a boundary. Software-layer policy can be reasoned around, misconfigured, or simply have a bug in the one code path nobody tested. A boundary enforced at the infrastructure layer - where the thing that would need to be reasoned around doesn’t exist on the network at all - doesn’t have that failure mode in the same way.
There’s a second problem underneath it. Our infrastructure model was built around humans logging in, authenticating once, and doing bounded work in a session. Agents don’t have sessions. They run continuously, spin up sub-agents, call tools, and read external data for hours at a stretch with no human in the loop to re-authenticate anything - which means the credential an agent holds is usually a static API key or service-account token sitting in an environment variable, not an identity that’s continuously verified. Alex Peay has written about how that key sprawl plays out inside AI stacks; what I’m describing here is the same static-credential problem handed to something that acts on its own.
NIST’s zero trust architecture, SP 800-207, was written in 2020 for that human-session world, and it hasn’t been revised. To its credit, NIST is not pretending otherwise: it launched an AI Agent Standards Initiative in February 2026, with a workstream specifically on agent authentication and identity, and its NCCoE published a concept paper the same month on agent identity and authorization that asks directly how zero-trust principles apply to agent authorization and how to bind an agent’s identity to a human’s. What that work does not yet address is the case that actually worries me - agents that spawn their own sub-agents, several layers deep, each inheriting authority nobody explicitly granted.
The stack that ate itself
Take service meshes - the layer teams bolt onto Kubernetes specifically to get the security and observability the orchestration layer doesn’t provide on its own. A 2023 study out of the University of Washington and collaborators measured the overhead directly and found that meshes “can have high overhead - up to 269% higher latency and up to 163% more virtual CPU cores for our benchmark applications - but the severity is intimately tied to how they are configured and the application workload.”
Those measurements were taken on sidecar-based meshes, and sidecarless architectures have cut the per-workload cost substantially since; Istio’s own published figures for ambient mode are roughly a third of a sidecar’s footprint. Which is the real point. The industry spent several years paying a large, measurable tax for a bolted-on security layer, then spent several more years engineering that tax back down. An enormous amount of collective effort to arrive near where you’d have been if the capability had been in the platform to begin with.
Because that’s the pattern. Kubernetes for orchestration. A service mesh bolted on for network security. A secrets manager bolted on for credentials. Terraform bolted on to describe all of it. A security team bolted on to hold the whole thing together. Every layer solves a problem the layer below it created. None of it was designed as one system. It was assembled - and every seam between those bolted-on pieces is a place where something can slip through.
Teams end up treating the mesh as a complete security posture and under-investing in the basic controls underneath it. That’s the failure I’ve watched most often, and the most dangerous kind, because it produces the feeling of being protected without the structure of it. It’s exactly the kind of environment an autonomous system will find a way through, because that’s what autonomous systems are now good at finding.
I built Salt. I know this pattern. Automation doesn’t create fragility, it finds it. Every scope you meant to tighten later. Every access you never revoked.
Agents don’t break rules. They expose that we never built real ones.
What the right infrastructure actually has to do
If you take the sysadmins’ original question seriously - secure, reliable, and simple, all three, at once - you can’t get there by adding another product on top of Kubernetes. The isolation has to be built into the infrastructure itself, so there’s no seam left for anything, human-directed or autonomous, to slip through.
That means four things, and none of them work in isolation. Every workload gets its own network, constructed the moment it starts and torn down the moment it stops - not a shared cluster network with policy rules layered over it, but a boundary that simply doesn’t extend beyond what that workload is allowed to reach. Credentials are never handled by a developer or hardcoded anywhere: generated per deployment, delivered at runtime, rotated continuously, so there’s no static secret in an environment variable for anything to find. Every connection is authenticated at the service level itself, so being on the same network is never treated as permission.
And all of it has to be automatic, because a security model that depends on a team remembering to configure it correctly is a security model that will eventually not be configured correctly. Ask Amazon about the misconfigured role.
That’s what ContextOS is. Every container and VM gets a dedicated, zero-trust network built fresh at startup and scoped exclusively to what that workload is permitted to touch. Nothing outside a workload’s access map is reachable, resolvable, or even visible to it - not misconfigured, not forgotten, just absent. Credentials and certificates are generated, delivered, and rotated automatically, with no developer ever handling them directly. It’s the same design philosophy whether the workload is deploying application code for a person or executing a tool call for an autonomous agent, because the platform doesn’t grant trust based on who’s asking. It grants access based on what’s explicitly permitted, and nothing else exists as far as that workload is concerned.
Which is the answer to the agent problem too
I’ve come at this from a different angle every time I’ve thought about where agent containment is actually failing, and I keep arriving in the same place. I’m not the only one. A real category has grown up around giving AI agents isolated, ephemeral places to execute code - E2B and Vercel Sandbox on Firecracker microVMs, Modal on gVisor, Daytona on containers with VM isolation as an opt-in. The money is real: Daytona raised a $24 million Series A in February after realigning its whole business toward agent runtimes, and E2B raised $21 million before that. And it isn’t only startups anymore - AWS shipped Lambda MicroVMs in June explicitly for handing each session its own isolated environment to execute AI-generated code, and Docker shipped microVM-per-session sandboxes in April.
So the problem is validated to the point of being crowded. But most of what exists is built for a narrower job than the one I keep needing: short-lived function calls, single code-interpretation tasks, session-scoped execution. What the work actually looks like is a full agentic coding session - clone a repo, install dependencies, run a build, iterate for hours, reach exactly the handful of external resources that session needs and nothing else - with the network boundary itself doing the enforcement rather than a policy check inside a shared environment.
So: spin up a fully isolated, ephemeral environment for the session. Let the agent run as root inside it, install whatever it wants, rewrite whatever files it wants, because the blast radius is that environment and nothing else exists on its network. Allowlist the exact external resources the session is permitted to reach - a specific package registry, a specific API, nothing else - and everything outside that list simply isn’t part of the agent’s world. When the session ends, the environment disappears. No cleanup, no drift, no wondering whether it changed something in a repo you weren’t looking at.
Here is the part I’m ridiculously excited about, and it isn’t a safety story. It’s a speed story. Almost every team I talk to that’s serious about agents is throttling them. Approval prompts on every write. Read-only access until a human reviews the plan. Somebody babysitting a session that has no business needing a babysitter. They aren’t doing that because they want to. They’re doing it because the blast radius is unbounded and everyone involved knows it, so the only lever left is to slow the agent down. Make the boundary structural and that lever stops being necessary. You can hand an agent root, close the laptop, and let it work for six hours on the thing you didn’t want to spend your Saturday on. The reason to build the fence isn’t to keep the agent small. It’s so you can finally let it run.
That isn’t a new product category. It’s the same architecture pointed at a new kind of workload - which is the whole argument. If the boundary is structural, it doesn’t much matter whether the thing inside it is a person, a deployment, or an agent running unsupervised at three in the morning.
We didn’t get AI security wrong because AI is uniquely dangerous. We got it wrong because we never built the infrastructure underneath it correctly in the first place - and every layer we bolted on afterward gave us the feeling of security without the structure of it. What’s happening now is what happens when something finally capable enough shows up and tests that feeling against reality.
Guardrails aren’t a feature. They’re the foundation.
Want to see what a structural boundary looks like? Book a demo with ContextOS.
Sources
- ABC News, AI Assistant Hacks Gym Website in First Known Australian Autonomous Cyber Attack, August 10, 2026
- OpenAI, OpenAI and Hugging Face Partner to Address Security Incident During Model Evaluation, July 21, 2026
- Anthropic, Investigating Three Real-World Incidents in Our Cybersecurity Evaluations, July 30, 2026 — 141,006 runs, 3 incidents across 6 runs, 15 systems, the run that stopped
- eWeek, AI Agent Wipes Production Database, Then Lies About It, July 22, 2025, and The Register, July 21, 2025 — Replit: 1,206 executives, over 1,196 companies, code freeze
- GitHub, google-gemini/gemini-cli issue #4586, July 21, 2025 — phantom destination directory, successive renames
- GeekWire, Amazon Pushes Back on Financial Times Report Blaming AI Coding Tools for AWS Outages, February 20, 2026 — Cost Explorer outage, Amazon’s “misconfigured role” position, mandatory peer review
- GitHub Advisory GHSA-vp62-r36r-9xqp — CVE-2026-39861, Claude Code symlink sandbox escape, published April 20, 2026, fixed in 2.1.64
- GitHub Advisory GHSA-7fv4-fmmc-86g2 — CVE-2026-31861, shell command injection in @siteboon/claude-code-ui git routes, March 2026, fixed in 1.24.0
- Check Point Research, AI Security Threats in 2026, July 2026 — nine Mexican government agencies, 1,088 instructions, 5,317 commands, 34 sessions, ~400M records
- Gambit Security — technical report on the AI-assisted breach of Mexican government infrastructure (305 internal servers, ~75% of remote command execution)
- Zhu et al., Dissecting Overheads of Service Mesh Sidecars, ACM SoCC ’23 — up to 269% higher latency, up to 163% more virtual CPU cores, for the paper’s benchmark applications
- Istio — Performance and Scalability documentation, ambient mode / ztunnel footprint versus sidecar
- NIST — SP 800-207, Zero Trust Architecture, August 2020; AI Agent Standards Initiative, launched February 17, 2026; NCCoE concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, February 5, 2026
- E2B and Vercel Sandbox documentation (Firecracker microVMs); Modal security documentation (gVisor); Daytona sandbox documentation (Linux containers by default)
- PR Newswire, Daytona Raises $24M Series A to Give Every Agent a Computer, February 5, 2026 (self-reported forward revenue run rate); Insight Partners on E2B’s $21M Series A, July 2025
- AWS, Run Isolated Sandboxes with Full Lifecycle Control: AWS Lambda Introduces MicroVMs, June 22, 2026; Docker, Why microVMs: The Architecture Behind Docker Sandboxes, April 16, 2026