Scout: Sandbox-Per-Task Primitives Compared — GKE Agent Sandbox, Cloudflare Dynamic Workflows, Claude Code Auto Mode

In Brief

• Three sandbox-per-task primitives converged in the week of May 1 to May 8, 2026, at three different layers (only Cloudflare Dynamic Workflows is a new ship; Google’s managed GKE Agent Sandbox was announced at Next ‘26 on April 22 over an upstream project launched in November 2025 and drew its trade coverage in the window, and Claude Code Auto Mode has been a research preview since March 24): GKE Agent Sandbox isolates the process running the agent’s code, Cloudflare Dynamic Workflows isolates the durable plan a tenant’s agent wrote, and Claude Code Auto Mode gates each tool call that reaches its classifier (shell commands, web fetches and out-of-project writes; allowlisted reads and in-project edits bypass it).
• They compose rather than compete: Auto Mode stacks on top of either of the other two, and a team running adversarial-input agents on Claude needs all three answers (host isolation, tenant isolation, per-action permission) rather than one.
• The GKE headline numbers (300 sandboxes per second at sub-second latency) attach to Google’s managed offering; the CRDs themselves are the Apache-2.0 upstream kubernetes-sigs/agent-sandbox project, which installs on any conformant cluster but without Pod Snapshots or the Axion tuning.
• Dynamic Workflows is ~300 lines of MIT-licensed TypeScript over V8 isolates, purpose-built for keeping one tenant’s plan state away from another’s; Cloudflare itself acknowledges that V8 security bugs are more common than hypervisor bugs, so kernel-escape threats need Cloudflare Sandboxes or Agent Sandbox underneath it.
• Auto Mode’s Sonnet 4.6 classifier posts a 0.4% false-positive rate on real traffic and a 17% false-negative rate on Anthropic’s own set of real overeager actions; the cited stress test measured 81% on a synthetic adversarial workload. Anthropic frames Auto Mode as an improvement over --dangerously-skip-permissions rather than as a security boundary, so blast-radius planning should assume the classifier misses, at a rate that depends on who is feeding it.

Why This Matters

Sandbox-per-task is the dominant production pattern for running untrusted agent code, and three of the four credible vendor implementations converged in one news week: Cloudflare shipped Dynamic Workflows on May 1, Google’s managed GKE Agent Sandbox, announced at Next ‘26 on April 22, got its InfoQ write-up on May 7, and Anthropic’s Auto Mode, a research preview since March 24, drew a week of independent coverage. For a team building agent infrastructure in mid-2026, the useful question is which combination of these primitives to stack, because each one protects against a different threat. The findings below take each primitive in turn, then compare what the vendors bill for and the architectural shape all three share.

Key Findings

The three primitives isolate three different things, so they stack rather than compete

Each primitive treats a different thing as its unit of isolation:

GKE Agent Sandbox is the layer where you decide what process the untrusted code runs in. Dynamic Workflows is the layer where you decide whose durable plan executes next. Auto Mode is the layer where you decide whether this specific tool call gets to run at all. A team running adversarial-input agents at production scale on Claude has to answer all three questions: host isolation, tenant isolation and per-action permission.

The illustrative stack: GKE Agent Sandbox pods running per-session containers, each container running Dynamic Workflows-style per-tenant code, each tenant’s agent calling tools through Auto Mode classifiers. No single vendor ships that defense-in-depth shape end to end. The week’s news is three layers of one stack coming into view at once, not three competing solutions to one problem.

Agent Sandbox is an upstream Kubernetes project; Google’s version is the managed offering on top

The headline hides an upstream fact. The kubernetes-sigs/agent-sandbox subproject is an Apache-2.0-licensed Kubernetes SIG Apps project, launched at KubeCon Atlanta in November 2025. Its four CRDs (Sandbox, SandboxTemplate, SandboxClaim and SandboxWarmPool) install on any conformant Kubernetes cluster via standard manifests.

The project documentation explicitly emphasises vendor neutrality: “Interoperability is core to Agent Sandbox with a standardized Kubernetes API that fully decouples the execution layer from the underlying isolation technology.”

What Google ships at Cloud Next ‘26 is the managed version on GKE, with three GKE-specific accelerants on top of the upstream primitive:

