Azure agent-first platforms: what changes now

Introduction

Traditional applications are built to respond to requests. Agent-based applications are different: they reason through tasks, execute code, and operate continuously with limited human intervention. For Azure architects and platform teams, that shift changes how enterprise AI workloads must be designed, secured, and operated.

Microsoft’s latest guidance highlights an emerging reference architecture for production-grade agents: govern the agent in Microsoft Foundry and run its task execution in Azure Container Apps Sandboxes.

What’s new

From request-response apps to autonomous agents

Microsoft argues that multi-agent applications no longer follow fully deterministic workflows. Instead of hard-coded paths, developers define outcomes and let agents determine runtime steps.

This creates new platform requirements:

• Agents need their own identity and scoped permissions
• Every step must be traceable and auditable
• Runtime guardrails must be enforced continuously
• Security and compliance standards must match the rest of the enterprise estate

Microsoft Foundry as the control plane

According to Microsoft, Foundry is the layer where agents are:

• Built and grounded in enterprise knowledge
• Assigned a first-class identity through Entra Agent ID
• Traced, evaluated, and governed in production

Foundry handles oversight and governance, but not necessarily the runtime where code execution happens.

Azure Container Apps Sandboxes for isolated execution

When agents move from answering questions to completing actions, they need a secure execution environment. Microsoft positions Azure Container Apps Sandboxes as that runtime layer.

Key capabilities include:

• Fully isolated environments per agent execution
• Hardware-isolated microVMs
• Sub-second startup times
• Identity-based access without storing credentials
• Pause-and-resume support for long-running tasks
• Scoped access and egress controls

This helps reduce the risk of running autonomous code on shared infrastructure.

Why this matters for IT and platform teams

For Azure administrators, security teams, and architects, the main takeaway is that agent workloads should not simply be added to existing app hosting patterns without redesign. Shared infrastructure can increase blast radius, while over-restricting permissions can make agents ineffective.

Microsoft’s proposed pattern aims to balance both needs:

1. Foundry for governance, identity, and observability
2. Container Apps Sandboxes for isolated execution

The result is a model intended to support thousands of concurrent agents without weakening enterprise controls.

Real-world examples

Microsoft cites:

• KPMG, using Azure Container Apps Sandboxes at global scale for engagement-specific AI workspaces
• Cognite, using Foundry and sandboxed execution to deliver traceable industrial investigations in minutes instead of days

Next steps

If your organization is planning enterprise AI agents on Azure, consider these actions:

• Review whether current app platforms are suitable for autonomous code execution
• Evaluate identity, audit, and runtime isolation requirements for agents
• Explore Microsoft Foundry for agent governance
• Assess Azure Container Apps Sandboxes for secure task execution environments

Agent-first design is quickly becoming a platform architecture question, not just a model selection decision.