AWS and Google Cloud have both launched managed sandbox services for AI agents, completing a market where all four major cloud platforms—Microsoft Azure, Cloudflare, AWS, and Google Cloud—now offer isolated code execution as a built-in feature. For Windows users and developers, this means no cloud provider is without a secure way to handle the code that AI assistants generate, but the differences between these services could shape how you build, test, and deploy agent-driven workflows.

The Missing Pieces Arrive: AWS and Google Join the Sandbox Party

In July 2026, Google Cloud announced the public preview of Cloud Run sandboxes at the WeAreDevelopers World Congress in Berlin. The feature arrived shortly after AWS shipped its own Lambda MicroVMs earlier in the same quarter, according to reporting by The New Stack. With those launches, every hyperscale cloud now provides a native sandbox primitive—a dedicated environment where untrusted code from AI agents can execute without endangering the host application.

Microsoft got there first. Azure Container Apps dynamic sessions have been generally available since 2024, and the company reported that its own Copilot consumes more than 400,000 such sessions daily. Cloudflare followed with its Sandbox SDK, tying execution to Workers and Durable Objects. Now the quartet is complete, and developers no longer need to cobble together homegrown isolation systems or rely on specialized third-party microVM services.

Inside the Box: How Each Cloud Isolates AI Code

The shared pattern is simple: a trusted application submits code to a platform-controlled environment, receives the results, and never lets the untrusted workload touch its own memory, processes, or network. But underneath that similarity, each cloud provider made profoundly different choices about the isolation boundary, session lifecycle, and resource model.

AWS: Firecracker MicroVMs with Persistent Sessions

AWS Lambda MicroVMs run on Firecracker, a lightweight virtual machine monitor that gives every session a dedicated guest OS and hardware-assisted isolation. Each microVM can live for up to eight hours, supporting full Linux workloads, custom HTTPS endpoints, and—crucially—a suspend-resume cycle that preserves memory, disk, and running processes.

This stateful design is ideal for coding agents that need to pause mid-workflow, wait for human input, and resume without rebuilding the environment. AWS also exposes lifecycle hooks (startup, suspension, resumption, termination) so teams can flush writes, refresh credentials, or clean up session-specific resources.

Google Cloud: Two Sandbox Paths, Two Different Mindsets

Google Cloud now offers two distinct sandbox options.

GKE Agent Sandbox targets Kubernetes-native shops. It introduces custom resources, warm pools, stable identities, and a controller that manages lifecycle. The runtime can use gVisor, a userspace kernel that interposes between the container workload and the host kernel, reducing the attack surface without the overhead of a full VM for every task.

Cloud Run sandboxes take the opposite approach. A simple --sandbox-launcher flag during deployment makes a sandbox binary available inside the container. The application then shells out to it as a subprocess. Google reported a demo where a single Cloud Run service started, executed, and stopped 1,000 sandboxes at an average of 500 milliseconds each. There is no separate sandbox charge—the sandbox borrows the CPU and memory already allocated to the parent instance.

Security defaults are opinionated: no inherited environment variables, no metadata server access, no outbound network, a read-only filesystem, and ephemeral writes that disappear when the command ends.

Azure: Hyper-V Isolation with Session Pools

Azure Container Apps dynamic sessions use Hyper-V boundaries and a pool-based allocation model. Prewarmed, ready-to-allocate environments ensure low-latency handoffs. When an application requests a session via a management endpoint, Azure either reuses an existing warm session or draws from a pre-scaled pool. Sessions can be code interpreters or custom containers, and network access is blocked by default unless explicitly enabled.

Microsoft’s documentation carries a critical warning: users within the same session can access each other’s files and environment variables. That makes session ID management a top-tier security concern, not an afterthought.

Cloudflare: Edge-Native Sandboxes with Durable Objects

Cloudflare’s Sandbox SDK combines Workers, Durable Objects, and VM-backed Containers. A Worker receives the request, routes it through a Durable Object (which provides a stable, unique identity for the sandbox), and the container executes commands inside its own VM. HTTP and WebSocket communication are supported, making it natural for real-time, interactive agent sessions at the edge.

This is not a generic VM-service pitch—it’s deeply integrated with Cloudflare’s developer platform, so the sandbox is an extension of the Durable Object model rather than a standalone compute resource.