• Managed gVisor on GKE Sandbox — Google’s gVisor is the same kernel-isolation technology securing Gemini, operationally mature at Google scale.
• Pod Snapshots — a GKE-exclusive feature announced in limited preview at Next ‘26 and generally available since May 6, 2026 on GKE 1.35.3-gke.1234000 or later, that captures both memory state and filesystem, taking pod startup “from minutes down to seconds” per Google’s framing. Pod Snapshots is not in the upstream project.
• Axion price-performance — Google claims up to 30% better price-performance on Axion compared to other hyperscale clouds for sandbox workloads.

The headline performance numbers attach to the managed offering, not the upstream code. The 300 sandboxes per second at sub-second latency figure is achievable on GKE with warm pools and Axion. A self-hosted Agent Sandbox install on a non-Google Kubernetes distribution gets the same CRDs, and gVisor or Kata isolation where the cluster supplies a configured runtime backend, but its cold-start and price-performance numbers are unlikely to match without comparable engineering investment.

The Lovable production-use quote from Fabian Hedin via InfoQ is specifically about the GKE flavour: “GKE’s cutting-edge sandboxing capabilities allow us to reliably scale to hundreds of secure sandboxes per second, ensuring we can seamlessly empower builders, even during massive, unpredictable demand.” Lovable’s production workload runs 200,000+ AI-generated projects daily on it.

If a team is committed to Kubernetes-native infrastructure but not to Google Cloud, Agent Sandbox is a credible upstream-OSS choice that installs on EKS, AKS or on-premises clusters. Pod Snapshots, the warm-pool-on-Axion price-performance and the production tuning behind 300 sandboxes per second are GKE-flavour accelerants the team has to replicate or do without. A team already on GKE gets the managed offering with the least operational work. A team on neither GKE nor Kubernetes wants neither version of Agent Sandbox, and that is where Cloudflare’s offering comes in.

Dynamic Workflows is ~300 lines of MIT TypeScript, and it sandboxes the tenant’s plan rather than the process

Dynamic Workflows is @cloudflare/dynamic-workflows on npm, MIT-licensed, roughly 300 lines of TypeScript, released May 1. It runs on top of Dynamic Workers, which Cloudflare’s post describes as in open beta on the Workers Paid plan. The insight it bakes in is that durable execution can be decoupled from deployment: the workflow code at execution time need not be the code that was there at deploy time.

Cloudflare’s framing for what this enables, verbatim per InfoQ’s coverage: “Say you’re building an app platform where the AI writes TypeScript for every tenant. Say you’re running a CI/CD product where each repository has its own pipeline. Say you’re using an agents SDK where each agent writes its own durable plan.”

The mechanism is straightforward. A Worker Loader sits between the Workflows engine and tenant code. When a tenant calls env.WORKFLOWS.create(...), the call goes through the Worker Loader, which tags the new Workflow instance with metadata identifying which Dynamic Worker to load. The engine persists that payload, and when it wakes to run the next step, it reloads the right tenant’s Dynamic Worker through the loader.

Per the Cloudflare post, tenants write standard Workflows code with no awareness of dynamic dispatch; the wrapping happens at the binding layer, not inside the tenant code.

This is not a kernel-level isolation boundary in the GKE Agent Sandbox sense. Dynamic Workers run as V8 isolates, the JavaScript engine underneath Chrome, with single-digit-millisecond boot times and a few megabytes of memory per isolate, around 100x faster and 10x-100x more memory efficient than a typical container.

Cloudflare acknowledges the security tradeoff and the defence-in-depth response: “security bugs in V8 are more common than security bugs in typical hypervisors,” per the Dynamic Workers post. So Cloudflare layers V8 isolates with a custom second-layer sandbox that cordons tenants dynamically by risk, hardware-MPK protection, Spectre defences and malicious-pattern code scanning, rather than Chrome-style per-isolate process isolation.

For genuinely adversarial agent code, code that may try to escape its execution environment, V8 isolates are a different threat-model bet than gVisor or Firecracker. For per-tenant code where the threat is mostly cross-tenant data leakage rather than kernel escape, V8 isolates plus Cloudflare’s defence in depth is the lightest sandbox the practitioner has access to.

Heavy workloads route through Cloudflare Sandboxes: container-based, full OS, snapshot-based wake. Sandboxes compose naturally with Dynamic Workflows. The lightweight per-tenant code lives in an isolate, and when a step needs docker build or a Postgres dependency, the workflow hops out to a Sandbox for that step. Sandboxes run on active-CPU pricing, billed in 10-millisecond increments at $0.000020 per vCPU-second and $0.0000025 per GiB-second, with idle time effectively free.

