The AI Sandbox Market Just Got a Hyperscaler Problem

In October 2025, AWS shipped AgentCore Code Interpreter and the agent-sandbox category had its first hyperscaler entrant. By May 2026, it had five. Vercel Sandbox went GA on January 30. NVIDIA OpenShell shipped at GTC in mid-March. Cloudflare's Sandbox SDK reached general availability at Agents Week in April. Google Agent Sandbox followed at Cloud Next in May. Four major clouds, one seven-month stretch, the same product: an isolated compute primitive for running code an AI agent wrote.

That's not a coincidence of roadmaps. It's what happens when a category that independents like E2B, Daytona, and Modal spent three years proving out gets big enough for the infrastructure incumbents to notice. And it changes the question a team building agent infrastructure should be asking — from "which vendor has the fastest cold start" to something the hyperscalers' own entry accidentally makes obvious: why is agent code execution a separate metered thing at all, when the same fleet already running your deployed app has spare, isolated compute sitting right there?

What five clouds actually shipped​

The offerings aren't identical, and the differences matter more than the "everyone has a sandbox now" headline suggests:

Two of those five details do more work than the rest of the table. AWS shipping first, seven months ahead of the pack, tells you this wasn't a sudden pile-on — it was a category AWS had already validated by the time the others followed. And Google's choice to publish Agent Sandbox as a portable Kubernetes SIG project, rather than a GKE-exclusive feature, is a tell worth sitting with: even the hyperscaler with the most reason to lock this to its own cloud decided the isolation boundary belongs in the deploy substrate, as a Kubernetes primitive, not as a proprietary API you call over the network.

The independents get squeezed from underneath​

The startups that built this category are still standing, but the ground moved. E2B and Daytona's compute rates landed on the identical number: $0.0504 per vCPU-hour and $0.0162 per GiB-hour. That's not two vendors converging by coincidence — it's what a commoditized compute-metering floor looks like once the input costs (cloud VM pricing) are the same for everyone and the differentiation has to come from somewhere else.

Where it comes from, this cycle, is milliseconds and business model, not price:

• Cold starts. Daytona benchmarks around 90ms; E2B around 150ms. A real gap, but one measured in the range where a hyperscaler's own snapshot mechanisms (Cloudflare's warm-start snapshotting, Vercel's persistent Sandbox storage) are closing fast.
• Billing shape. Daytona is pure usage-based, billed per second. E2B layers a $150/month Pro plan on top for 24-hour sessions and 100 concurrent sandboxes. Neither is cheaper on raw compute — the difference is which shape of bill a team prefers.
• Continued capital. Daytona raised a $24M Series A in February 2026 to expand its agentic-infrastructure platform — investors are still betting the independents can defend a lane. Whether that lane is "faster than a hyperscaler" or "not bundled inside one" is the open question.

None of that is a knockout blow to E2B, Daytona, or Modal — dedicated sandbox providers can still out-execute a hyperscaler's bolted-on offering on latency and developer experience for a while. Modal's pricing shows the same pattern from a different angle: its physical-core rate comes in lower than E2B's or Daytona's per-vCPU number, but only because Modal bills a physical core (roughly two vCPUs) as the unit, not because the underlying compute is meaningfully cheaper. Strip out the unit-conversion trick and the three independents are charging within a few percent of each other — which is exactly what you'd expect once the input cost (a cloud VM) is the same for everyone and there's no room left to compete on the sticker price.

That's the real signal in the pricing convergence. When three well-funded, differently-architected startups all land on the same compute-hour economics, the category has stopped being about who can source cheaper VMs and started being about who can avoid paying for a dedicated VM at all. "Which vendor is fastest" was always a question about a category that needed to exist as a standalone purchase. The hyperscalers' entry — bundling the same primitive into infrastructure teams already pay for — is what makes people ask whether it does.

Why pay per-sandbox when your deploy target already owns the compute?​

Here's the reframe the hyperscaler wave forces. Every one of the five offerings above is solving the same subproblem: give an AI agent an isolated place to run code that isn't your production environment, metered and billed as its own line item.

