Separate agent authority from user delegation

Learning objective

Explain agent identities, delegated permissions, and trust boundaries.

Core idea

For an architect designing agent access, the first question is who the downstream service authorizes. An agent’s name and instructions describe behavior; they do not establish a security principal. An authenticated user, a running agent, and a tool service can each have a different identity and different permissions.

Treat each transfer between them as a trust decision. Authentication establishes the caller; authorization decides which operation that caller can perform on which resource. A prompt saying “read only” cannot replace a role assignment, and a user’s request cannot grant access the user does not hold. This lesson establishes those distinctions; see 1.2.3 for Foundry identity lifecycle and role reassignment.

How it works

Identify the principal at the resource

Microsoft Foundry uses Microsoft Entra agent identities for governance and downstream tool authentication. An agent identity is a service principal representing the agent at runtime. An agent identity blueprint governs a class of identities and supplies the authentication foundation for creating and using them. The blueprint and the identity are related objects, not interchangeable assignees for every permission.

Foundry’s documented token exchange authenticates the blueprint, obtains a token for the agent identity, and requests an access token for the downstream service’s audience. The downstream resource validates that token and evaluates the identity’s permissions. The identifier agentIdentityId is the assignee when you grant Azure role-based access control (RBAC) permissions to the agent identity.

The audience identifies the intended resource. For Azure Storage, the documented audience is https://storage.azure.com. It is not necessarily the URL of an MCP server that mediates access to that storage. A correct role assignment with an incorrect audience still produces an authentication failure. Keep the transport endpoint, token audience, and resource scope separate in the design.

The project’s managed identity can authenticate the blueprint through a federated credential. That does not make the project managed identity the principal accessing the downstream resource in this chain. Assigning a storage role to the wrong identity cannot authorize the agent identity. Identify the actual caller before expanding permissions in response to an access failure.

Choose delegated or application authority

In the attended, delegated model, the agent operates on behalf of a human. Foundry’s identity documentation describes the OAuth 2.0 on-behalf-of (OBO) flow: the user authenticates, the application passes the user’s token to Agent Service, and the service exchanges it for a token carrying the agent identity and the user’s delegated permissions. Access is limited to resources the user has consented to and is authorized for.

In the unattended model, the agent operates under its own authority through the OAuth 2.0 client credentials flow. Its RBAC assignments, Microsoft Graph application permissions, or the target system’s authorization policy determine its access. There is no signed-in user whose resource permissions implicitly constrain this operation. Both paths reach the downstream resource, but only the delegated path carries the user’s delegated permissions there.

Choose the model from the business action. “Summarize my permitted records” requires preserving the user’s access context. “Process the organization’s scheduled reconciliation” can require application authority. A background process is not automatically entitled to every resource, and an attended interface does not prove that its tools use delegation. Verify the configured downstream authentication path.

For a remote-tool connection, Foundry documents three identity-based --auth-type values: user-entra-token authenticates as the caller, project-managed-identity as the project’s system-assigned managed identity, and agentic-identity as the agent’s per-project identity. Assign the corresponding principal the required RBAC role on the target resource before invoking the toolbox.

Foundry’s MCP documentation provides a concrete delegation configuration for a toolbox connection: --auth-type user-entra-token with --audience https://ai.azure.com passes the caller’s Entra identity to the toolbox. This is specific to that connection and audience. Do not copy it as the audience for an unrelated storage service, or infer that every MCP connection delegates user authority.

Locate each trust decision

Separate at least four decisions: admission to the application, invocation of the agent, invocation of the tool, and access to the tool’s target data. A successful decision at one point does not satisfy the others. A developer allowed to create an agent is not thereby authorized to read every document the agent can reach.

Azure RBAC role assignments combine a principal, a role, and a scope. The Foundry identity page illustrates Storage Blob Data Contributor for read/write blob access at storage-account scope. That example demonstrates the assignment mechanism; it does not make account-wide write access appropriate for a read-only assistant. Select the role and scope from required operations, rather than adopting the broad example unchanged.

Tool responses and retrieved content also cross a trust boundary. They supply data, not permission to change identity or execute a different operation. Enforce access in the downstream system and preserve the instruction-versus-evidence separation from 0.3. Logging a caller’s identity helps explain an action, but an audit record cannot substitute for a permission check before the action.

Key distinctions and trade-offs

These distinctions determine the access model:

Delegation aligns an attended task with user entitlement, but requires preserving the caller’s authenticated context through the integration. Application authority supports unattended work, but you must independently constrain the service principal’s access. Neither model makes model-generated requests trustworthy by themselves.

Architecture / decision scenario

A finance assistant supports two operations: answer an employee’s questions about permitted expense records and run a scheduled reconciliation over an approved shared dataset. The design assigns different authorization paths even if both operations use the same model.

For the employee request, the application authenticates the employee and selects an integration that preserves delegated authority. For a Foundry toolbox using caller identity, the connection uses user-entra-token and the documented toolbox audience. The tool’s target must still enforce record access. An employee typing another department’s identifier does not expand that entitlement.

For scheduled reconciliation, the remote-tool connection uses --auth-type agentic-identity to authenticate under the agent’s application authority. The team assigns the required target role to the actual agentIdentityId, at the intended resource scope. It checks the target audience independently of the tool’s HTTP URL. It does not reuse the employee’s token or infer access from the agent’s finance persona.

A returned document asks the assistant to upload the whole dataset elsewhere. The application treats that text as untrusted evidence; it does not switch identities or grant another tool permission. If a tool call fails, the investigation distinguishes an audience mismatch from missing resource authorization before changing role assignments.

Common exam traps

• Treating an agent’s persona or prompt restrictions as an authorization policy.
• Assigning downstream permissions to the project managed identity for an agentic-identity connection, or to the agent identity for a project-managed-identity connection.
• Assuming a signed-in user interface means every tool uses delegated access.
• Treating OBO as permission to exceed the user’s consented and authorized access.
• Confusing an MCP endpoint URL with the downstream token audience.
• Assuming access to the Foundry project grants access to every connected resource.

What to remember

Trace the principal, audience, permission model, and resource scope for each action. Delegated access acts for a user; application authority acts for the agent. Each downstream system enforces its own access decision, and neither an instruction nor retrieved text grants authority.

Knowledge check

References

• Microsoft, Agent identity concepts in Microsoft Foundry
• Microsoft, Connect agents to MCP server endpoints