So Dynamic Workflows sandboxes the durable plan, not the process. If the agent’s threat model is “tenant A’s agent must not be able to read or modify tenant B’s workflow state,” the metadata-tagged Worker Loader pattern is purpose-built for that. If the threat is “the agent’s generated code could try to escape its execution environment,” Dynamic Workflows by itself isn’t the answer. Pair it with Sandboxes, or pick GKE Agent Sandbox for the underlying execution layer.

Auto Mode gates each classifier-eligible action, and its published 17% miss rate is the most-criticised number of the three

Anthropic’s Claude Code Auto Mode, first shipped as a research preview in March 2026 on Claude Team and now rolling to Enterprise and API, is the layer of the stack the other two don’t address. Where Agent Sandbox isolates the host and Dynamic Workflows isolates the tenant, Auto Mode isolates the individual action.

Before any tool call runs, a transcript classifier on Sonnet 4.6 evaluates the proposed call against more than twenty default block rules, grouped into four categories: destroy-and-exfiltrate operations, security-degradation moves, trust-boundary violations and bypass-and-shared-impact actions. It then permits the call, blocks it, or escalates to a human.

Two design decisions stand out. First, the classifier deliberately strips assistant messages and tool outputs before evaluation: it sees only user messages and the executable tool-call payload itself. Per Anthropic’s engineering post, this prevents the agent from generating “persuasive rationalizations” that would justify dangerous actions in its visible reasoning.

Second, the classifier runs a two-stage filter: a fast single-token yes/no first stage, with chain-of-thought reasoning only on actions Stage 1 flags for blocking; Stage 2 reviews Stage 1’s blocks, not its uncertainties. The optimisation is for cost and latency: most actions clear Stage 1 cheaply, and only flagged cases pay the CoT cost. It is also a precision-for-recall trade: Stage 1 alone posted an 8.5% false-positive rate and a 6.6% false-negative rate on the real overeager set, and the two-stage pipeline brings false positives down to 0.4% while raising false negatives to 17%.

The numbers Anthropic publishes are unusually transparent. After the full two-stage pipeline: a 0.4% false-positive rate across 10,000 real-traffic actions and a 17% false-negative rate on 52 curated real overeager actions, with a 5.7% false-negative rate on synthetic exfiltration prompts (n=1000).

Anthropic’s own framing on whether the 17% is acceptable, verbatim: “Whether 17% is acceptable depends on what you’re comparing against. If you are running --dangerously-skip-permissions, this is a substantial improvement. If you are manually approving every action carefully, it’s arguably a regression—you’re trading your own judgment for a classifier that will sometimes make a mistake.” That hedge carries the positioning. Auto Mode is offered as a middle path rather than a hardened security boundary: between manual approval, where users approve 93% of prompts, enough that the approval mechanism degrades into rubber-stamping, and the no-prompts mode that offers no protection at all.

Zvi Mowshowitz’s coverage reproduces that Anthropic paragraph rather than reaching the verdict independently; his own contribution is the practitioner reminder that the classifier “doesn’t look at file writes and edits inside the project directory”.

The three-tier permission framework around the classifier is the operationally important structure. Tier 1 is a built-in allowlist of read-only tools (file reads, code navigation) that bypass the classifier entirely. Tier 2 is in-project file operations, which proceed without classifier involvement because edits are “reviewable via version control”. Tier 3 is shell commands, web fetches, external integrations and out-of-project filesystem operations; these are the actions that reach the classifier.

The denial backstop is symmetric. Three consecutive denials, or twenty total within a session, and the agent halts and escalates to a human; in headless mode, the process terminates.

The criticism Auto Mode has drawn is sharp. Backslash Security’s analysis centres on the classifier’s deliberately restricted visibility: the guard sees only what the architecture exposes, and that exposure was narrowed by design so the agent’s reasoning cannot become a persuasion surface. Sophisticated prompt injection that manipulates the primary model into emitting clean-looking tool calls could pass the classifier. The reasoning-blindness that prevents persuasion is the same property that prevents detection of upstream manipulation.

Backslash’s overall position is that one model guarding another is preferable to a fatigued human, but that probabilistic security needs deterministic controls around it. That is consistent with Anthropic’s own positioning of Auto Mode as one layer in a defence-in-depth stack, not a standalone security boundary.

