{"slug": "run-untrusted-ai-agent-code-safely-with-azure-container-apps-sandboxes", "title": "Run Untrusted AI Agent Code Safely with Azure Container Apps Sandboxes", "summary": "Microsoft has launched the public preview of Azure Container Apps Sandboxes, a new ARM resource type that runs untrusted AI agent code in hardware-isolated microVMs. The sandboxes start from OCI disk images in under a second, scale to thousands of instances, and incur no cost when idle, addressing the security risks of LLM-generated code executing in-process where prompt injections can steal API keys or load payloads. The service includes network egress defaults to deny, Entra managed identity support, and is already used by GitHub Copilot, Azure AI Foundry, and Azure Container Apps Express.", "body_md": "Microsoft has [announced](https://techcommunity.microsoft.com/blog/appsonazureblog/introducing-azure-container-apps-sandboxes-secure-infrastructure-for-agentic-wor/4524131) the public preview of Azure Container Apps Sandboxes. This new ARM resource type is `Microsoft.App/SandboxGroups`\n\nruns untrusted code generated by agents in hardware-isolated environments. Each sandbox starts from an OCI disk image in less than a second. It can scale to thousands of instances at once and incurs no cost when idle. This billing model suits the short, bursty tasks typical of agentic workloads.\n\nThe risk is not theoretical. When an LLM generates code and an agent executes it in-process, the execution surface becomes the attack surface. A planner in Python might seem safe, like fetching a remote URL, reading environment variables, or using `exec()`\n\n. But it can actually steal API keys or load any payload with just the standard library. Without a hard boundary between the agent's generated code and the host environment, any sufficiently capable model is one prompt injection away from a postmortem. Teams building multi-tenant platforms, CI/CD automation, or LLM-backed code interpreters often had to create custom isolation setups. They usually did this by layering container runtimes with limited seccomp profiles or by using dedicated Kubernetes clusters with Kata Containers. These solutions need ongoing operational investment.\n\nEach sandbox operates in its own microVM, which is isolated from the host, the platform, and other sandboxes on the same infrastructure. Developers can use any OCI-compliant container image. Sandboxes handle provisioning from pre-warmed pools. They ensure multi-tenant isolation and manage the whole lifecycle, from startup to teardown. The resource model groups sandboxes into Sandbox Groups. These groups serve as the management and configuration boundary for a set of sandboxes. They are similar to Container Apps Environments but are designed for short-lived workloads. Each Sandbox Group holds shared settings that apply to all sandboxes within it. This includes network egress policy, managed identity assignment, lifecycle rules, and resource tiers.\n\nThe isolation model comes with key operational capabilities for production. Snapshot-based suspend and resume keep the full memory and disk state during sessions. This means an agent can pause a multi-step investigation or a development environment with installed packages, scale it to zero, and then resume later without re-initialisation.\n\nNetwork egress defaults to deny. Outbound traffic is allowed only to explicitly allowed hosts, as enforced at the proxy layer inside the sandbox. Both system-assigned and user-assigned Entra managed identities are supported. This allows sandboxes to authenticate with Azure services without embedding credentials in the image or passing secrets through environment variables.\n\nMicrosoft has published an[ Agent Governance Toolkit](https://techcommunity.microsoft.com/blog/linuxandopensourceblog/govern-ai-agents-using-agent-governance-toolkit-and-azure-container-app-sandboxe/4526011). This toolkit works with ACA Sandboxes through the agt-sandbox Python package. It adds two layers of enforcement: AST scanning and Tool allowlists\n\nThese are applied before a snippet runs, and egress allowlist enforcement happens at the network boundary within the sandbox. They operate independently. This means that a denied call never reaches the execution environment. Also, if an outbound call is made to a non-allowlisted host, it fails at the proxy, no matter what the in-process policy allows.\n\nThe announcement clearly lists the products using this infrastructure:[ Cloud Sandboxes in GitHub Copilot](https://github.com/features/copilot),[ Foundry Hosted Agents](https://azure.microsoft.com/en-us/products/ai-foundry), and[ Azure Container Apps Express](https://techcommunity.microsoft.com/blog/appsonazureblog/whats-new-in-azure-container-apps-at-build26/4524184). This is important for architecture. Instead of creating a new trust-based abstraction, Microsoft is providing access to the same isolation fabric it uses for its own developer products.\n\nThe ACA Sandboxes announcement comes into a crowded market. In April 2026,[ Cloudflare](https://www.infoq.com/news/2026/04/cloudflare-sandboxes-ga/) launched its Sandboxes product. It offers persistent, isolated Linux environments with active CPU pricing and snapshot-based session recovery. This targets teams already using Cloudflare Workers. [E2B](https://e2b.dev/) is a dedicated sandbox platform based on Firecracker microVMs. It has gained traction among many Fortune 500 companies for agent code execution. E2B boasts sub-200ms cold starts and BYOC options for teams needing data residency. [Fly.io](http://Fly.io) launched[ Sprites](https://sprites.dev/) in January 2026. This product features a persistent-by-default model with Firecracker microVMs and 100GB NVMe storage. It challenges the ephemeral approach, arguing that rebuilding the state wastes latency.\n\nWhat sets the ACA Sandboxes apart is their Azure-native integration, not just sandbox performance. Teams using Azure can access Entra identity, ARM-native resource management, and egress control through existing tools. They benefit from the same infrastructure that supports GitHub Copilot, all without managing the orchestration layer. For teams outside Azure, or those needing GPU-intensive workloads, BYOC options, or preferring open-source isolation tools, dedicated providers offer more flexibility.", "url": "https://wpnews.pro/news/run-untrusted-ai-agent-code-safely-with-azure-container-apps-sandboxes", "canonical_source": "https://www.infoq.com/news/2026/06/untrusted-ai-agents-sandboxes/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global", "published_at": "2026-06-12 11:00:00+00:00", "updated_at": "2026-06-12 11:41:32.047138+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-safety", "ai-agents", "large-language-models", "ai-tools"], "entities": ["Microsoft", "Azure Container Apps Sandboxes", "Kata Containers", "OCI"], "alternates": {"html": "https://wpnews.pro/news/run-untrusted-ai-agent-code-safely-with-azure-container-apps-sandboxes", "markdown": "https://wpnews.pro/news/run-untrusted-ai-agent-code-safely-with-azure-container-apps-sandboxes.md", "text": "https://wpnews.pro/news/run-untrusted-ai-agent-code-safely-with-azure-container-apps-sandboxes.txt", "jsonld": "https://wpnews.pro/news/run-untrusted-ai-agent-code-safely-with-azure-container-apps-sandboxes.jsonld"}}