A practical identity architecture guide for security, governance, and troubleshooting

Executive summary

When an agent is created in Azure AI Foundry, multiple identity-related objects can appear across Azure and Microsoft Entra ID, including managed identities, Agent Identity Blueprints, Blueprint Principals, and Agent Identities. This article explains how those objects relate and clarifies which runtime identity should receive RBAC permissions for downstream resources.

A note on naming: Microsoft’s platform naming is evolving. This article uses “Azure AI Foundry” and “Microsoft Foundry” to refer to the same platform, and “Agent 365” refers to the portal where agent identities can be viewed.

Why this matters

  • Security teams need a reliable way to distinguish agent actions from user, workload, and managed identity actions.
  • Identity administrators need to know which object to inventory, govern, disable, or review.
  • Cloud administrators need to assign RBAC permissions to the right runtime identity, not simply the most visible managed identity.
  • Developers and architects need to understand why publishing or changing an agent can introduce a distinct identity that requires new role assignments.

Problem statement

The main challenge is that Foundry-created identity objects can look similar in Graph exports or the Entra admin center even though they serve different purposes. Without joining the objects by identifiers, it can be difficult to determine which object represents the project, which one defines the agent blueprint or trust boundary, and which one acts as the runtime security principal. This article uses exported object evidence to clarify those relationships and explain why multiple blueprint and agent identity hierarchies can be expected.

What objects are created when an agent is created in Azure AI Foundry?

When a Foundry project is created, the identity model typically spans both Azure resource identities and Entra Agent ID objects. The Foundry account-level managed identity appears in the Enterprise applications blade in Microsoft Entra ID, while the project-level identity can also appear in the Agent Identities blade under Agents in the Entra admin center.

Creating an agent can add separate identity objects for the agent lifecycle. In the observed pattern, Foundry creates one Agent Identity Blueprint and Agent Identity for the unpublished or draft agent, and another pair for the published agent. Each blueprint has its own Blueprint Principal, represented as a service principal in Microsoft Entra ID.

In this pattern, a single Azure AI Foundry project with one agent can surface eight related objects: two Agent Identity Blueprints, two Blueprint Principals, two managed identities, and two Agent Identities. These are not duplicates; they represent the Foundry account, project, draft agent, and published agent layers. In the Entra Agent Identities blade, you may see three entries because the project managed identity can also appear as an Agent Identity. The actual agent identity is also visible in the Agent 365 portal under the Agents tab.

To validate the relationships, use Graph exports and join the objects by their identifiers rather than by display name.

Two identity planes: Azure resource identity and agent identity

The simplest way to reason about the object model is to separate it into two planes. The first is the Azure resource identity plane, where managed identities belong to Foundry account and project resources. The second is the agent identity plane, where Entra Agent ID objects represent the blueprint, the service principal instance of that blueprint, and the runtime agent identity.

Plane

Objects

Primary purpose

Azure resource identity plane

Foundry account managed identity; Foundry project managed identity

Represents Azure resources and enables secretless platform authentication or account/project-level access where RBAC is explicitly assigned.

Agent identity plane

Agent Identity Blueprint; Blueprint Principal; Agent Identity

Represents agent trust, lifecycle governance, and runtime access to tools or downstream resources.

Core object types and how to interpret them

The table below summarizes each object type, how to recognize it in a Graph or Entra ID export, and what it means operationally.

Object type

What it represents

How to identify it

Operational implication

Foundry Account Managed Identity

Azure resource identity for the Foundry / Cognitive Services account.

servicePrincipalType = ManagedIdentity; alternativeNames can show the Azure resource path.

Use for account-level scenarios only where RBAC is intentionally assigned to the account identity.

Foundry Project Managed Identity

Azure resource identity associated with a Foundry project.

servicePrincipalType = ManagedIdentity; project-related display name and Foundry tags may be present.

Often participates in the trust chain used to authenticate the blueprint; do not assume it is the runtime identity for tool access.

Agent Identity Blueprint

Reusable governing object for a class or scope of agent identities.

@odata.type = #microsoft.graph.agentIdentityBlueprint.

Defines the trust context used during token exchange and lifecycle operations.

Blueprint Principal

Service principal representation of the blueprint in the tenant.

@odata.type = #microsoft.graph.agentIdentityBlueprintPrincipal.

Its appId maps back to the Blueprint Application id/appId.

Agent Identity

Runtime service principal representing the agent.

@odata.type = #microsoft.graph.agentIdentity; servicePrincipalType = ServiceIdentity.

This is the identity that should receive RBAC on downstream resources when the agent calls tools.

Relationship map from exported objects

The relationship pattern is easier to understand when the objects are joined by identifiers rather than by display name. In the export used for this analysis, the Agent Identity points to its parent Blueprint Application through agentIdentityBlueprintId. The Blueprint Principal points back to the same Blueprint Application through appId.

Why multiple blueprints and agent identities can exist