Auto Mode composes with the other two primitives rather than competing with them. If the agent is executing code in a GKE Agent Sandbox pod or a Cloudflare Sandbox, Auto Mode is still the right primitive for “should this rm -rf actually run inside the sandbox?” That 17% is Anthropic’s figure on 52 real overeager actions drawn from production traffic; the independent stress test discussed in Open Question 1 measured an 81.0% end-to-end false-negative rate on a synthetic adversarial workload, which its authors call a different workload rather than a contradiction. Neither figure is a general planning rate: 17% is what Anthropic measured on its production overeager set, and 81% is what adversarial inputs did to a similar architecture. The deployment posture is the same under either: not “trust the classifier to catch adversarial inputs” but “deploy the classifier alongside isolation that limits the blast radius when it misses.”

The billing unit tells you who each vendor expects to buy

The unit each primitive prices in is the most direct signal of who the vendor expects to deploy it.

GKE Agent Sandbox prices at $0. The add-on itself is free, and you pay for the underlying GKE resources (vCPU-hour, memory-hour and so on) that the sandbox pods consume. The implicit buyer is the platform team that already buys GKE capacity and treats the sandbox as a feature rather than a line item.

Comparable workloads on AWS price the sandbox as a separately billable line item: AgentCore Runtime at $0.0895/vCPU-hour and $0.00945/GB-hour, with a dedicated microVM per session and an eight-hour max compute lifetime (Firecracker underneath, per Dev.to’s write-up). AWS’s pricing structure makes the sandbox cost legible; GKE’s makes it invisible inside the cluster bill.

Cloudflare’s active-CPU pricing is the most agent-shaped unit of the three primitive families. The $0.000020 per vCPU-second rate belongs to Cloudflare Sandboxes (Containers pricing, the process-isolation layer); Dynamic Workflows itself bills on Workers Standard CPU time, requests and storage, where a workflow waiting on an API call or sleeping incurs no CPU time. Both charge for active CPU with idle time effectively free, which matches the agent’s actual work pattern: wake briefly, do a step, sleep. Most production agent workloads idle frequently, waiting on LLM responses or tool calls. For those, Cloudflare’s TCO can come in dramatically below per-session or per-vCPU-hour pricing. On the active rates alone the gap is about 20% (Cloudflare’s per-second rate works out to $0.072 per vCPU-hour against AgentCore’s $0.0895), and AWS’s AgentCore Runtime also charges only for active CPU within the session (“if your agent consumes no CPU during I/O wait, there are no CPU charges”); what remains is the session itself, which has overhead the Cloudflare model doesn’t.

Anthropic bundles Auto Mode with the plan. There is no separate line item; Auto Mode is a research-preview feature of the Claude Team plan, rolling to Enterprise and the API. The implicit buyer is the developer team already paying for Claude Code seats. The classifier has no separate line item, but Anthropic says Auto Mode “may have a small impact on token consumption, cost, and latency for tool calls”, so its tokens land in the user’s existing Claude usage; the two-stage filter design is what keeps that impact small, for the customer as much as for Anthropic.

The cross-vendor billing-unit comparison is starker now that all three are available. A team running an idle-heavy multi-tenant agent platform pays effectively zero for runtime on Cloudflare while sessions sleep, pays for the warm-pool capacity it provisions on GKE Agent Sandbox even when idle, and pays Anthropic for the Claude Code plan however much Auto Mode is exercised. None of these is a strictly better unit; they target different deployment shapes.

Three vendors converged on the same four-pillar shape in one news week

What the three primitives share architecturally matters more than what they differ on. All three implement some version of the four-pillar architecture GitHub formalised in its defense-in-depth piece the same week: Isolation, Constrained Execution, Controlled Outputs, Observability. GKE Agent Sandbox provides Isolation as a Kubernetes-native primitive. Dynamic Workflows provides Constrained Execution as a per-tenant code-loading mechanism. Auto Mode provides Constrained Execution and Controlled Outputs at the action-call level.

None of the three ships the Observability piece as a first-class primitive. GKE relies on its general Managed OpenTelemetry path into Cloud Observability, with nothing Agent-Sandbox-specific; Cloudflare on Workers logging and AI Gateway telemetry, Anthropic on the existing Claude Cowork OTEL integration.

When the same architectural decomposition surfaces at three layers from three vendors in the same seven days, it is no longer a research pattern. The platform layer has converged on sandbox-per-task as the default, and the convergence is on the shape, not on a specific implementation.

