Four hyperscaler agent sandboxes, four different isolation primitives

Now that all four major public clouds have shipped a managed agent sandbox, they have also confirmed there is no shared blueprint for one. That is the argument The New Stack lands in a survey piece published on July 24, using Google Cloud's Cloud Run sandboxes public preview, announced at the WeAreDevelopers World Congress earlier this month, as the news peg.

The short version, per the survey: AWS, Google Cloud, Microsoft Azure and Cloudflare each offer a service that will run code produced by an AI agent under isolation the vendor manages for you. Each one is a different product. Each one, the piece argues, is built on a different foundation. That fragmentation is the story.

What "agent sandbox" is trying to do

Set aside the marketing labels. The problem all of these products address is the same. An AI agent generated some code, and something needs to execute it without handing over the developer's credentials, the developer's filesystem, or the cluster the developer's laptop is signed into.

Traditional CI runners were designed to run code humans wrote and reviewed. A code generator does not necessarily produce code anyone read before it ran.

The choice that separates the products is which isolation layer sits between the agent-authored code and the host. It is the same choice CI engineers have been making for years for build isolation: containers, microVMs, syscall-filtering runtimes, WebAssembly, or a JavaScript-runtime isolate. Every option is a different trade between startup latency, blast radius, and how much of the host kernel the guest gets to see.

The New Stack's read is that the four hyperscalers each picked a different point on that curve. The piece does not frame that as a coordination failure. It frames it as inevitable: each vendor already had a runtime it trusted at scale, and the fastest path to an agent sandbox was to wrap that runtime in a new API.

Why a CI/CD team should care

Three practical concerns fall out:

1. Queueable resource. A sandbox is now a queueable resource in your pipeline the same way a runner is. If you have wired an AI coding agent into a build or a test step, the pod or the container that used to hold the agent is no longer the isolation boundary. The sandbox is. Which cloud you picked determines what that boundary looks like and what it costs.

2. Portability. Sandboxes running on different primitives expose different limits: what languages start fast, whether outbound network is on or off by default, whether persistent state survives a session, what kind of filesystem the guest sees. A workflow that runs cleanly under one vendor's sandbox is not automatically portable to the next.

3. Audit trail divergence. Some primitives produce cleanly attributable per-invocation logs. Some pool workers behind a shared runtime. Some let you attach a per-agent identity, some do not. If you have to prove after the fact which agent did which thing, the vendor choice stops being a footnote.

The bit the survey does not resolve

None of this decides which primitive is right for a CI/CD team building an agent pipeline today. The New Stack names the fragmentation. It does not close it. There is no cross-vendor sandbox spec, no open contract that lets a team write the sandbox once and target four backends. The trade-offs are real, and the vendors have no obvious incentive to normalise them.

The pragmatic move for now is to treat the sandbox as a first-class choice at the same design level as your runner class or your registry. Wire your pipeline to the primitive whose isolation, cost profile and audit trail match the trust boundary you actually need. Then plan for the day you have to move.