But if you're already running a Cluster API-managed fleet to host git-push deployments — the actual thing a PaaS does — that fleet already has the two ingredients a sandbox needs: isolated compute (each app gets its own namespace or node boundary, by construction) and capacity headroom (fleets are provisioned for peak, not average, load). An agent that wants to run a build, execute a test suite, or try a code change against the app it's about to deploy doesn't need a second vendor relationship with its own billing, its own network egress rules, and its own credential-injection story. It needs a scoped slice of the compute you're already paying for and already isolating.

Google's own framing supports this more than it undermines it. By shipping Agent Sandbox as a portable Kubernetes SIG project instead of a GKE-only API, Google effectively conceded that the isolation boundary is a cluster-level concern, not a hyperscaler-level product. If the biggest cloud in the category thinks the right home for this primitive is "wherever your Kubernetes cluster already is," that's the argument for building it directly into the fleet that deploys your app — not for adding a sixth vendor to evaluate.

There's a trust-boundary argument here too, and it cuts the same direction. AWS AgentCore's 2026 security research turned up DNS-exfiltration and credential-extraction paths in its managed sandbox network behavior; AWS's response was that the behavior was intended, with hardening guidance published after the fact. That's not a knock on AWS specifically — it's what happens whenever you hand agent-generated code execution to a third party: you've created a new trust boundary, with its own audit surface, that you don't control end-to-end. Every one of the five offerings in the table above asks you to trust a network egress policy, a credential-injection mechanism, and a data-retention story that lives outside your own infrastructure, on top of whatever isolation guarantees the underlying microVM or container runtime provides.

A self-hosted MCP server running agent tool calls inside your own cluster's RBAC and network policy doesn't remove the need for isolation — the agent's generated code still needs a sandbox boundary around it. What changes is where that boundary lives. The credentials the agent can reach, the audit log its actions write to, and the network policy governing what it can call out to all stay inside the boundary you already operate and already monitor, instead of a second one you have to separately evaluate, separately audit, and separately trust not to have a DNS-exfiltration path nobody's found yet.

What this means for a self-hosted MCP roadmap​

The practical shift is architectural, not philosophical: treat agent code execution as another workload on the same fleet that runs the deployed app, governed by the same namespace and network-policy boundaries, rather than a call out to a metered third-party API.

That's the model bex.co is built on — push a git repo, get a running HTTPS service on machines you own, with a Cluster API-managed fleet underneath. Because that fleet already exists to run your app, giving an MCP-connected agent a scoped, isolated slice of it for build/test/execution workloads is a scheduling decision, not a new integration. There's one trust boundary, one bill, and no second vendor whose sandbox network policy you have to separately audit. Star the repo on GitHub if a self-hosted, AI-native path through this is useful to you.

The stampede validates the primitive, not the vendor​

It's tempting to read five hyperscaler launches in seven months as proof that agent sandboxing is a hyperscaler's game now. Read the other way, it's proof the opposite is at least as true: the primitive got important enough that every major infrastructure provider decided they needed one — including the one, Google, that chose to ship it as portable Kubernetes infrastructure instead of a walled-garden API.

That's not an argument against independents, and it's not an argument for any one hyperscaler's bundle either. It's an argument for treating isolated agent execution as something your deploy substrate should already know how to do — because increasingly, according to the hyperscalers' own product decisions, that's exactly where it belongs.

Sources:

• Vercel Sandboxes are now generally available — Vercel Changelog
• Vercel Sandbox in the Main CLI: What Changed on April 8, 2026
• Agents have their own computers with Sandboxes GA — Cloudflare Blog
• Cloudflare Sandboxes Reach General Availability — InfoQ
• NVIDIA OpenShell — GitHub
• Securing AI agent workflows on Ubuntu with the new NVIDIA OpenShell snap — Canonical
• Google Announces GKE Agent Sandbox and Hypercluster at Next '26 — InfoQ
• Bringing you Agent Sandbox on GKE and Agent Substrate — Google Cloud Blog
• E2B Pricing Explained (2026) — Beam
• Daytona vs E2B vs Modal vs Vercel Sandbox: A 2026 Comparison — StartupHub.ai
• AI Agent Sandboxes Compared — Ry Walker Research