A glowing AI robot connects identity controls, secure servers, and data workflows in a futuristic data center.
AI agent infrastructure is increasingly pairing controlled tool access with isolated code execution. DigitalOcean’s Agent Droplets, Uber’s agent identity architecture, Daytona’s VM forking, E2B’s sandbox usage milestone, and Cloudflare’s Dynamic Workers illustrate that direction—but they do not represent five equivalent, production-ready launches in the same week. Their dates, security boundaries, and maturity levels differ substantially.

For enterprise developers, the useful takeaway is less dramatic and more actionable: authorization and execution containment solve different problems. Uber documents controls over who may invoke downstream tools; Daytona and Cloudflare document boundaries around the code doing the invoking. Neither should be mistaken for a complete security guarantee.

What actually changed—and when​

DigitalOcean: an agent bundle, explicitly in preview​

DigitalOcean announced Agent Droplets on October 1, 2026, following the September 22 public preview of Managed Agents. Its announcement describes dedicated microVM sandboxes, inference, persistent memory, session storage, and governed tool access.

The pricing deserves a qualification. Pro costs $50 per month and Team $200, but these are resource-allowance subscriptions—not unlimited compute and inference for a flat fee. Customers can stop spending at the plan allowance or permit additional consumption at list prices. Models not hosted by DigitalOcean are billed at list price.

More importantly, the release explicitly states that Agent Droplets and Managed Agents are public-preview services, with production-level performance not guaranteed. It reports roughly one-second sandbox startup and 300-millisecond resume times in DigitalOcean testing. The announcement establishes dedicated microVM execution, but does not identify Firecracker as its implementation. Describing this as a confirmed production-grade Firecracker launch goes beyond that evidence.

Uber: identity propagation, not sandbox forking​

Uber’s engineering account describes a Security Token Service that issues short-lived, destination-scoped tokens for individual hops. The architecture preserves the delegation chain from the originating user through participating agents, rather than presenting downstream systems with an anonymous-looking service account. Its MCP Gateway verifies those identities and applies tool-level policies.

That is an authorization architecture, not a VM-forking mechanism. Uber says the account covers identity-stack changes made during 2025 and its roadmap for 2026. Its related-article listing dates a separate MCP Gateway article to October 1, 2026; that publication date alone does not establish a new gateway deployment that day.

Daytona and E2B: earlier developments, different evidence​

Daytona announced its $24 million Series A on February 5, 2026, describing environments that agents could pause, branch, snapshot, and destroy. Its documentation now explicitly supports duplicating a Linux VM or Windows sandbox’s filesystem and memory into an independent child. Container sandboxes do not support that fork operation.

E2B’s own timeline places its billionth sandbox start on June 3, 2026. That is a company-reported cumulative usage milestone across several agent workloads—not evidence of an October launch, a billion distinct customers, or a particular copy-on-write implementation.

Cloudflare: lightweight isolates in open beta​

Cloudflare’s Dynamic Worker Loader lets a Worker instantiate another sandboxed Worker using code supplied at runtime. The company says the feature is in open beta for paid Workers users and can support a separate Dynamic Worker for each request. These environments use V8 isolates, not cloned Linux VMs.

The common direction is finer-grained containment. The mechanisms are not interchangeable.

Copy-on-write is useful, but benchmarks need boundaries​

ZeroBoot provides a concrete illustration of copy-on-write VM creation. Its repository describes mapping a Firecracker memory snapshot with mmap(MAP_PRIVATE), creating a new KVM VM, and restoring CPU state. The design allows forks to begin from a prepared baseline, with private changes as execution diverges.

The project reports median spawn latency of 0.79 milliseconds, but also labels itself a working prototype that is not production-hardened. Its documented limitations include one vCPU per fork, no networking inside forks, and explicit reseeding requirements for user-space random-number generators.

Daytona’s approximately 27-millisecond startup claim is traceable to a July 2025 company post, which separately reported end-to-end latency below 90 milliseconds. That is not a verified benchmark for its current VM-fork operation.

Cloudflare’s claimed 100-fold startup advantage compares isolates with a typical container. Its announcement also notes that small JavaScript snippets are the most efficient fit, although Python and WebAssembly are technically supported.

These figures should not be treated as a leaderboard. As an engineering assessment, a meaningful comparison would need the same workload, startup definition, networking requirements, and isolation expectations. A stopwatch cannot tell you whether an environment offers the capabilities your application needs.

A sandbox is not a permissions policy​

Cloudflare’s documentation supplies an especially useful practical detail: setting globalOutbound to null blocks outbound fetch() and connect() calls from a Dynamic Worker. Those calls throw exceptions, while explicitly supplied bindings remain usable. Developers can alternatively intercept outbound requests through a gateway to restrict destinations, inject credentials, and record activity.

That distinction matters. Blocking general network access does not remove capabilities deliberately exposed through bindings. Similarly, hiding a credential from agent-generated code does not eliminate the authority of the API operations that credential enables. This is the security implication of Cloudflare’s documented capability and credential-brokering model.

Daytona adds another lifecycle consideration: forks are independent environments with tracked parent-child relationships, and a parent cannot be deleted while it has active fork children. “Forked” therefore does not mean “automatically discarded.” Cleanup must account for the branch tree.

A practical evaluation checklist, synthesized from these documented controls, is:

  • Define the execution boundary: isolate, container, Linux VM, or Windows VM.
  • Define the authority boundary: which tools, destinations, bindings, and credentials remain available.
  • Define the state boundary: what memory and filesystem state enters each fork.
  • Define the cleanup boundary: which children and persistent resources must be removed.
  • Check service maturity: preview, beta, and prototype labels matter alongside latency claims.

The security incidents are not all sandbox failures​

OWASP’s Agentic Top 10 places EchoLeak under Agent Goal Hijack, Amazon Q under Tool Misuse, and Replit under Rogue Agents. Unexpected Code Execution is a separate category. Grouping these examples as proof of one missing execution boundary obscures their different failure paths.

The EchoLeak case study describes CVE-2025-32711 as a zero-click prompt-injection vulnerability in Microsoft 365 Copilot that enabled data exfiltration through a crafted email. It supports the need to protect data and instruction boundaries; it does not establish that putting code inside a VM would have prevented the attack.

AWS’s account of the Amazon Q incident is also narrower than a claim of hundreds of thousands of compromised installations. Its bulletin identifies extension version 1.84.0 and says the distributed malicious code failed to execute because of a syntax error. AWS released 1.85.0 as the remediation at the time and instructed customers to remove affected installations, including derivative copies. Those are historical affected and remediation versions, not a statement about today’s latest extension.

The enterprise takeaway​

The strongest supported conclusion is not that sandbox forking “completes” agent governance. It is that execution containment belongs alongside identity, scoped authorization, network controls, and lifecycle management. Uber’s delegation-aware tokens and Cloudflare’s explicit egress controls demonstrate why those responsibilities remain separate.

For Windows development teams, Daytona’s documented Windows VM forking also makes the discussion directly relevant to native application and tooling workflows—not just Linux coding agents. Its Windows forks preserve filesystem and memory state, so the baseline deserves scrutiny before it becomes the starting point for parallel work.

Faster isolation can make safer architectures more practical. But the procurement question should remain blunt: what can this agent still reach after it enters the sandbox? That answer—not the smallest startup number—is where the security assessment begins.

 

References

  1. Sandbox Forking Completes the Agent Governance Stack - forkast.news forkast.news 2026-10-03T10:02:21+00:00
  2. Daytona Raises $24M Series A to Give Every Agent a Computer daytona.io
  3. Egress control · Cloudflare Dynamic Workers docs developers.cloudflare.com