Microsoft's Agent Identity Model Is the Blueprint to Steal

Most AI agents running in production right now authenticate like it's 2012: one service principal, an API key in an environment variable, and every permission anyone ever asked for stapled onto it because removing one might break something. That works fine until the agent is the thing making decisions — at which point you've built a textbook confused deputy, with prompt injection as the trigger. A poisoned email or web page convinces the agent to act, and it acts with the full authority of that over-privileged account.

Microsoft Foundry's answer to this has been quietly assembled over the past year, and it's the most complete one shipping today: agents get first-class identities in Microsoft Entra, and every action an agent takes is routed through one of three distinct permission planes. It's a genuinely good design — and it comes with a publish-time trap that will break your deployment the first time you hit it, plus lock-in you should price in before adopting.

Three planes, not one account

The core move is to stop asking "what can the agent do?" and start asking "on whose authority is this specific action happening?" Foundry's model gives you three answers:

User-present work runs on-behalf-of the user. When a signed-in human invokes the agent, Foundry uses OAuth 2.0 token exchange: the app passes the user's token to Agent Service, which swaps it for a token carrying both the agent identity and the user's delegated permissions. The agent reading your calendar to prep a meeting can only see calendars you can see, filtered further by the delegated scopes the app requested, admin consent, and Conditional Access. This is the same RFC 8693 machinery enterprises already use for middle-tier APIs, applied to agents — which matters, because your existing audit and consent tooling already understands it.

Background work runs on the agent's own identity. Scheduled and autonomous tasks use the client-credentials flow with a dedicated agent identity — a real Entra service principal you assign Azure RBAC roles to, exactly like a managed identity:

az role assignment create \
  --assignee "<agentIdentityId>" \
  --role "Storage Blob Data Contributor" \
  --scope ".../storageAccounts/<account>"

No human in the token, no inherited user privilege, and the blueprint-plus-federated-credential chain means no stored secrets. The identity shows up in the Entra admin center's agent inventory alongside every Copilot Studio agent in the tenant, with Conditional Access and identity protection applying to it like any other principal.

Irreversible work gets a human gate regardless. For MCP tools, Foundry's require_approval defaults to "always" — the run pauses and returns the pending tool call for explicit sign-off before anything executes. RBAC answers "is this allowed?"; the approval gate answers "should this happen right now?" — and for sending bulk email or writing to a CRM, those are different questions. Correct permissions plus a prompt-injected agent still equals a bad outbound email; the gate is the only plane that catches intent, not just authority.

If you're not on Azure, steal the taxonomy anyway. Delegated, autonomous, and approval-gated are the three modes every agent framework eventually rediscovers — usually after an incident.

The publish-time trap

Here's the sharp edge. During development, every unpublished agent in a Foundry project shares one project-level agent identity. That's convenient — prototype freely, configure permissions once — and it quietly accumulates scope: every permission any prototype in the project ever needed ends up on one shared principal. Microsoft's own docs tell you to treat it as "a broader blast radius," which is doc-speak for your dev environment is over-privileged by design.

Then you publish, and the agent receives a brand-new, distinct agentIdentityId — with zero role assignments. Nothing carries over from the shared identity. The docs are explicit: you must manually reassign every RBAC role to the new principal. So the failure mode is a one-two punch: dev "works" because the shared identity is fat, and prod fails with authorization errors because the fresh identity is empty. If you're doing CI/CD, that reassignment has to live in your pipeline — the Azure Developer CLI handles the dev-side assignment but leaves published-agent roles to you.

Budget a debugging sequence for when tool calls 403: confirm which principal actually made the call (shared vs. distinct identity), verify the role assignment exists on that principal, check the scope, then check the token audience. That last one is the sleeper — the audience must be the downstream resource (https://storage.azure.com for Storage), not the MCP server's URL, and getting it wrong fails authentication even with perfect RBAC.

Second caveat: agent-identity authentication currently only covers MCP and Agent-to-Agent tools. Everything else in the tool catalog still uses keys or connection-level auth, so the clean identity story has real coverage gaps today.

Ahead of the pack, priced accordingly

Judged against the field, Microsoft is meaningfully ahead. AWS's Bedrock AgentCore ships identity primitives but nothing like tenant-wide agent inventory with Conditional Access; Okta and Auth0 are building agent-auth products atop the same token-exchange standards; the IETF's WIMSE working group is still standardizing what Entra Agent ID already does in production. Being early has a price tag, though: the full governance story — inventory, policy, Defender integration — lands in Microsoft Agent 365, generally available since May at $15 per user per month standalone. Identity is the platform; governance is the upsell.

And the whole model is Entra-shaped. The three-plane pattern is portable; the implementation is not. If your agents need to touch non-Azure resources, you're back to bridging identities yourself at the MCP-server boundary.

Verdict: this is the real blueprint, not hype — the first agent permission model that maps cleanly onto identity infrastructure enterprises already run and audit. If you're deploying agents on Azure, adopt it now and script the publish-time role reassignment before it bites you. If you're anywhere else, copy the three questions it forces you to answer for every tool call: whose authority, how scoped, and does a human need to say yes. Your single over-privileged service account answers none of them.