Azure pushes platforms agent-first and isolates every agent execution in a hardware microVM
On September 23, 2026, Mike Hulme, Azure’s GM of product marketing, describes the shift from request-response applications to continuously acting multi-agent systems, and Microsoft’s answer: govern the agent on Foundry, execute it in an isolated Azure Container Apps sandbox. For platform teams, it is a concrete framework for what must change when the agent replaces the request.
September 23, 2026. Mike Hulme, Azure’s general manager of product marketing at Microsoft, publishes a post that describes less a launch than a paradigm shift. For decades, applications have been designed to wait: a user clicks, a request arrives, code runs, a response goes back. What is changing now is not the infrastructure underneath, but the software on top: the work we used to capture as deterministic code is being rewritten as multi-agent applications that figure out their steps at runtime. Why it matters: an application that responds and an agent that acts need very different things underneath them, and most platforms are still built on the assumptions of the former.
An agent does not work like a request
Given an outcome, an agent reasons through the problem, breaks it into steps, writes code to solve it, runs that code, looks at the result, and goes again. The work happens in a loop that no human is standing inside. Mike Hulme puts the observation bluntly: “the organizations pulling ahead right now are not simply adding AI to what they already have — they are designing for a different kind of software.”
The hard part is no longer getting an agent to work. A team can connect a capable model to a few tools, ground it in company data, and have a genuinely useful pilot inside a week. The real distance sits between that pilot and an agent the business depends on around the clock.
An agent operating continuously on a company’s behalf is held to the same bar as everything else in production. It needs its own identity, with permissions scoped to what it is allowed to see. It needs to be watched while it works, so a team can trace every step, evaluate whether the outcome was right, and catch the drift that shows up quietly weeks after launch. It needs guardrails enforced at runtime. And it has to clear the same security and compliance standards as the rest of the estate — nobody grants an agent an exemption.
Two separate layers: govern, then execute
Microsoft’s answer separates two responsibilities most teams conflate. Microsoft Foundry is where agents are built, grounded in enterprise knowledge, given a first-class identity through Entra Agent ID, then traced and evaluated once live. The Foundry Control Plane governs the agent — but it does not dictate where the agent’s work actually runs. That is a separate decision, and a separate layer.
Where the work runs is where it gets hard. The moment an agent stops answering questions and starts completing tasks, it has to execute code: clone a repository, install a package, run an analysis against live data, call into a system of record. That execution needs a runtime environment — and in most cases it simply inherits the host application’s environment, the path of least resistance.
That is where most promising agents stall. Run the agent on shared infrastructure and every workload inherits the blast radius of every other one. Give it broad access so it can be useful, and you have handed an autonomous process far more reach than you intended. Lock it down until it is safe, and the agent can no longer do the job you built it for.
Azure Container Apps Sandboxes: isolate the execution, not the power
The answer is not to limit what the agent can do, but to give it a dedicated environment, with its own identity and guardrails for execution. Azure Container Apps Sandboxes provides exactly that. Every agent execution gets a fully isolated environment, created in seconds and gone when the work finishes. It runs as an identity you control, can reach only the systems you have allowed, and never stores the credentials it uses to get there. When a task spans hours or days, the environment can be paused and resumed with its full working context intact.
There is real engineering behind it: each environment runs inside its own hardware-isolated microVM, which makes strong separation and sub-second startup possible at the same time. But the mechanism is not the point. Isolation is built into the runtime rather than wrapped around it, so teams stop choosing between a capable agent and a controlled one. And nothing disappears into the sandbox: the agent is still governed by Foundry, so what it sent into the sandbox and what came back stay on the record alongside every other step it took.
The pattern that emerges: two case studies
Put together, the two pieces form a recurring motif across large enterprises: build and govern on Foundry, extend execution into an isolated Azure Container Apps sandbox. The agent keeps its identity, its permissions, and its oversight — only the ground it runs on changes. KPMG, through its Digital Gateway platform, runs more than 30,000 concurrent Azure Container Apps sandboxes to keep client data separated by engagement. Cognite, for its industrial operators, lets Atlas AI agents execute arbitrary code in sandboxes that isolate each user, environment, and dataset — turning a days-long manual investigation into “which wells are underperforming and why?” into a cited answer delivered in minutes.
What hardware isolation actually changes
The nuance sits in the word “hardware”. Most execution sandboxes — containers, namespaces, software virtual machines — isolate at the kernel or hypervisor level, sharing part of the attack surface with the host. Azure Container Apps Sandboxes mounts every execution in a hardware-isolated microVM: the separation is enforced by the processor, not merely by software configuration.
That choice changes the nature of the trade-off. A software sandbox starts fast, but its boundary rests on the quality of its configuration and patches. A hardware-isolated microVM keeps sub-second startup while offering a boundary that workloads of differing trust cannot cross — the kind of guarantee a CISO will accept when several clients share one infrastructure.
The second effect is administrative. When isolation is hardware-level, the trust you place in an agent no longer depends on where it runs or what runs next to it. That is what lets an organization move from a handful of supervised agents to thousands of concurrent executions without asking security teams to surrender their standards.
For platform teams, the two case studies carry the same message: the organizations that scale agents are the ones that stopped treating agent execution as a special case of the host application’s runtime. They built the isolated ground first, and let the agents — and the number of them — grow on top of it.
Verdict
If you are designing an internal platform for agents, remember the separation: governance (identity, traceability, evaluation) is one layer, isolated execution is another, and merging them means every workload inherits the blast radius of every other one. If you are on Azure, test Azure Container Apps Sandboxes for agents that execute code: the hardware-isolated microVM with sub-second startup resolves the “capable but uncontrolled” trade-off that blocks most production rollouts. If you are elsewhere, the pattern still transfers: it is not the agent you should constrain, it is the ground under its feet you should isolate.