Microsoft Foundry Agent Identity Governance: Agent Identities, Blueprints, and Managed Identities

Today, I want to look at how Microsoft Foundry governs permissions for AI agents. Once an agent moves beyond answering questions and starts calling tools, accessing data, and taking actions, a more fundamental question emerges: Who actually performed this operation?

Many teams focus first on whether the model, prompt, and tools work well, then address permissions only when production approaches. This often leads to one of two extremes. With too few permissions, everything works in development but fails with a 403 in production. With too many, teams keep adding access to meet deadlines, and the agent ends up running with far more authority than its task requires.

The first failure is noisy and therefore easier to spot. The second may remain invisible until the agent reads data it should not see, writes to the wrong system, or sends a message the user never intended to send. By the time the team investigates, it may not even be clear whether the operation represented the user or the system.

This article does not cover configuration steps. Instead, it builds an identity map for readers who are new to agent governance.

Why Do Agents Need Identity Governance?

A conventional chatbot primarily generates content. An enterprise agent may also read files, update a CRM system, send email, and chain multiple tools into a workflow. The model is no longer just producing an answer; within defined boundaries, it is also deciding what to call next.

An enterprise therefore needs to ask more than whether an agent can complete a task. It must also answer five questions:

1. Who initiated the request?
2. Which identity does the agent use to access downstream systems?
3. What is the maximum authority granted to that identity?
4. Which actions require explicit human confirmation?
5. If something goes wrong, can the organization audit, revoke, and disable the agent?

These questions correspond to the caller, identity, authorization, approval, audit, and lifecycle. A prompt can influence behavior, but it is not a permission boundary. Real boundaries must be enforced by the identity system, downstream authorization, and deterministic controls.

Consider a simple example. An employee asks an agent to “prepare me for tomorrow's customer meeting.” Fulfilling that request may involve three separate operations: reading the employee's email, retrieving product information from a team knowledge base, and writing the result back to the CRM system.

Although these calls belong to the same task, they carry different business responsibilities. The first represents the employee, the second may represent the organization, and the third changes the state of a business system. If the agent receives one general-purpose API key, all three boundaries collapse into a single statement: “the agent can call it.”

The more dangerous failure is that this broad access does not produce a 403. When permissions are insufficient, the system rejects the request. When they are excessive, the system cooperates. The agent might use the same key to read another employee's email or write internal information into a customer-visible field, while the downstream service simply returns 200. In the logs, data exposure may look exactly like a normal call.

Identity governance exists to separate these boundaries again, giving each class of operation its own permission ceiling and audit attribution.

The Four Foundry Identity Concepts Most Often Confused

Microsoft Entra Agent ID treats an agent as a principal that can be identified, authorized, and audited independently. Foundry creates and manages the related objects across the agent lifecycle. Around a single tool call, four concepts are particularly easy to confuse:

The important point is not to memorize the names, but to recognize that they belong to different layers:

Project Managed Identity --authenticates--> Agent Identity Blueprint
Agent Identity Blueprint --creates and governs--> Agent Identity
Agent Identity --obtains an audience-scoped token--> Tool / Downstream Resource

This is a simplified view of the Foundry agent identity token exchange. According to the official identity documentation, the Project Managed Identity authenticates the blueprint in this flow, while the Agent Identity is the principal that needs RBAC access to the target resource.

However, do not stretch that conclusion into “Project Managed Identity can never access a tool.” Foundry MCP connections can also explicitly use project-managed-identity authentication. In that configuration, the corresponding permissions must be assigned to the Project Managed Identity. To determine which principal needs access, inspect the authentication method actually selected by the tool connection rather than relying on the project or agent name alone.

Is a Key Stored in a Connection Another Agent Identity?

No. A Foundry Project Connection can store an API key, bearer token, or OAuth configuration, or it can select an Entra identity-based authentication method. It answers the question “How does this tool authenticate?” but does not necessarily give the agent an independent, governable Entra identity.

Suppose ten agents share the same third-party API key. The downstream logs may show only that key and, by themselves, may not reveal which agent initiated the request. At a minimum, the application layer must also record the agent, tool, arguments, and correlation ID, while the organization defines how the key is stored, rotated, and revoked.

When Agent Identity or delegated user access is available, it is usually easier to establish separate permission and audit boundaries. When a key is the only option, the blast radius of that shared credential must be managed as an explicit risk.

How Is Agent Identity Different from a Traditional Application Identity?

In Microsoft Entra, an Agent Identity is still implemented as a service principal, but it is explicitly identified and governed as an AI agent identity. The Microsoft Entra Agent ID documentation emphasizes that this model distinguishes actions performed by agents from actions performed under workforce, customer, or other workload identities. It also supports governance at the scale of agents that may be created and destroyed rapidly.

