Agent Identity: Who the Agent Is When It Calls Something

What this slice covers

When an agent calls a tool that reads a storage account, some identity is presented and some permission check happens. This note covers whose identity that is, where it comes from, how it changes when you publish an agent, and why the three most common tool-authentication failures are all identity problems wearing different masks. It is the security slice of agent development, and it is the one most likely to be skipped and then learned expensively.

The core idea

An agent identity is a specialised identity type in Microsoft Entra ID designed specifically for AI agents. Concretely, it is a service principal representing the agent at runtime — a first-class actor in the directory, distinct from the human who built the agent and distinct from the application hosting it.

That distinctness is the whole point. It lets an organisation separate what agents did from what employees, customers, and workloads did; grant agents right-sized access rather than borrowed access; keep agents out of sensitive administrative roles; and manage identity at a scale where agents are created and destroyed quickly. Foundry provisions and manages these identities across the agent lifecycle, so this is largely infrastructure you inherit rather than build.

Alongside the identity sits an agent identity blueprint: a reusable governing template corresponding to a class of agents. It carries the type classification, so administrators can apply conditional access to every agent of that kind or revoke them together, and it holds the credentials used to create identities and to authenticate at runtime.

What happens when a tool is called

When an agent invokes a tool, a multi-step OAuth token exchange runs automatically between Agent Service, Entra ID, and the downstream resource. Developers do not manage tokens directly.

The sequence is worth knowing in outline because it explains the error messages. Agent Service first authenticates the blueprint to Entra ID. Entra ID then issues a token for the specific agent identity — a token distinct from a user token or a managed identity token. Agent Service presents that token back and requests a new access token scoped to the audience of the downstream service. Finally, the scoped token is passed to the tool endpoint, which validates it and checks the agent identity's role assignments before allowing or refusing the call.

Audience is the term to fix. It is the OAuth resource identifier of the target service — the storage resource identifier for Azure Storage, the Key Vault one for Key Vault, and so on — not the address of the MCP server you are calling. An incorrect audience produces an authentication failure even when every role assignment is right, which is why this failure is so confusing the first time.

In Foundry the recommended credential arrangement removes stored secrets: the blueprint holds a federated credential trusting the project's managed identity, so no client secret or certificate sits in the configuration and Azure handles rotation. Note the subtlety — the managed identity authenticates the blueprint; the agent identity is the principal that needs role assignments on the target resource.

Shared identity, then a distinct one

When you create your first agent in a project, Foundry provisions a default blueprint and a default agent identity. All unpublished, in-development agents in that project share one identity. This is a deliberate convenience: administrators configure permissions once, identity sprawl during experimentation is avoided, and developers can then build and test without asking for new grants each time.

Publishing changes the picture. A published agent gets its own dedicated blueprint and agent identity, bound to the agent application resource. That is appropriate for agents heading toward integration testing or production, agents that need a unique permission set, or agents that need an independent audit trail.

Here is the consequence you must internalise: permissions assigned to the shared project identity do not carry over. When you publish, you have to reassign the roles the agent needs to its new identity. Everything working in development and failing immediately after publication is the classic symptom, and it is not a bug.

Assigning and checking permissions

Because the agent identity is an ordinary service principal, you assign roles to it exactly as you would to any other — using the agent identity's identifier as the assignee, at the narrowest scope that works. Prefer a resource or resource group scope over a subscription-wide grant, and grant only the permissions the agent's tool actions actually require. You can find the relevant identifiers from the JSON view of the project (for the shared identity) or of the agent application (for a published agent's distinct identity).

Support is not universal yet: today MCP servers and agent-to-agent tools are the tools that authenticate with an agent identity. Other tools may use key-based authentication or OAuth passthrough, so check the tool's own documentation.

The three failures

Roles assigned to the wrong identity — usually the shared one after publishing. Missing role assignments on the target resource. An incorrect audience value. Diagnose in that order, and you will resolve most tool-authentication problems without touching a line of agent code.