The primitives are now portable enough to mix and match: GKE Agent Sandbox underneath, Dynamic Workflows as the per-tenant code layer (if the team is willing to bridge Kubernetes and Cloudflare’s Workers tier, which is non-trivial), Auto Mode at the action layer if the agent is Claude Code. The full-stack composition is real, even if no single vendor sells it end to end.

The Code w/ Claude 2026 context deserves a brief mention. The Anthropic-SpaceX compute deal announced the same week, 300+ megawatts of new capacity, over 220,000 NVIDIA GPUs, within the month, doubled Claude Code’s five-hour rate limits across the Pro, Max, Team and Enterprise tiers. That is not a primitive in the sandbox-per-task sense, but it is the enabling capacity story for Auto Mode.

A classifier-gated long-running coding session that the old caps rate-limited out after an hour is now feasible. The practitioner pattern of “Auto Mode running for hours on a large task” is contingent on that compute capacity being there.

Whether the deal’s dollar value lives at the $5B/year figure circulating in trade-press analyst commentary is unsettled; Latent Space explicitly hedges this number as derived from secondary Twitter commentary rather than Anthropic’s own announcement. What’s confirmed is the megawattage and GPU count.

Practical Implications

Pick by layer, then compose

The decision shape differs from the registry-and-runtime comparison earlier this spring. There, the offerings were largely substitutes: pick one runtime, one registry. Here, the offerings stack:

• Process isolation — pick from GKE Agent Sandbox (Kubernetes-native, gVisor, open-source upstream), AWS AgentCore Runtime (Firecracker microVM, paid per vCPU-hour, hyperscaler-bundled), Azure Container Apps dynamic sessions (Hyper-V-isolated session pools, code-interpreter or custom-container), or Cloudflare Sandboxes (container-based, active-CPU pricing). The tradeoff runs between kernel-isolation strength at one end and idle cost at the other.
• Per-tenant code — Dynamic Workflows is the closest thing on offer in OSS to a purpose-built primitive for “different agent, different durable plan, same runtime substrate.” If the team is on Workers, it’s a 300-line vendor-in choice. If the team is on Kubernetes, the equivalent pattern requires more bespoke wiring on top of Agent Sandbox.
• Per-action permission — Auto Mode is the only first-party shipped option for Claude Code. For teams running non-Claude agents, the equivalent pattern (a separately modelled action classifier with low FNR on overeager actions) is something to build, not buy.

When to reach for which primitive

You’re already on GKE, you run untrusted code (LLM-generated or agent-authored), and you need kernel-level isolation: GKE Agent Sandbox is the right call. The managed gVisor + Pod Snapshots + warm pool combination is the lightest-weight path to sub-second sandbox creation at production scale. The Lovable production deployment at 200,000+ projects daily is the strongest reference for what this primitive looks like at scale.

You’re on Kubernetes but not on GKE, and you want vendor-neutral OSS: install the kubernetes-sigs/agent-sandbox upstream project. You get the same CRDs, and gVisor or Kata isolation once your cluster supplies a configured runtime backend. You don’t get Pod Snapshots, and the warm-pool performance numbers will depend on your underlying compute. The vendor neutrality is real; the production-tuning work is yours.

You’re running multi-tenant agent code where each tenant’s plan should be isolated from the others, and idle cost matters: Cloudflare Dynamic Workflows is the lightest primitive on offer, period. The MIT licence and ~300-line footprint make it small enough to vendor into your own platform if you want the pattern without the Cloudflare dependency, though the underlying Worker Loader machinery is Cloudflare-specific.

If your threat model is “tenant A’s agent must not see tenant B’s plan state,” Dynamic Workflows is purpose-built. If your threat model includes “the tenant’s agent might try to escape its execution sandbox,” pair it with Cloudflare Sandboxes or with Agent Sandbox on Kubernetes.

You’re shipping Claude Code at scale and approval fatigue is your bottleneck: turn on Auto Mode. The 93%-approval-rate finding means the manual-prompt mechanism degrades into rubber-stamping anyway. Auto Mode replaces that rubber stamp with a classifier that catches a meaningful (though not complete) fraction of the overeager actions a fatigued human approver would have waved through.

Don’t treat Auto Mode as a security boundary on its own; the 17% FNR makes that framing unsound. Treat it as a fatigue-reduction layer that composes with sandbox-level isolation for blast-radius control.

