Microsoft’s Azure team argues that an agent-first platform must separate the system that governs an AI agent from the environment in which that agent performs work. The distinction matters once an agent moves beyond answering questions: it may clone a repository, install packages, run code, inspect live data, call a system of record, then iterate without a person present for every step.
What Microsoft is proposing
The governance layer in this design is Microsoft Foundry. Microsoft positions it as the place to build agents, ground them in enterprise knowledge, give them a first-class identity through Entra Agent ID, and trace and evaluate their behavior after deployment. This control plane is intended to retain the agent’s identity, permissions, telemetry and policy context. It does not, however, prescribe the runtime where code executes.
For execution, the source points to Azure Container Apps Sandboxes. An agent task receives a dedicated, hardware-isolated microVM; Microsoft says the environment can be created in seconds, offers sub-second startup, and is discarded when work ends. The sandbox runs under an identity controlled by the customer, reaches only approved systems, and does not store the credentials it uses. Long-running tasks can be paused and later resumed with their working context intact.
Why the split changes architecture
A conventional application usually waits for a request and follows a predetermined code path. A multi-agent workload can choose steps at runtime, write or run code, and continue in a loop. Placing that workload directly on shared application infrastructure creates a difficult choice: broad access makes the agent useful but expands blast radius; severe restriction may stop it completing the assigned work.
The proposed pattern avoids treating those as mutually exclusive. Foundry remains responsible for governing the agent, while a sandbox contains the execution. The source emphasizes that sandbox inputs and results do not disappear from oversight: they remain traceable alongside the rest of the agent’s activity. For administrators, that separation means identity and policy should travel with the agent while network reachability, filesystem state and process isolation are enforced where the task runs.
Evidence and scale cited in the announcement
Microsoft gives three examples. KPMG’s Digital Gateway Powered by Claude uses engagement-specific workspaces for client separation; its DG Cowork environment is described as running more than 30,000 Azure Container Apps Sandboxes concurrently. Cognite Atlas AI uses governed workspaces over live data in Cognite Data Fusion, turning investigations that previously took days into traceable answers in minutes. For the Department for Education in South Australia, EdChat supports 60,000 students and more than 40,000 staff; the department estimates the managed sandbox model can retire close to 50,000 lines of custom code used to manage code-interpreter state.
Microsoft also states that more than one million sandboxes run per day in production across services including GitHub Copilot, Copilot Studio, Security Copilot, Foundry Agent Service and Azure SRE Agent. These are vendor claims, not a substitute for a workload-specific capacity test, but they clarify the target: large numbers of short, isolated agent executions rather than one long-lived shared worker.
Practical checklist for platform teams
- Map every tool an agent may call. Assign a separate Entra identity or scoped permission set; never reuse a broad human administrator account.
- Define sandbox egress, data sources, package installation rules, time limits and deletion behavior before pilot traffic begins.
- Send Foundry traces, sandbox logs, security events and cost data to an observable retention path. Test whether an operator can reconstruct one agent decision.
- Use synthetic or approved non-production data first. Verify that one tenant, engagement or user cannot read another task’s files or tokens.
- Exercise pause/resume, failure handling and a manual fallback workflow. Measure startup latency, concurrency limits and the cost per completed task.
- Review compliance ownership: who approves tool access, who investigates a harmful action, and who can immediately revoke an agent identity.
Conclusion
The important claim is not that every AI workflow needs a sandbox. It is that autonomous code execution needs a different boundary from agent governance. Microsoft Foundry plus Azure Container Apps Sandboxes offers a concrete Azure pattern: retain identity, evaluation and audit in the control plane; give each task an isolated runtime with narrowly defined access. Validate the pattern against real data classification, egress rules, recovery needs and budget before moving a pilot into unattended production.