Why This Matters for Your Windows Workflows

Before these services, a Windows application that needed to run Linux-based code—generated by an AI agent or submitted by a user—often resorted to risky or heavy-handed strategies: executing scripts inside the same process, spinning up a local Hyper-V VM, or maintaining a separate Kubernetes cluster. Now, any Windows app can offload that execution to a cloud sandbox with a simple API call.

This unlocks several practical scenarios:
- Running generated Python, Node.js, R, or shell scripts from a Windows desktop or server application without granting it access to the host filesystem.
- Building secure code interpreters into internal tools without exposing application servers.
- Performing data analysis or document processing in an isolated environment that can’t exfiltrate data.
- Creating disposable test environments for DevOps pipelines that evaluate patches or untrusted plugins before they reach a build server.

These cloud sandboxes do not replace local Windows Sandbox, Windows Defender Application Guard, Hyper-V, or WSL for personal desktop isolation. Instead, they complement those tools by moving multi-tenant, AI-driven code execution into managed infrastructure designed for scale, policy enforcement, and integration with cloud services.

A Timeline of AI Sandbox Evolution

The path to universal sandbox services was not sudden. A few years ago, running AI-generated code safely meant picking one of several uncomfortable options:

  • Execute in the same container or VM as the application and hope for the best.
  • Operate a Kubernetes cluster with hardened runtimes like gVisor or Kata Containers.
  • Build a custom sandboxing system around cgroups, namespaces, seccomp, and credential management.
  • Purchase a specialized third-party microVM service.
  • Avoid execution entirely and keep the agent limited to text responses.

Microsoft broke the pattern in 2024 with Azure Container Apps dynamic sessions, offering a managed, pool-based sandbox that quickly found production use inside its own products. Cloudflare followed with an edge-native alternative. By mid-2026, both AWS and Google Cloud had concluded that agent code execution was no longer a niche experiment—it was a mainstream architectural requirement—and released their own offerings.

Your Sandbox Checklist: 7 Steps to Safe AI Execution

Isolation alone is not security. A sandbox prevents code from breaking out of its container, but it does nothing to govern what that code does with the permissions you hand it. Here is a practical checklist for Windows developers and IT administrators integrating these services.

  1. Pick the sandbox that fits your cloud and workload. If you’re already on Azure, start with dynamic sessions. If on Google Cloud, test Cloud Run sandboxes (they’re free with your instance). Need long-lived, interactive sessions? Try AWS microVMs. Want edge execution? Look at Cloudflare.
  2. Deny outbound network by default. Azure and Cloud Run do this automatically; for AWS and GKE, configure explicit egress allowlists. An agent that can exfiltrate data over the internet instantly becomes a data-loss vector.
  3. Guard session IDs like secrets. Use cryptographically random, per-tenant identifiers. Never expose them in URLs, logs, or client-side telemetry. Remember Microsoft’s warning: shared sessions mean shared files and environment variables.
  4. Scope credentials to the absolute minimum. The sandboxed code should receive short-lived tokens with access only to the specific resources it needs—not your entire subscription.
  5. Set hard resource limits. Define CPU, memory, and timeout ceilings. For Cloud Run, where sandboxes share the parent instance’s resources, a runaway script can starve your own service.
  6. Log everything you can. Record every command executed, network connection attempted, and file written. Feed these logs into your SIEM or audit pipeline.
  7. Layer governance on top of isolation. Isolation limits blast radius; governance answers whether an action should be allowed at all. Use policies, approval gates, and role-based controls to decide which APIs the agent can call, which data it can see, and which destructive operations require human sign-off.

What’s Next for Cloud Sandboxing

Expect the feature gap between providers to narrow rapidly. AWS will likely add longer session limits and more network controls. Google’s Cloud Run sandboxes will graduate from preview with additional resource management tools. Azure and Cloudflare will deepen their integrations with AI platforms and developer toolchains.

However, the fundamental architectural choices—Firecracker VM vs. Hyper-V pool vs. gVisor runtime vs. subprocess boundary vs. Durable Object coordination—will persist. This is not a market that commoditized into interchangeability; it’s a market that gave developers multiple, valid ways to answer the same dangerous question: where should an AI agent’s code actually run? The smarter question now is: who governs what that contained code is permitted to do?