You’re running adversarial-input agents in production (untrusted tenant code, agent-authored shell commands on customer data, autonomous coding sessions on production repos): stack the layers. GKE Agent Sandbox or AWS AgentCore Runtime for process isolation. Per-tenant code routing for tenant separation. Auto Mode (or equivalent) for per-action permission. The point of three primitives converging in the same week is that the full-stack composition is now achievable with off-the-shelf pieces; don’t ship adversarial-input agents with only one layer.

The build-vs-buy calculus has shifted, but not entirely

A platform team in mid-2026 that has spent the last twelve months building its own per-task sandbox primitive now has three credible buy-side answers across three platform layers, plus an Apache-2.0 upstream OSS option for the process-isolation layer that has only existed since November 2025. The math has changed enough that “we’re building this ourselves” needs a real defence: what does the bespoke version do that the off-the-shelf primitives don’t?

Three plausible answers survive: a non-Kubernetes runtime substrate (the SaaS team running on bare metal or on Nomad), a model coupling that none of the three vendors target (a specialised inference engine that needs a specific harness shape), or a regulated-industry context where the off-the-shelf primitives don’t meet a compliance constraint. Outside those, the bespoke-build defence is now harder to mount than it was in Q1.

Open Questions

1. Does Auto Mode’s 17% FNR hold up under sustained adversarial pressure? The published number comes from 52 curated real overeager actions and 1,000 synthetic exfiltration prompts. The Permission Gate paper that Edition 10 covered used a similar architecture on a synthetic adversarial workload; there, the end-to-end FNR was 81.0%, roughly five times the production figure, and over a third (36.8%) of state-changing actions fell outside the classifier’s evaluation scope. Whether the production Sonnet 4.6 classifier closes those scope gaps, particularly for in-project file edits (Tier 2, which bypasses the classifier), is the most operationally consequential open question. A patient quarter-long red-team campaign is the right test, and its absence from public reporting is itself a data point.

2. Will the kubernetes-sigs/agent-sandbox project sustain non-Google contributions? The project is upstream Apache-2.0 and vendor-neutral on paper. In practice, the maintainer footprint and most of the design momentum appear to come from Google. Whether other hyperscalers (AWS, Azure) build Agent Sandbox conformance into their managed Kubernetes offerings, or keep shipping their own primitives (AgentCore Runtime on AWS, Container Apps dynamic sessions on Azure), determines whether Agent Sandbox becomes the Kubernetes-native standard or the Google-flavour standard. The next two quarters of EKS and AKS release notes are the place to watch.

3. Is Dynamic Workflows’ Worker Loader pattern portable enough to vendor outside Cloudflare? The 300-line MIT-licensed library lives on top of Cloudflare-specific primitives: Dynamic Workers, the Worker Loader binding, the Workflows engine. The architectural pattern (per-tenant code loaded at runtime through a metadata-routing layer) is portable in principle. Whether a team running on AWS Lambda or on Kubernetes can lift it without rebuilding the entire Worker Loader substrate is unclear. The first non-Cloudflare implementation of “Dynamic Workflows-style per-tenant durable execution” is the signal to watch.

4. What does observability look like across the stack? Each of the three primitives ships some telemetry, but none ships a unified observability story for the full stack. A team running GKE Agent Sandbox + Dynamic Workflows + Auto Mode has to ship traces from all three into a single backend, and the OTEL bridge work for that isn’t yet productised. The opening for a third-party observability vendor (Datadog, Honeycomb, Grafana Cloud) to ship the cross-primitive view first is real, but no one had done it as of mid-May 2026.

5. How does the per-action permission pattern generalise outside Claude Code? Auto Mode is Claude-specific: the classifier runs on Sonnet 4.6, the integration is with Claude Code’s tool-call surface, the rate-limit dependencies are Anthropic’s. A team running Gemini-based or OpenAI-based agents has no turnkey equivalent. The pattern is reproducible (separate guard model, two-stage filter, restricted-context classifier), but the engineering work to ship it is non-trivial. Whether a vendor-neutral OSS implementation of the pattern emerges, something like an MCP-layer guard, is an open architectural question for non-Claude shops.

