Azure Container Apps Sandboxes: per-agent microVMs with egress controls

Azure Container Apps Sandboxes is Microsoft’s execution environment for workloads where code cannot be trusted: agent runtimes that install packages, call APIs, or act on behalf of a user. Each sandbox runs as a hardware-isolated microVM with its own Linux kernel, rather than relying on the shared host kernel used by typical container runtimes. Microsoft says startup takes under a second, which it argues makes it practical to give each task its own machine and delete it when the work is done.

The security model centers on egress. Every outbound request passes through a proxy that can apply rules by host, domain pattern, or CIDR, starting from a default deny. The proxy can also inject authentication headers outside the sandbox, so an agent never receives the API key it is using. If a static allowlist is not enough, an egress webhook sends each request to the customer’s own service for approval. Network Audit records which requests were allowed and denied.

For data on private networks, sandbox groups can sit on a dedicated subnet via VNet integration, and inbound access can be brought into a virtual network through a Private Endpoint. Microsoft says internal routes receive the same egress filtering, header transformation, and audit logging as internet-bound calls.

Sandboxes are created from platform-provided images, a custom container image from a public or private registry, or a snapshot of an existing sandbox. Snapshots can capture disk and memory, allowing a new sandbox to resume where the original stopped. Sizes range from 0.25 vCPU with 0.5 GB of memory and a 5 GB disk up to 16 vCPU with 32 GB of memory and a 320 GB disk through the API. Lifecycle policies can stop an idle sandbox and later delete it, and persistent volumes can attach to one sandbox or to many for read-heavy data.

Telemetry is opt-in and covers console logs, platform-managed metrics, OpenTelemetry signals from the application, and egress decisions. It can be routed to OTLP collectors, Log Analytics, or Application Insights, and Microsoft says the credentials used to write telemetry never enter the sandbox.

The service is programmable through Python and TypeScript SDKs, an ACA CLI, and an ARM resource type for Bicep; a Terraform provider is in preview. Microsoft says .NET SDK support is on the way. Pricing is per vCPU core-second, per GiB-second of memory, and per GB of stored disk images, snapshots, and volumes. Storage charges were listed as coming soon at Premium Azure Blob ZRS rates, and prebuilt images are provided as is, with availability and versions subject to change.

Microsoft says usage during public preview passed one million sandboxes created per day. It cites KPMG, Cognite, and South Australia’s Department for Education as early customers; the department’s AI technical lead, Cody Little, is quoted estimating that the service lets his team retire close to 50,000 lines of code that managed a custom code interpreter and state. That figure is the customer’s claim, not an independently verified number.

Microsoft says its next priorities are group-level policy enforcement and auditing, more SDKs and VS Code integration, and connectors and triggers with on-behalf-of authentication. Some parts of the offering are still unfinished: storage pricing has not fully taken effect, the Terraform provider remains a preview, and .NET SDK support has not shipped.