Multiple blueprint and agent identity hierarchies are not necessarily a sign of duplication or misconfiguration. They can reflect different identity scopes and lifecycle states. For example, a Foundry project may have a shared project identity for unpublished or in-development agents, while a published agent can receive a distinct identity tied to the agent application resource. This design supports separation of duties, more precise permissions, and clearer audit boundaries.

  • A shared project identity can simplify early development because multiple unpublished agents can use the same access pattern.
  • A distinct agent identity supports production-grade governance when a specific agent requires unique permissions, auditability, or lifecycle treatment.
  • A published agent may require new RBAC assignments because permissions granted to the shared project identity do not automatically prove the distinct runtime identity has the same access.
  • Different blueprints can represent different trust or lifecycle boundaries, such as project-level identity versus agent-specific identity.

Runtime authentication flow

At runtime, the managed identity and agent identity have different responsibilities. The managed identity participates in authenticating the blueprint. The agent identity is the runtime principal that receives a scoped token and is evaluated by downstream resources. This distinction matters when troubleshooting access failures.

Practical guidance for inventory, RBAC, and troubleshooting

Inventory the identities

  • Start with Agent Identity objects because they represent the runtime principals that agents use.
  • Join AgentIdentity.agentIdentityBlueprintId to the Blueprint Application id.
  • Join the same Blueprint Application id to BlueprintPrincipal.appId to locate the service principal representation of the blueprint.
  • Record whether the identity is shared at the project level or distinct for a published agent.

Assign RBAC to the correct identity

  • For downstream tool access, assign RBAC to the runtime Agent Identity rather than assuming the Foundry account or project managed identity is sufficient.
  • After publishing an agent or moving it from development to production, recheck which identity is used for tool calls.
  • Prefer least privilege scope wherever possible; avoid subscription-wide assignments unless explicitly required.

Troubleshoot access failures

  • Confirm the agent is using the identity you expect: shared project identity or distinct/published agent identity.
  • Verify role assignments on the target downstream resource for that identity.
  • Validate the token audience for the downstream service when tool authentication fails.
  • Avoid troubleshooting against display names only; use object IDs, app IDs, and blueprint relationship fields.

Governance considerations

Agent identity governance should treat agents as first-class identities. That means keeping an inventory of agent identities, understanding the blueprint relationship, assigning least privilege access, and reviewing access when agents move between development, testing, and production states.

Governance question

Why it matters

Which Agent Identities exist in the tenant?

Supports inventory, ownership, and lifecycle tracking.

Which Blueprint Application created or governs each Agent Identity?

Supports relationship mapping and policy review.

Which identity has RBAC on downstream resources?

Prevents access failures and reduces over-permissioning.

Did publishing create a distinct identity?

Ensures production agents receive the required permissions and audit separation.

Are shared identities being used beyond development?

Helps reduce blast radius and improve auditability for production agents.

Key takeaways

  • Do not treat all Foundry-created identities as interchangeable. Managed identities, blueprints, blueprint principals, and agent identities each serve a different role.
  • The Agent Identity is the runtime principal that should receive downstream RBAC for tool access.
  • The Blueprint Application and Blueprint Principal are linked through appId; the Agent Identity links to the blueprint through agentIdentityBlueprintId.
  • Multiple blueprint and agent identity hierarchies can be expected when the environment contains shared project identities, published agents, or different lifecycle scopes.
  • For reliable troubleshooting, use join properties and object IDs rather than display names alone.

Conclusion

Azure AI Foundry introduces an agent identity model that is more granular than a traditional single service principal or managed identity pattern. That granularity is valuable because it separates platform authentication, blueprint trust, runtime agent identity, and downstream authorization. The tradeoff is that architects and administrators must understand how the objects relate before assigning RBAC, investigating access, or building governance dashboards.

The most important distinction is simple: the managed identity helps authenticate the blueprint, while the Agent Identity represents the runtime agent principal. When the agent calls a downstream resource, access should be evaluated against the Agent Identity that is actually being used by the agent. In development, this may be a shared project identity. In production or published scenarios, it may be a distinct identity that needs its own role assignments.

A practical governance approach is to inventory Agent Identities first, join them back to their Blueprint Applications using agentIdentityBlueprintId, locate the corresponding Blueprint Principals through appId, and then verify RBAC on downstream resources. This method creates a repeatable way to map Foundry-created objects, reduce identity confusion, and strengthen agent security as organizations scale from experimentation to production deployments.

References

→ Related reading

24 min read

AI Red Teaming: A Risk-Based Methodology for When, Why, and How

AI red teaming has emerged as a foundational security control for organizations deploying artificial intelligence — analogous to penetration testing for traditional applications, but distinct in scope, technique, and risk profile. Unlike standard security assessments, AI red teaming…

AI Security Microsoft
2 min read

Securing Enterprise AI: An Identity-First Approach

As enterprises move from AI pilots to agentic systems that act on their behalf, identity becomes the control plane. Here is how I think about securing AI agents with the same rigor we apply to human and workload identities.

AI Security Microsoft Identity
2 min read

Using AI to Optimize SOC Operations

Security Operations Centers are drowning in alerts while the metrics that matter — mean time to detect and respond — barely move. Here is how AI-driven automation and analytics change the operational math.

SOC AI Security Microsoft

Discussion

Comments are powered by Giscus / GitHub Discussions. They appear here once configured — see Configure Giscus in the project README and update GISCUS in src/consts.ts.