6. Where do the AWS and Azure equivalents land? AWS AgentCore Runtime ships per-session Firecracker microVMs and is the most architecturally complete hyperscaler offering for process isolation, but has no public-OSS upstream equivalent to Agent Sandbox. Microsoft’s first-party equivalent is Azure Container Apps dynamic sessions: Hyper-V-isolated, prewarmed session pools built for LLM-generated code, a Container Apps feature rather than a Kubernetes-CRD primitive (Agent 365 is governance, not runtime). The next two quarters turn on whether AWS contributes to Agent Sandbox upstream, ships a competing Kubernetes-CRD primitive, or doubles down on the AgentCore Runtime managed-service model. Microsoft’s positioning is the most open of the three hyperscalers’ agent strategies.

Since publication

• 2026-09-01 — Auto Mode has left research preview. Anthropic’s Auto Mode announcement now carries the update “Auto mode is generally available in Claude Code for all users. (July 10, 2026)”, so the Team-plan preview status described above no longer applies.
• 2026-09-01 — AWS has added a second compute option to AgentCore Runtime since the eight-hour microVM ceiling above was written. The AgentCore Runtime developer guide now states “Sessions run for up to 8 hours on microVMs, or up to 14 days on Instances”, where Instances run agents on EC2 infrastructure in the customer’s own account.

Sources

