Every containment story I’ve written this year has been about the sandbox — bubblewrap, Seatbelt, microVMs, blast radius. Microsoft’s September 23 blog post, “Designing agent-first platforms,” argues that’s the wrong layer to obsess over. Their bet: an agent without a real identity is unmanageable no matter how good your sandbox is, because you can’t audit, revoke, or scope permissions for something the system can’t individually recognize.

The three pieces

Microsoft ties together three things that used to be separate announcements:

  • Entra Agent ID — agents get their own identity object in Entra, not a shared service principal borrowed from a human account.
  • Azure Container Apps Sandboxes — hardware-isolated microVMs, which Microsoft says already run 1 million-plus sandboxes per day internally at Microsoft.
  • Foundry — the runtime layer that binds an agent’s identity to what it’s allowed to touch inside a given sandbox session.

The pitch is that identity and sandboxing aren’t competing containment strategies — sandboxing limits what an agent’s process can reach, identity limits what an agent’s credentials can reach, and you need both because a compromised agent with a sandboxed process but an over-scoped identity can still do real damage by calling out to an API it was never supposed to touch.

The numbers that make this more than marketing

Two customer references in the post are concrete enough to matter:

  • KPMG runs 30,000-plus concurrent sandboxes on this stack. That’s not a pilot number.
  • South Australia’s EdChat, serving roughly 60,000 students, migrated onto sandboxed Foundry runtimes and reportedly removed 50,000+ lines of code in the process — bespoke isolation and guardrail logic that Container Apps Sandboxes now handles natively.

That second number is the one I’d pay attention to as a Tech Lead. Every team building agent infrastructure ends up writing its own half-working sandbox-plus-permission layer, because until recently there wasn’t a good managed option. If EdChat’s 50K-line reduction is representative, that’s not a security improvement — it’s a maintenance-burden removal, which is a different budget line and a different argument to make to your VP.

Hands-on: scoping an agent identity in Bicep

Here’s roughly what registering a scoped agent identity looks like today:

resource agentIdentity 'Microsoft.Entra/agentIdentities@2026-06-01' = {
  name: 'invoice-processing-agent'
  properties: {
    displayName: 'Invoice Processing Agent'
    allowedScopes: [
      'Storage.Read.InvoicesContainer'
      'Foundry.Sandbox.Execute'
    ]
    sandboxProfile: {
      runtime: 'containerAppsSandbox'
      hardwareIsolation: true
    }
  }
}

resource sandboxSession 'Microsoft.App/sandboxSessions@2026-06-01' = {
  name: 'invoice-agent-session'
  properties: {
    agentIdentityId: agentIdentity.id
    maxDurationMinutes: 15
  }
}

The part worth noticing: allowedScopes lives on the identity, not on the sandbox session. That means the same agent code, deployed into two different sandbox sessions with two different identities, gets genuinely different permissions — not just different network policies. If you’ve ever tried to bolt least-privilege onto an agent by hand-rolling IAM roles per deployment, this is what Microsoft is trying to make a first-class primitive instead of a workaround.

Where I’m skeptical

Identity-first containment only helps if your team actually scopes identities tightly, and in practice most teams don’t — they grant broad scopes early to unblock development and never tighten them, the same way S3 buckets end up world-readable. Entra Agent ID makes fine-grained scoping possible; it doesn’t make anyone do it. I’d bet real money that six months from now, audits find agent identities in production with scopes three times broader than what the agent actually uses, because nobody revisited the Bicep file after the demo worked.

There’s also a lock-in question nobody’s asking loudly enough. Entra Agent ID is an Azure-native identity primitive. If your agent stack is meant to be portable — say, the same LangGraph agent running on AWS and Azure depending on customer region — you’re now maintaining two separate identity models, because AWS doesn’t have an equivalent yet and probably won’t ship one that’s compatible.

My actual take

If you’re already Azure-committed and running agents that touch real customer data — invoices, PII, payment flows — Entra Agent ID plus Foundry sandboxes is worth adopting now, specifically for the audit trail it gives you, not just the containment. When someone asks “which agent touched this record and under what scope,” you want an answer that doesn’t involve grepping application logs.

If you’re multi-cloud by design, treat this as a preview of where identity-scoped agent containment is heading everywhere, but don’t build your architecture around an Azure-specific primitive yet. The pattern is right. The implementation is still one vendor’s opinion.

One practical step either way: whatever cloud you’re on, start writing down which scopes each agent identity actually needs before you provision anything, not after. Teams that skip this step end up doing the audit in reverse six months later, trying to reconstruct intent from logs instead of reading it off a spec. A five-line YAML file per agent — name, allowed scopes, who owns the review — costs nothing today and saves a very uncomfortable meeting with security later.

Export for reading

Comments