Azure Container Apps Sandboxes Reach GA With MicroVM Isolation

Azure Container Apps Sandboxes Moves From June Preview to GA​

The Azure Container Apps team announced GA on the Microsoft Tech Community blog the same day as Hulme's post. The preview dates back to Build 2026, when Microsoft introduced Sandboxes as a new first-class resource type that gives you fast, secure, ephemeral compute environments with built-in suspend and resume. Microsoft said then that the same infrastructure already runs Cloud sandboxes in GitHub Copilot, Foundry Hosted Agents, and Azure Container Apps Express.

Container Apps Express reached GA on the same day, which is a useful clue about what Sandboxes actually is. According to Microsoft, Azure Container Apps Express runs on Azure Container Apps Sandboxes, the isolated compute layer behind its provisioning and startup speed. In other words, Sandboxes is the layer underneath several Microsoft products, now sold to customers directly.

Microsoft's documentation hasn't caught up with the announcement. When checked, the Learn "Get started" page still carried a preview label and warned that sandboxes created during preview might not be compatible with future releases and might need to be recreated. The API surface for Python SDK and Azure Container Apps CLI commands might change during preview. The most likely explanation is that the docs haven't been updated yet. Still, teams that built on the preview should check whether their existing sandbox groups and SDK code carry over before calling anything production-ready.

Microsoft Splits Agent Governance in Foundry From Execution in Sandboxes​

The main argument in Hulme's post is that an agent involves two separate decisions. One is how you govern the agent. The other is where its code runs. He argues that when an agent moves from answering questions to completing tasks, it starts cloning repositories, installing packages and running analysis against live data. By default, that code usually runs wherever the host application happens to be.

Hulme calls this a three-way trap. On shared infrastructure, every workload shares the same blast radius. If you give the agent broad access so it can be useful, an autonomous process ends up with far more reach than you meant to give it. If you lock the host down, the agent can't do its job. Microsoft says this is where many promising agent pilots stall before production.

Microsoft's answer splits the stack. Foundry is where agents are built, grounded in enterprise data, given an identity through Entra Agent ID, and traced and evaluated. Microsoft Learn describes Foundry as bringing agents, models and tools together under one management grouping, with tracing, evaluation, role-based access control, network isolation and Azure Policy. Sandboxes handles execution. Hulme says the agent keeps its identity, permissions and oversight when its work moves into a sandbox, and that what goes into and comes out of the sandbox stays on the Foundry record.

This is the right way to think about agent risk, but the two layers solve different problems. Sandbox isolation limits what a misbehaving or compromised agent can reach. It does nothing to make the agent's decisions correct. That still depends on Foundry's tracing and evaluation, and on whatever permissions the connected business systems grant.

How Sandbox Groups, Disk Images and Snapshots Fit Together​

Sandboxes appear in Azure as a resource of type Microsoft.App/SandboxGroups. The sandbox group is the top-level ARM resource you create in a resource group and region. Disk images, snapshots, volumes and secrets are all scoped to a group. Each sandbox inside a group is an isolated compute instance with its own CPU, memory, disk and network boundary, and Microsoft's portal docs describe these as isolated, on-demand microVMs for AI agents, code execution, and developer environments.

Management works across two planes. You create, update and delete sandbox groups, and manage VNet connections, through the standard ARM endpoint at management.azure.com. Everything else goes through a separate data plane at management.azuredevcompute.io. That includes individual sandboxes, disk images, snapshots, files, volumes, secrets, ports and egress policies. Anyone writing network rules or RBAC for this service needs to account for both endpoints.

Root filesystems come from OCI container images. For a custom environment with your own code and dependencies, you can bring a container image from a public or private registry. The platform converts it into an optimized, bootable disk image containing your application, agent harness, runtimes, and toolchain. For a private registry, you authenticate with registry credentials or a managed identity for Azure Container Registry. Microsoft also provides prebuilt public images.

