Microsoft Foundry Agent Identity and Blueprint: Who Gets the Permission, and Who Does a Blueprint Change Affect?

Part 1listed the governance questions to settle before an agent ships, and Part 2 used an access package to manage a 30-day read permission for the meeting-prep agent. This part adds just one more question: which identity actually ends up holding the resource permission? And who is affected when a Blueprint changes?

Grant resource permissions to the identity your tools actually use, and check which identities a Blueprint is linked to before you change it. Downstream systems identify the calling principal from the access token.

1. Separate the agent itself from the Blueprint that creates its identity

The meeting-prep agent is a Foundry object that stores the model, instructions, and tool configuration. When a tool authenticates with an Agent Identity, that identity is the caller the downstream resource sees. The Agent Identity Blueprint creates and authenticates these identities and holds settings that identities can share. A Blueprint here is an Entra identity blueprint — not a prompt or workflow template. Agent Identity Blueprint

A simplified way to hold the relationships:

Simplified diagram: the Agent Identity is the principal downstream resources see; the Blueprint holds authentication settings and can affect linked identities through explicit permission-inheritance settings. Real Foundry connections may also use user delegation, a project Managed Identity, or another authentication method.

Entra also shows a Blueprint Principal: the Blueprint's object in your tenant, which records this tenant's permission consent for the Blueprint. It is not the identity the agent uses when it accesses customer records. Blueprint Principal notes

When troubleshooting, go by ID, not display name. In Graph, agentIdentityBlueprintId corresponds to the Blueprint's appId; the Blueprint Principal has its own Object ID. The two are not the same ID. Agent Identity field definitions

2. First confirm which Foundry agent model you are on

This series follows the new Foundry model: a newly created agent gets its own Blueprint and Agent Identity. Under the old model, unpublished agents could share the project identity, and only an agent published as an Agent Application got a dedicated identity. Both models may coexist today; after a migration or rebuild, re-verify identity IDs and resource grants. Official migration guidance

A Blueprint in Entra can manage multiple identities, but don't infer from that that new-model agents in the same Foundry project share a Blueprint.

3. The identity is separate — so why does it depend on the Blueprint?

An Agent Identity is a special kind of service principal (the Entra object that represents an app or service). It has no credentials of its own and depends on the Blueprint's authentication configuration to obtain tokens. What makes up an Agent Identity

Foundry configures federated identity credentials for the Blueprint, and the Agent Service manages the runtime token exchange. When a tool authenticates as the Agent Identity, the token the target resource receives represents that identity; this managed flow means developers don't need to configure a client secret or certificate of their own. Foundry identity and token exchange

The chain reduces to:

Agent Service → obtains a token using the Blueprint's authentication settings
              → calls the customer-record tools as the specific Agent Identity
              → the target system checks that identity's access

So troubleshoot authentication and authorization separately: if Blueprint authentication fails, no token is issued; if the identity authenticates but the resource has no grant for it, the call is still denied. An MCP connection may also use a project Managed Identity, Entra delegation that carries the current user's permissions, or an OAuth passthrough where the user signs in separately. Check which method a connection actually uses before you debug further. MCP tool authentication methods

4. Permissions can be granted individually or inherited from the Blueprint

The previous part managed read permission through security-group membership — an authorization path for one specific identity. A Blueprint can also be configured for OAuth API permission inheritance, letting linked identities reuse qualifying permissions.

Keep "declare" and "grant" apart:

Declaring a permission is not the same as being granted it. Static consent requires the permission to be listed in Required resource access first; dynamic consent can skip pre-declaration, but must explicitly request the permission at request time. Either way, the resource must be listed in the inheritance configuration and consent must be granted to the Blueprint Principal before qualifying permissions flow into linked identities' tokens. An OAuth permission granted directly to one Agent Identity applies to that identity only. Declaration, grant, and inheritance

The inheritance configuration controls delegated scopes (API access on behalf of a user) and application roles (API access as the agent itself) separately. allAllowed brings every permission on the specified resource that meets the grant conditions into inheritance scope, and permissions added and approved later may also be inherited. Inheritance configuration details

Azure RBAC, group membership, and Access Packages are not inherited automatically. In our example, if the agent can still read customer records after the 30-day access package expires, check for direct grants or inherited OAuth permissions. Which authorization the customer API actually accepts has to be confirmed on the resource side.

Inherited permissions don't show up as standalone entries on the Agent Identity; they are merged at token issuance. Inspect the token's scp (delegated) and roles (application) claims, and verify what the customer API actually returns. How inherited permissions appear at runtime

5. Before you modify a Blueprint, confirm what it affects

In the Entra admin center, go to Entra ID > Agents > Agent blueprints and open the Blueprint Principal to see Linked agent identities and Granted permissions. The former confirms which identities are linked; the latter shows the consents already granted. The inheritance configuration still needs a separate check. Managing Blueprints

A Conditional Access policy targeted at a Blueprint covers the Agent Identities it creates, including identities added later. Entra decides at token issuance whether the policy conditions are met; the policy does not replace the target resource's own authorization check. Agent Conditional Access

It does not automatically cover the agent's user account. For OBO (on-behalf-of a signed-in user), check the user's policies; API-key calls never pass through Entra token issuance, so this kind of Conditional Access policy does not protect them.

Entra's architecture guidance plans Blueprints around trust boundaries: agents that can share a runtime and authentication material, and accept common risk, can share one Blueprint; split them when credentials or the runtime must be isolated. Splitting a Blueprint by itself does not isolate networking, the runtime, or data storage. Planning your agent identity architecture

6. Back to the meeting-prep agent: leave a verifiable record

Four items in the launch record are enough to help troubleshooting: the Agent Identity ID, the Blueprint Application ID, the Blueprint Principal Object ID, and the authentication each tool actually uses — plus a note on whether the authorization comes from an access package, a direct OAuth grant, or inheritance.

When you verify, test an allowed and an out-of-scope customer record, a fresh token after the access package expires, and the linked identities' results after a Blueprint policy change. Existing tokens and tool caches can distort what you observe, so check them separately. These are verification steps to run, not results measured in a tenant.

The whole part reduces to this: confirm the calling identity first, then check both what that identity was granted directly and what it inherits from the Blueprint; when you modify a Blueprint, assess the impact by its linked identities and trust boundaries.

You can outsource your thinking, but you cannot outsource your understanding.

Official references

• Agent Identity Blueprint and Blueprint Principals
• Old and new Foundry agent models and migration
• Agent Identity and Foundry runtime authentication
• Permission declaration, grant, and inheritance
• Configuring inheritable permissions on Blueprints
• Agent Conditional Access
• Planning agent identity architecture