1. Cloudflare Ships Dynamic Workflows, Bringing Durable Execution to Per-Tenant and Per-Agent Code — InfoQ, 2026-05-09. Source for the ~300 LOC TypeScript figure, MIT licensing, Worker Loader mechanism, and the verbatim “Say you’re building an app platform…” use-case framing attributed to Cloudflare engineering.
2. Introducing Dynamic Workflows: durable execution that follows the tenant — Cloudflare Blog, 2026-05-01. First-party announcement. Source for the Worker Loader routing pattern, RPC-into-Worker-Loader mechanism, and the composition-with-Sandboxes pattern.
3. Run Workflows inside Dynamic Workers with the @cloudflare/dynamic-workflows library · Changelog — Cloudflare Developer Changelog. Source for the May 1 2026 release date and npm package name.
4. Sandboxing AI agents, 100x faster — Cloudflare Blog. Source for the V8 isolate boot time (single-digit ms, ~MB memory), the 100x-faster-than-containers claim, and Cloudflare’s own framing on V8 security tradeoffs (“security bugs in V8 are more common than security bugs in typical hypervisors”).
5. Agents have their own computers with Sandboxes GA — Cloudflare Blog. Source for Sandboxes’ container-based isolation, the 30s-from-scratch / 2s-from-snapshot performance numbers, and the active-CPU pricing model.
6. Pricing · Cloudflare Containers docs — Cloudflare Developer Docs. Source for the $0.000020/vCPU-second, $0.0000025/GiB-second, and $0.00000007/GB-second rates on Cloudflare Containers (which Sandboxes inherits).
7. Google Announces GKE Agent Sandbox and Hypercluster at Next ‘26, Positioning Kubernetes as AI Agent — InfoQ, 2026-05-07. Source for the 300 sandboxes/sec at sub-second latency claim, the 30% better price-performance on Axion claim, the Drew Bradstock / Gari Singh “Kubernetes has rapidly become the operating system for the AI era” quote, the Lovable / Fabian Hedin production-use quote, and the Alex Gkiouros analyst quote on hypercluster blast radius.
8. Agentic AI on Kubernetes and GKE — Google Cloud Blog. First-party source for the gVisor + Kata Containers isolation framing, the managed gVisor on GKE Sandbox detail, the pre-warmed pools enabling sub-second latency, and the Pod Snapshots feature.
9. GitHub — kubernetes-sigs/agent-sandbox — Kubernetes SIGs. Source for the Apache-2.0 license, the four CRDs (Sandbox, SandboxTemplate, SandboxClaim, SandboxWarmPool), and the vendor-neutral / cross-Kubernetes-distribution portability claim.
10. Agent Sandbox — project home — Kubernetes SIG Apps. Source for the verbatim interoperability claim (“Interoperability is core to Agent Sandbox with a standardized Kubernetes API that fully decouples the execution layer from the underlying isolation technology”) and the gVisor/Kata backend support framing.
11. Running Agents on Kubernetes with Agent Sandbox — Kubernetes Blog. Source for the SandboxWarmPool cold-start framing (“Starting a new pod adds about a second of overhead”), the four-CRD enumeration, and the standardised-Kubernetes-API portability claim.
12. Unleashing autonomous AI agents: Why Kubernetes needs a new standard for agent execution — Google Open Source Blog, November 2025. Source for the KubeCon Atlanta November 2025 launch as a SIG Apps subproject.
13. About GKE Agent Sandbox | Google Cloud Documentation — Google Cloud Docs. Source for the official GKE Agent Sandbox definition and the Python SDK / ADK / LangChain integration framing; the “offered at no extra charge in GKE. GKE pricing applies to the resources that you create” pricing statement is on the companion Enable Agent Sandbox on GKE page.
14. Save and restore Agent Sandbox environments with Pod snapshots | Google Cloud Documentation — Google Cloud Docs. Source for the Pod Snapshots version requirement (1.35.3-gke.1234000 or later) and the memory-plus-filesystem state capture mechanism; the GA date is from the GKE release notes (source 28).
15. What’s new in GKE at Next 26 — Google Cloud Blog. Source for the Lovable “200,000+ new projects daily” production reference and the “same technology securing Gemini” gVisor framing. Also source for the hypercluster details (256,000 nodes / 1M chips / Titanium Intelligence Enclave / Private GA). Dated 2026-04-22, which fixes the Next ‘26 announcement date.
16. Claude Code auto mode: a safer way to skip permissions — Anthropic Engineering. First-party source for the 17% FNR / 0.4% FPR / 93% manual-approval-rate numbers, the two-stage classifier architecture on Sonnet 4.6, the user-message + tool-call-payload-only restricted-context decision, the three-tier permission framework (Tier 1/2/3), the denial backstop (3 consecutive / 20 total), and the verbatim “Whether 17% is acceptable depends on what you’re comparing against” hedge.
17. Auto mode for Claude Code — Anthropic / Claude.com. Source for the Team / Enterprise / API availability rollout, the Sonnet 4.6 + Opus 4.6 model requirement, and the verbatim “middle path that lets you run longer tasks with fewer interruptions” positioning.
18. Inside Claude Code Auto Mode: Anthropic’s Autonomous Coding System with Human Approval Gates — InfoQ, 2026-05-05. Source for the input/execution layer framing, the subagent outbound/return check mechanism, and the verbatim red-spinner quote attributed to Ankit Kalluraya.
19. Higher usage limits for Claude and a compute deal with SpaceX — Anthropic, 2026-05-06. Source for the 300+ MW / 220,000+ NVIDIA GPUs / Colossus 1 deal terms, the doubled five-hour rate limits across Pro / Max / Team / Enterprise, and the removal of the peak-hours reduction for Pro and Max.
20. Claude Code Auto Mode: Can One Model Guard Another? — Backslash Security. Source for the practitioner critique of Auto Mode’s reasoning-blindness tradeoff and the broader framing that probabilistic security needs deterministic controls layered around it.
21. Claude Code, Codex and Agentic Coding #7: Auto Mode — Zvi Mowshowitz Substack. Source for the framing that Auto Mode is suitable for users who would otherwise run --dangerously-skip-permissions, and the practitioner takeaway that file writes within project directories bypass the classifier.
22. Anthropic-SpaceXai’s 300MW/$5B/yr deal for Colossus I — Latent Space, 2026-05-07. Source for the explicit hedging that the $5B/year figure is “some estimate” derived from secondary Twitter analyst commentary rather than Anthropic’s own announcement, and the framing of Anthropic productising parts of the harness.
23. Firecracker – The Virtualization Technology Behind AWS Lambda and Bedrock AgentCore Runtime — Dev.to. Source for the AgentCore Runtime per-session microVM detail.
24. Amazon Bedrock AgentCore Pricing — AWS. Source for the $0.0895/vCPU-hour and $0.00945/GB-hour rates used in the cross-vendor pricing comparison.
25. Amazon Bedrock AgentCore Runtime — developer guide — AWS Docs. Source for the dedicated-microVM-per-session and eight-hour max compute lifetime details.
26. Managed Agent Runtimes — Anthropic, Cloudflare, AWS, Microsoft, Google Compared — Grimoire (prior scout). Comparative-runtime context for the substitution-versus-composition framing.
27. Azure Container Apps dynamic sessions — Microsoft Learn. Source for the Hyper-V isolation, prewarmed session pools, and the code-interpreter / custom-container session pool types.
28. GKE release notes — new features — Google Cloud Docs. Source for the 2026-05-06 entry “GKE Pod Snapshots is generally available on clusters that run version 1.35.3-gke.1234000 or later.”
29. Pricing · Cloudflare Workflows docs — Cloudflare Developer Docs. Source for Workflows billing on Workers Standard CPU time, requests and storage, and for idle workflows incurring no CPU time.