State is what separates Sandboxes from the older Container Apps dynamic sessions. Dynamic sessions are ephemeral, handed out by a session pool, and destroyed after a cooldown period. Sandboxes are managed one by one. You create, stop, resume and delete them yourself, and they keep state through snapshots and mounted volumes. Two volume types are available. Azure Blob volumes can be mounted by several sandboxes at once. Data Disk volumes are faster but can be mounted by only one sandbox at a time. Microsoft's guidance is to use dynamic sessions when you want a managed code interpreter and Sandboxes when you need programmatic control and persistence.

Hulme says a paused sandbox resumes "with its full working context intact". That depends on a setting. Each sandbox has a suspend mode:

• Memory mode takes a full snapshot of memory and disk, so running processes come back as they were.
• Disk mode keeps only the disk, so processes restart when the sandbox resumes.
• Auto-suspend stops a sandbox after an idle timeout. A sandbox counts as idle when it has no inbound traffic, no code execution through the execute API, no interactive shell and no file operations.
• Auto-delete removes a stopped sandbox after a set number of days.

Five resource tiers set the size of each sandbox:

Egress Policies Enforce the Sandbox Guardrails​

Hulme says a sandbox "can access only the systems you have allowed it to reach" and "never stores the credentials it uses". Both claims are true only if the egress policy engine is configured to make them true. Microsoft's egress documentation starts from the premise that sandboxes run code you don't fully trust, such as AI-generated scripts, agent tool calls and user input, and that the network is where such code can do the most damage.

A policy has three parts. The default action is Allow or Deny. Rules match on host, path and HTTP method. The inspection mode is one of Full, Partial, None or Legacy. Rules are evaluated in order, the first match wins, and the default action applies when nothing matches. Microsoft recommends starting any sandbox that runs untrusted code with a default of Deny plus an explicit allow list. Order matters: a Deny rule for api.example.com/admin must come before an Allow rule for api.example.com.

Credential injection is the key feature for agents. A Transform rule can add a header to outbound requests. The header's value can be a fixed string, a secret from the sandbox group's secret store (for example formatted as Bearer {value}), or a token obtained on demand from a managed identity. The request leaves the sandbox authenticated, but the code inside never sees the API key. Microsoft notes this is particularly useful when an agent needs to call an LLM API. Rewrite rules can also change the destination scheme, host or path.

The inspection mode decides whether these rules are enforced:

• Full inspects all traffic, enforces Deny rules and blocks non-HTTP traffic.
• Partial inspects only traffic that matches a rule and lets non-HTTP traffic through.
• None applies no egress rules.
• Legacy inspects all traffic but lets non-HTTP traffic through.

For an agent running AI-generated code, choosing Partial instead of Full is a real decision, because Partial lets non-HTTP traffic leave the sandbox. You can set a policy when the sandbox is created and change it while it runs. Changes apply to later requests; requests already in flight aren't re-evaluated. Microsoft also recommends reviewing the denied-request counts of long-running sandboxes regularly. In its words, a spike usually indicates either a misconfigured workload or an exfiltration attempt.

KPMG, Cognite and South Australia's EdChat: What Microsoft Reports​

Hulme's post names three customer deployments. All the figures come from Microsoft and the customers themselves, and no independent reporting has confirmed any of them.

KPMG's Digital Gateway Powered by Claude brings Anthropic's Claude into the firm's tax platform on Azure. Within it, DG Cowork is the AI workspace where tax professionals analyze information and draft content. Client data must stay separated by engagement, so the platform uses engagement-specific workspaces. Microsoft says DG Cowork runs more than 30,000 sandboxes concurrently.

Cognite Atlas AI runs agents on Azure OpenAI models in Foundry against live industrial data in Cognite Data Fusion. Christian Flasshoff, an architect at Cognite, says the agents needed to run arbitrary code and work with files directly. That required isolation of each user's agent, environment and data. He says the team had a prototype running in hours and was testing with customers within weeks. He credits per-user isolation, egress policies and sub-second execution, and says investigations that once took days now produce a cited draft in minutes. That speed-up is Cognite's own claim, not a measured benchmark. Cognite also uses pause-and-resume so agents can work through longer investigations.

