Evolution of Agentic AI: There Is No Runtime Moat to Buy (Part 3)
The thing everyone is being told to buy, an owned and isolated place for agents to run, is commoditizing on the same clock as everything else.
Part 3 of a 3-part series.
Start with Part 1 - Evolution of Agentic AI: What It Tells You About the Next 6-12 Months (Part 1)
Part 2 - Evolution of Agentic AI: The Payments Standards War Is Already Over (Part 2)
On April 7, 2026, researchers at Palo Alto Networks’ Unit 42 pulled data out of an AWS agent sandbox that was sold as sealed.
They didn’t crack the box open. They tunneled the data out through DNS, the internet’s phone book, one lookup at a time.
Picture smuggling a document out of a locked room by reading it aloud over the phone, one letter per call.
The walls held. The data left anyway.
After the disclosure, AWS updated its own developer guide for the service. “Complete isolation with no external access“ became “limited external network access.”
That one-line doc edit is the whole story of this article, in miniature.
In Part 2 I ended on a catch: the proof that an agent was allowed to spend your money is only as good as the runtime it executes inside, and you may not own that runtime.
The thing everyone is being told to buy, an owned and isolated place for agents to run, is commoditizing on the same clock as everything else.
And unfortunately it wouldn’t save you even if you owned it outright.
The clock is the same one from Part 1.
The same clock, one more time
Security looked like the one lane that stayed ahead. It didn’t.
Late in 2025, Anthropic open-sourced an operating-system-level sandbox for Claude Code: containment that cut agent permission prompts by about 84%.
That was the champion move, the rare capability nobody had cloned yet.
Then the clock ran, exactly like the first article said it would.
In April 2026, OpenAI added sandboxing to its Agents SDK (software development kit, the toolkit developers build agents on).
It didn’t build a runtime. It rents isolation from 7 interchangeable providers: Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel, all behind one abstraction layer so you can swap any of them out.
In June 2026, Microsoft put a kernel-level agent sandbox into Windows at its Build conference, with OpenAI and NVIDIA already onboard.
Champion, fast followers, commoditized.
Half a year, give or take. Same movie as tool-calling, memory, computer use, and payments.
ELI5: What is a “sandbox,” and what does it not do?
A sandbox is a walled-off space where a program can run without touching the rest of your machine. If the program misbehaves or gets hijacked, the damage is supposed to stay inside the walls. The catch this whole piece turns on: the walls stop something breaking out onto your computer. They don’t stop whatever’s inside from picking up a phone and talking to the outside world.
[ SCREENSHOT: the runtime clock — champion (Anthropic) → fast followers (OpenAI rents, Microsoft owns box) → the open-source commodity underneath — see Agent-Security-Runtime-Part3-2026-06-30-tables.html → Table 1 ]
The box everyone builds on is open-source
Nobody in that timeline invented their isolation technology. They’re all standing on the same open-source building blocks.
AWS’s sandbox runs Firecracker, the microVM that Amazon itself released under an open license (a microVM is a stripped-down virtual machine that boots in a fraction of a second, small enough to wrap around a single agent task).
Google’s runs on gVisor and Kata, two other open-source isolation layers. E2B, Modal, Daytona: the same handful of open building blocks underneath.
So let’s follow the logic from the first article to its end.
The isolation box is already at the donated-standard endpoint.
It’s free, it’s shared, and every “owned” runtime is a thin wrapper around a box anyone can download.
Which means the objection anyone who tracked Part 1 is already forming is correct. If every capability commoditizes, doesn’t the runtime commoditize too?
Doesn’t my own logic eat the “own the trust boundary“ advice I gave in the first two articles?
Yes. That’s the finding I’m writing on as I researched further.
Once the steel box got standardized, nobody got rich owning the box; the box was the commodity.
The money moved to the ports, the routing, the companies that controlled where the boxes could go.
Isolation is that box. Owning a commodity box is not a moat.
So if there’s no moat in the runtime, the instinct is to ask which layer to buy instead. But owning the box wouldn’t have protected you either.
Owning the box was never the safe part
Go back to the AWS leak. The sandbox did its job on the thing sandboxes are built for. The host wasn’t compromised. The walls held. The data still walked out through DNS.
A sandbox isolates the host, not the data.
The mental picture most people carry is a bank vault: get the agent inside, shut the door, sleep well.
The real picture is a soundproof room with a working phone in it. The room stops an intruder from breaking out into the rest of the building. It does nothing about the fact that whoever is in the room can still pick up the phone and read your secrets to someone outside.
A hijacked agent doesn’t need to break the walls. It needs an outbound line, and DNS is one that almost nobody blocks.
To be fair, this isn’t a law of physics.
You can cut the phone line: deny-by-default egress, no outbound DNS, an allowlist of the handful of endpoints the agent genuinely needs. A sandbox hardened that far would have stopped the AWS leak cold.
So the honest version of this isn’t that a sandbox can’t protect data. It’s that almost nobody ships one locked down that far, because the defaults leave DNS wide open.
But look at what that hardening is: an outbound policy tied to what this specific agent is allowed to reach. The moment you’re deciding egress by identity, you’ve stopped configuring a box and started running an enforcement point, which is the whole argument.
The protection was never the isolation. It was the policy you wrapped around it.
Security researcher Simon Willison named the dangerous combination the lethal trifecta:
an agent that can see private data,
can read untrusted content, and
can talk to the outside world.
Any agent with all three can be turned into a tool for leaking data, and the sandbox, as it ships, stops none of it.
It was built for a different threat.
The reason this keeps happening is that the attack that hijacks the agent can’t be patched away.
Prompt injection is the attack where a model reads some text (a web page, an email, a document) that contains hidden instructions and follows them as if they came from you. It’s the front-desk clerk who gets handed a forged note “from the manager” and does what the note says, because to the model, instructions and data are the same stream of words.
OWASP, the group that tracks the top security risks for AI systems, ranks it the #1 risk. Separate industry tracking, a Center for Internet Security report, clocked a roughly 340% year-over-year rise in reported prompt-injection attempts.
And the defenses don’t stop it.
A 2025 paper titled “The Attacker Moves Second” (a rare joint effort from OpenAI, Anthropic, and Google DeepMind) tested 12 published defenses, beat all 12, most at over a 90% success rate, and a human red team (people paid to break in) got through essentially every time.
Meta reached the same conclusion from the other direction and published an “Agents Rule of Two”: don’t let an agent handle untrusted content, hold sensitive data, and act on the outside world all in the same session.
Pick two, because all three at once is the combination nobody can secure.
That’s why the better defensive work isn’t about better walls.
Google DeepMind’s CaMeL approach splits the agent into a privileged planner that never sees the untrusted text and a quarantined worker that does, with a checker in between deciding what’s allowed to leave. It treats the agent’s own output as untrusted by default.
That’s a different bet than “buy a stronger box,” and it’s the direction the research is pointing.
Put the two findings together and the “own the runtime“ advice collapses from both sides at once. The box commoditized, so owning it is no advantage. And the box was never what kept you safe, so owning it was never the point.
Where the moat went
The defensible thing didn’t disappear. It slid one more rung, the same move I traced in Part 1 and Part 2: features, to the trust boundary, to identity.
Two things, and they’re linked.
First: the enforcement point
The layer where containment is on by default and tied to who the agent is. Not a sandbox you remember to switch on, but the operating system, the cloud control plane, or the coding tool the agent already runs inside, where every action gets checked against an identity before it’s allowed.
That’s the difference between a lock you have to install and a front desk that checks every guest whether you thought about it or not. Microsoft’s real asset in that Build announcement wasn’t the sandbox. It was that the sandbox is wired to Entra and Intune, the identity and device layer enterprises already run.
The box is the giveaway. The enforcement point is what they kept.
Second: identity itself
The thread Part 2 handed forward: proving a specific human authorized this specific agent to do this specific thing, with a record when it goes wrong.
NIST, the US federal standards body, stood up an AI-agent identity effort in early 2026 and proposed retrofitting the twenty-year-old machinery behind “log in with Google” rather than inventing something new.
FIDO, the standards group behind the passkeys slowly killing the password, opened a working group to verify an agent is acting for an authenticated user. Identity is starting at the standards-body endpoint and skipping the champion phase entirely.
ELI5: What does “identity-bound” containment mean?
Today most sandboxes are a wall around the code. Identity-bound containment adds a name tag: this agent is acting for this person, allowed to do these things, and every action gets checked against that before it runs. OAuth and OpenID Connect are the old standards behind “log in with Google”; SPIFFE gives a piece of software its own verifiable ID badge. The pitch from NIST and FIDO is to bend those proven tools to fit agents instead of inventing new ones.
[ SCREENSHOT: owns-the-box vs. rents-it across OpenAI, AWS, Google, Microsoft, and what each controls (the enforcement point is the highlight) — see Agent-Security-Runtime-Part3-2026-06-30-tables.html → Table 2 ]
There’s a regulatory push in the same direction, and it lands hardest on anyone holding regulated data.
The EU AI Act’s Article 12 requires high-risk AI systems to keep automatic logs of what they did, so there’s an audit trail after the fact, with enforcement of that tier arriving in August 2026.
A rented sandbox that hands the logs to your provider is a weaker answer to that than an enforcement point you control, with egress (the agent’s outbound network access) you can see and cut. This is the data officer’s version of the whole argument: the expensive failure isn’t the host getting popped, it’s an agent quietly leaking customer data with no record you can stand behind.
In practice: a hospital running agents against patient records doesn’t lose sleep over whether the microVM holds. It loses sleep over an agent that reads a poisoned document, pulls a batch of records, and ships them out over a channel nobody was watching, with no log to reconstruct what happened.
The sandbox is silent on all three. The enforcement point and the audit trail are the entire answer.
None of this is theoretical, and I traced the ground-level version in the 2026 attack taxonomy.
Poisoned packages that models hallucinate into existence and attackers pre-register (slopsquatting), and the Semantic Kernel bug that turned a prompt into remote code execution (RCE, an attacker getting to run their own commands on your machine): both proved the same thing that keeps proving out, that the model is not a security boundary.
You don’t fix that by renting a nicer box to run the model in.
What I’d do next
I’d stop shopping for an agentic AI runtime differentiator. There isn’t one to buy, and the piece you’d be buying wouldn’t have saved you.
The isolation box is a commodity, so I’d rent it knowingly, the way OpenAI does, and I wouldn’t pay a premium for “owned.”
The providers are already swappable. Treat them that way.
What I wouldn’t rent is the enforcement point or the identity layer.
That’s the part that stays valuable no matter who supplies the box: containment that’s on by default and bound to an identity, deny-by-default egress so a hijacked agent can’t phone out, and an audit trail you hold rather than one your landlord keeps.
Rent the runtime and its logs, and you’ve handed your audit trail to a vendor, which is exactly how your regulator will treat it.
One concrete move, same shape as the one I left you with in Part 2: ask whoever’s selling you an agent runtime, in writing, 3 questions.
When my agent gets prompt-injected and tries to leak data
What stops the outbound connection, and
Who holds the log that proves it happened?
If the answer is “the sandbox,” they’re selling you the box. If it names an identity and an egress policy you control, they’re selling you the part that matters.
Keep in mind, the big players who own identity today (Microsoft Entra, Okta, the card networks) have every reason to keep it closed, and identity standards have a long history of not lining up cleanly.
If they don’t, the enforcement point isn’t a moat anyone can buy either. It’s just a bill.
So here’s the question I’m left with, three articles in.
Every capability across this series (tool calling, computer use, payments, now the runtime) ended the same way: copied in days, donated in a year, free by the end. If the box your agents run inside was the last thing you thought was defensible, and it’s already a commodity that never kept you safe anyway, then what’s left to own is smaller and stranger than a product.
It’s the proof of who’s allowed to do what, and the record when they don’t.
No vendor sells you that. You have to hold it yourself.
References:
Anthropic open-source sandbox for Claude Code (~84% fewer permission prompts, November 2025): anthropic.com/engineering
OpenAI Agents SDK sandboxing, renting isolation from seven providers (Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel; April 16, 2026): openai.com
Microsoft kernel-level agent sandbox (MXC) in Windows, wired to Entra + Intune (Build 2026, June 2, 2026; OpenAI and NVIDIA onboard): blogs.windows.com
AWS Bedrock AgentCore Firecracker isolation, and Unit 42 DNS-tunneling exfiltration; AWS reworded “complete isolation with no external access” to “limited external network access” (April 7, 2026): Unit 42 / Palo Alto Networks
Google Vertex Code Execution / GKE Agent Sandbox on gVisor + Kata: cloud.google.com
Firecracker (Apache-2.0), gVisor, Kata open-source isolation projects: firecracker-microvm.github.io · gvisor.dev · katacontainers.io
“The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections” — 12 defenses bypassed, most at >90% success; human red team ~100% (OpenAI, Anthropic, and Google DeepMind; October 2025): arXiv:2510.09023
Meta “Agents Rule of Two” (containment design rule, October 31, 2025): ai.meta.com
Google DeepMind CaMeL, “Defeating Prompt Injections by Design” (privileged planner + quarantined worker + checker): arXiv:2503.18813
OWASP LLM Top 10, prompt injection as the number-one risk (LLM01): owasp.org
Center for Internet Security, roughly 340% year-over-year rise in reported prompt-injection attempts (2026): cisecurity.org
Microsoft Security, “When prompts become shells” — Semantic Kernel RCE, “your LLM is not a security boundary” (May 7, 2026): microsoft.com/security/blog
Slopsquatting (Spracklen et al., recurring hallucinated-package rate): arXiv:2406.10279
NIST / NCCoE concept paper on adapting OAuth, OpenID Connect, and SPIFFE for AI-agent identity (February 5, 2026): csrc.nist.gov
FIDO Alliance Agentic Authentication working group (announced April 28, 2026): fidoalliance.org
EU AI Act automatic event-logging for high-risk AI systems (Article 12; enforcement August 2, 2026): eur-lex.europa.eu