Agent Identity is therefore more than “one more account.” It enables an organization to establish that:

• An operation was performed by an AI agent, not directly by an employee.
• The agent has its own owner, sponsor, permissions, and lifecycle.
• The agent can be inspected, disabled, or revoked independently, without rotating a key shared by multiple applications.
• Different agents can have separate permission and audit boundaries.

For governance, the Microsoft Entra admin center provides an Agent identities inventory where administrators can inspect identities in the tenant, open their blueprints, or disable them:

Image source: Microsoft Learn

Why Separate Development and Production Identities?

Identity governance determines more than whether a call is currently allowed. It manages the entire lifecycle of an agent, from creation and testing through publication and retirement.

Within a Foundry project, unpublished prompt agents share the project's agent identity by default. This is convenient for rapid experimentation, but it also means that several agents under development share one permission boundary. If an agent needs different permissions, independent auditing, or is preparing for production, it should not remain on the shared identity.

This shared identity is not merely an abstract concept. Open the project's Resource JSON in the Azure portal and you can see the agentIdentity field, together with its agentIdentityId and blueprint ID:

Image source: Microsoft Learn

When an agent is published as an Agent Application, Foundry creates a dedicated blueprint and Agent Identity for it. The new identity does not automatically inherit the RBAC assignments of the shared development identity. This change reflects the governance principle itself: a production agent should have a clear permission and lifecycle boundary. I will cover role reassignment after publication, and the difference between the new and shared identities, in the next practical article.

OBO and Independent Identity Answer Two Different “Who” Questions

Agent identities support two common runtime patterns:

• Attended / delegated access: A user is present, and the agent uses the On-Behalf-Of (OBO) flow to access resources for that user. Effective access is also constrained by delegated scopes, consent, Conditional Access, and tenant policies.
• Unattended / application-only access: No user is present. The agent acts under its own Agent Identity, and access is governed by that identity's RBAC assignments, Microsoft Graph application permissions, or policies in the target system.

These are not simply the “secure” and “insecure” options. They represent different business responsibilities. Reading “my email” should normally preserve the user's context. A background queue processor cannot pretend that a user remains continuously signed in.

Identity, Authorization, and Approval Are Not the Same Thing

Enterprise agent governance should be separated into at least five layers:

For example, granting an agent permission to create tickets proves only that the call falls within an authorization boundary. It does not prove that a particular bulk ticket operation matches the user's intent. Microsoft's least-privilege guidance therefore treats identity, scope, tool allowlists, approval, logging, and revocation testing as parts of the same governance model.

What Is the Minimum Governance Design You Need?

This decision tree offers a practical starting point:

Does the agent access external data or call a tool?
├─ No: Protect the entry point, data, and logs as you would for a regular AI application
└─ Yes
   ├─ Should it inherit the current user's permissions? Yes -> Design OBO / delegated access
   └─ Does it run in the background on behalf of the system? Yes -> Use an independent runtime identity and least privilege
       └─ Can it write, send, delete, or elevate privileges? Yes -> Add tool policy and approval

Whichever path you choose, a production agent needs a named owner, a permission inventory, defined log fields, and a way to disable it. Governance does not mean building a massive approval platform on day one. It means refusing to hide questions that must eventually be answered behind shared accounts and broad permissions.

Three Common Misconceptions

Misconception 1: Agent Identity removes the need for OBO. An agent can still act for a user in an interactive scenario. Agent Identity makes the agent itself identifiable; OBO preserves the user's delegated authorization context.

Misconception 2: Project Managed Identity and Agent Identity are the same thing. The former is the managed identity of the project; the latter represents an agent. Both may participate in authentication, but their purpose, scope, and lifecycle differ.

Misconception 3: Writing “ask the user before acting” in the system prompt completes the governance design. A prompt is not an enforceable authorization mechanism. Identity, RBAC, tool policy, and approval gates must be implemented outside the model.

Conclusion

To understand Foundry agent governance, remember one rule: Identity explains who is acting. Authorization limits the maximum authority. Approval decides whether this particular action should proceed. Observability and lifecycle controls make the action explainable afterward and allow access to be withdrawn.

Permission governance addresses two failures that point in opposite directions. Too little access produces a 403, and the system fails loudly. Too much access can produce data exposure, while the system remains silent. Troubleshooting addresses the first problem; identity governance must prevent the second.

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

Further Reading

• Agent identity concepts in Microsoft Foundry
• What are agent identities?
• Least privilege for AI agents
• Connect agents to MCP server endpoints