South Australia's Department for Education runs EdChat for 60,000 students and more than 40,000 staff. Students write code and explore data alongside AI, and each student needs a separate environment they can come back to later. The department estimates that moving to Sandboxes lets it retire close to 50,000 lines of code it had written to manage the state of its own code interpreter. That kind of maintenance burden is common among organizations that built their own code-interpreter infrastructure before a managed option existed.

Microsoft's own scale claim is that more than a million sandboxes a day run in production across its services, including GitHub Copilot, Copilot Studio, Security Copilot, Foundry Agent Service and Azure SRE Agent. The GA announcement puts it slightly differently, saying that during public preview that we announced in June 2026, the usage surpassed quickly a million sandboxes created every day. Either way, this is Microsoft's own figure. It shows the platform is used heavily inside Microsoft, not how much capacity any given customer subscription will get.

Storage Billing and Entra-Only Access for Sandboxes​

At GA, compute follows the familiar Container Apps model. The resource tier of the sandbox determines the amount of vCPU and GiB of memory. These rates are on the Container Apps pricing page. Stopped sandboxes incur no CPU or memory charges. That doesn't make a stopped sandbox free, though.

The GA post describes a storage charge that is charged (coming soon) at Premium Azure Blob ZRS rates. It will cover custom disk images, snapshots, and optional Data Disk and Blob volumes. The billing model is reasonable. You pay to store one copy of that image for as long as you keep it, regardless of how many sandboxes boot from it. The OS disk each of those sandboxes runs on is not billed. But snapshots are the combined memory and disk snapshots of your sandboxes, including those taken automatically when a sandbox stops. A deployment with thousands of suspended per-user sandboxes, like the EdChat model, will build up snapshot storage costs. Auto-delete is the setting that keeps them under control.

Two access requirements catch people out. Only Microsoft Entra ID accounts can use sandboxes; personal Microsoft accounts aren't supported. Creating or managing sandboxes also requires the Container Apps SandboxGroup Data Owner role, assigned at subscription or resource-group scope, for example:

az role assignment create \
  --assignee "<USER_EMAIL_OR_OBJECT_ID>" \
  --role "Container Apps SandboxGroup Data Owner" \
  --scope "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>"

Microsoft's sample repository notes that role assignments take 30-60 seconds to propagate. If your first sandbox operation fails with an authorization error right after granting the role, waiting a minute and retrying is the documented fix. You can manage sandboxes from the dedicated Sandboxes portal, the aca CLI, or the Python SDK (azure-containerapps-sandbox). Microsoft's portal docs also mention MCP control for agent-driven workflows.

What this means for you​

If your agents currently run generated code on the same compute as the host application, you should evaluate Sandboxes now. Teams already using Container Apps dynamic sessions only need to move if they need persistent state, per-sandbox egress control or VNet integration. Before putting production data behind a sandbox, confirm that preview-era resources and SDK calls still work under GA, and design your egress policy before your first deployment instead of adding it later.

• Set untrusted-code sandboxes to a default-Deny egress policy with Full inspection. Partial inspection lets non-HTTP traffic out.
• Use Transform rules with secret or managed-identity references so API keys never exist inside the sandbox.
• Choose memory suspend mode only when processes need to survive a pause. Disk mode restarts processes on resume.
• Set auto-delete on stopped sandboxes, because snapshot and custom-image storage are billed at Premium Blob ZRS rates even when compute is not.
• Grant the Container Apps SandboxGroup Data Owner role at the narrowest scope that works, and use only Entra ID accounts.
• Allow for the ARM control plane and the separate management.azuredevcompute.io data plane in your firewall and audit rules.

GA brings Microsoft's case for separating Foundry governance from sandboxed execution to every Azure customer. The platform is the same one behind GitHub Copilot's cloud sandboxes, and Microsoft says it is already running at scale for KPMG, Cognite and South Australia's schools. What the service provides is the isolation boundary itself: sub-second microVMs, snapshots, and an egress proxy that can inject credentials. How tight that boundary is depends on the policy you configure. The next concrete change is the storage meter Microsoft lists as "coming soon". Once it's live, the cost of keeping thousands of suspended sandboxes will show up on the bill.