MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-101.2 Specify technology components to include in a multi-agent solution
Rebind permissions when agent identity changes
Completed by the knowledge check
Learning objective
Distinguish shared project identity for unpublished Foundry agents from the dedicated identity of a published agent; plan publish-time RBAC reassignment, scoped access, and lateral-movement controls.
Core idea
Permissions belong to a principal, not to an agent’s instructions or recognizable name. When deployment or migration changes the principal that calls tools, verify and assign access for that principal. Successful development calls don’t prove production authorization.
The objective describes the Agent Application publishing model: unpublished agents share a project agent identity, and publishing creates a dedicated identity. Microsoft’s migration documentation also describes a revised agent object model in which an agent receives a unique identity at creation. Publishing in that model distributes the agent to Microsoft 365 and Teams; it doesn’t create the endpoint identity.
Teach both models, then identify which one your actual agent uses. Applying the publish-time rule universally can produce unnecessary or missing assignments. Ignoring it for an Agent Application can break every identity-authenticated downstream tool after publication.
How it works
Identify the principal and object model
An agent identity is a specialized Microsoft Entra service principal. Its agent identity blueprint governs creation and lifecycle. The downstream access token represents the agent and is requested for a target audience, such as https://storage.azure.com for Azure Storage.
In the Agent Application model, all unpublished agents within a Foundry project share the project agent identity and blueprint. Publishing provisions a dedicated identity and blueprint bound to the Agent Application resource. Tool calls using agent identity authentication switch to that dedicated identity.
Use the agentIdentityId from the relevant resource’s JSON view when assigning roles. The project JSON identifies the shared identity; the Agent Application JSON identifies the published application’s identity. Don’t copy the project value into a production permission template without checking which object is executing the call.
In the revised object model, newly created agents receive a unique identity and stable endpoint without a separate publishing step. The migration page distinguishes agents by agent.identity: null identifies an agent using the legacy shared model; non-null identifies the unique-identity model. Its REST inspection example exposes instance_identity, using api-version=2025-11-15-preview and Foundry-Features: AgentEndpoints=V1Preview. Treat that inspection interface as a preview surface rather than a universal version-independent contract.
For an agent that still uses the shared identity, the migration page documents creating another agent with the same definition to obtain a unique identity. It doesn’t document an available in-place identity upgrade. A migrated agent gets a different identity from both the project identity and any Agent Application identity, so downstream assignments must be made again.
Reassign the permissions that tools need
Azure role-based access control (RBAC) assignment binds a principal, role, and scope. For an MCP server that reads and writes blobs, the identity guidance shows Storage Blob Data Contributor at the storage account scope, assigned with az role assignment create.
For an MCP server that triggers a Logic App, the same guidance names Logic Apps Standard Operator at the Logic App resource. For an A2A tool that queries Cosmos DB, it names Cosmos DB Built-in Data Reader. That last role is a Cosmos DB data-plane role: assign it with az cosmosdb sql role assignment create, not the general Azure RBAC command.
These examples describe different permission systems. A role with a plausible name isn’t enough; use the assignment interface for the target service. Select permissions for the actual tool operations, and prefer resource or resource-group scope to subscription-wide access. A reader doesn’t need a writer’s authority merely because another agent in the development project writes data.
In the Agent Application model, repeat required downstream assignments for the published identity. They don’t transfer from the shared project identity. In the revised model, there is no publish-time identity change, but creation and migration still require assignments for the agent’s unique identity.
Configure authentication independently of authorization
For identity-authenticated MCP and A2A connections, the documented authentication value is AgenticIdentityToken. The connection categories are RemoteTool for MCP and RemoteA2A for A2A. The connection includes the downstream audience so Agent Service can request an appropriately scoped token.
The audience and role assignment solve different problems. A valid token for the wrong service audience doesn’t satisfy the target’s authentication contract. A correctly targeted token from a principal without the required role doesn’t satisfy authorization. Check both before changing application logic to recover from a denied call.
Don’t assume every tool uses agent identity authentication. The identity documentation scopes this capability to supported MCP and A2A integrations; other tools can use keys or OAuth identity passthrough. Inspect the specific tool’s mechanism before assigning an agent role that the tool never presents to the target.
Reduce lateral movement across the agent team
A shared project identity creates a shared blast radius. If a development agent can exercise that identity’s broad permission set, a narrow prompt doesn’t create an independent security boundary. Separate high-risk development workloads rather than giving the common principal every permission a future team member might need.
Dedicated identities enable separate role sets and auditing. Grant only required downstream resources and verify denial elsewhere. Identity creation and resource-scoped assignments establish complementary controls.
In the Entra admin center, Entra ID > Agent ID > All agent identities exposes Conditional Access, identity protection, network access controls, and governance of expiration, owners, and sponsors. Blueprints let administrators apply Conditional Access across an agent type or disable or revoke permissions for all agents of that type. These directory controls contain a compromised class of agents beyond one resource assignment.
For hosted agents, distinguish the per-agent runtime identity from the project managed identity. The hosted-agent documentation assigns infrastructure operations to the project identity and runtime model, tool, and resource access to the agent identity. Giving a project identity access to infrastructure doesn’t establish the runtime agent’s access to business data.
Delegated access is another boundary. Microsoft’s identity guidance distinguishes attended OAuth On-Behalf-Of access from unattended application-only authority. If an action must respect a user’s permissions, choose the documented delegated mechanism supported by that integration. An autonomous agent’s own role set doesn’t automatically inherit the restrictions of the person who asked a question.
Key distinctions and trade-offs
The identity change depends on the lifecycle model:
| Model | Before distribution | Permission boundary |
|---|---|---|
| Agent Application publishing | Shared project agent identity | Publishing creates a dedicated identity; reassign access |
| Revised agent object model | Unique identity from creation | Assign at creation; migration introduces another principal |
| Hosted agent runtime | Dedicated per-agent runtime identity at deployment | Distinguish it from the project’s infrastructure identity |
Shared identity simplifies experiments but broadens the permission union. azd assigns Foundry User to the shared project agent identity for unpublished agents; it leaves Container Registry, Application Insights, and custom resource permissions for you to configure.
Microsoft renamed Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager to Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager. Role IDs and core permissions remain unchanged.
Architecture / decision scenario
A development project contains a document reader and an automation agent. In the Agent Application model, they share identity during development. The automation agent’s Logic App permission therefore sits on the same principal as the reader’s storage access.
Publish each agent with a dedicated identity. Assign the reader only its required storage permissions; assign the automation identity the Logic Apps Standard Operator role on its target Logic App. Verify assignments with az role assignment list, then test required calls and denied access to unrelated resources. Use the Cosmos-specific assignment command if a specialist also needs the data-plane reader role.
If the deployment uses the revised agent model, assign these permissions to each unique identity at creation instead. If migrating the existing agents, recreate the definitions as documented and rebind access to the resulting principals. In either path, check the connection audience and AgenticIdentityToken configuration. If the automation blueprint is compromised, administrators can disable or revoke permissions for all its agents, containing the affected type while separate reader identities retain their scoped access.
Common exam traps
- Treating the shared-project rule as universal across both object models.
- Assuming published Agent Application roles transfer automatically.
- Assigning a Cosmos DB data-plane role with the Azure RBAC command.
- Confusing a project managed identity with a hosted agent runtime identity.
- Using instructions as a substitute for least-privilege resource assignments.
- Assuming agent-only access enforces the initiating user’s permissions.
What to remember
Determine the object model and active principal before assigning access. Rebind permissions whenever identity changes, using the target’s correct role system and narrow scope. Dedicated identity limits sharing only when its permissions, audiences, and delegated-access choices also preserve the intended boundary.
Knowledge check
A blob-reading tool succeeds during development but is denied after publication in the Agent Application model. Its audience and connection authentication are unchanged. What should the team check first?
An agent in the revised object model has a unique identity from creation. The team is preparing to distribute it to Microsoft 365. When should it assign the agent’s downstream roles?
A hosted specialist’s A2A tool queries Cosmos DB case records with agent identity authentication. The specialist needs Cosmos DB Built-in Data Reader on the account. Which assignment grants the access the tool uses?
az role assignment create for the agent identity on the Cosmos DB accountaz cosmosdb sql role assignment create for the agent identity on the Cosmos DB accountaz cosmosdb sql role assignment create for the project managed identity on the Cosmos DB accountaz role assignment create for the project managed identity on the Cosmos DB accountA hosted agent reads sensitive documents for a signed-in user. The read must respect that user’s permissions and avoid access to unrelated resources. Which design preserves those boundaries?