Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-104.1 Design and implement security for multi-agent solutions

Assign each principal only required permissions

Completed by the knowledge check

Learning objective

Apply per-agent identities, managed identities, and least-privilege management/data-plane RBAC.

Core idea

For a production multi-agent system, decide which principal performs each operation before assigning a role. An agent that reads evidence, a deployment pipeline that changes infrastructure, and a person who invokes an endpoint need different permissions. Giving them one shared credential combines their authority and makes a compromised component more useful to an attacker.

Microsoft Foundry agent identities, Azure managed identities, and Azure role-based access control (RBAC) solve different parts of this problem. Identity establishes the actor. A role assignment establishes permitted actions at a resource scope. Neither an agent name nor a prompt instruction creates an authorization boundary.

See 0.12 for credential foundations and 1.2.3 for identity migration. This lesson focuses on designing the permission matrix across agents, infrastructure, and data.

How it works

Identify the runtime principal

A Foundry agent identity is a specialized Microsoft Entra service principal. An agent identity blueprint governs its creation and authentication. In the blueprint authentication chain, the project managed identity authenticates the blueprint through a federated credential; Entra issues an agent identity token, which Agent Service exchanges for a downstream audience-specific token. For this chain, downstream RBAC belongs to the agent identity, not automatically to the project managed identity.

Some tool connections instead select project managed identity authentication. In that configuration, the project identity is the downstream principal. Inspect the tool’s configured authentication rather than assuming every connection uses the same chain. A successful deployment does not establish which identity a tool uses when it runs.

Foundry documentation includes two identity lifecycles. The Agent Application model uses a shared project identity during development and a separate identity after publishing. The agent object model gives each created agent a unique identity from creation. The migration page distinguishes them through agent.identity: null identifies a legacy agent, while non-null identifies an agent with its own identity. It also documents instance_identity on the agent object. Do not apply the shared-development-identity rule to every agent. Reuse the migration checks in 1.2.3 rather than granting both possible identities broad access.

Choose a managed identity lifecycle

For Azure-hosted code that authenticates directly to a downstream service, a managed identity removes application-managed secrets. A system-assigned identity belongs to one Azure resource and is deleted with that resource. A user-assigned identity is a separate Azure resource, has an independent lifecycle, and can be assigned to multiple compute resources.

An independent lifecycle is useful when you replace compute without changing its authorized principal. Sharing a user-assigned identity across several agents, however, also shares its permissions. Treat that as an explicit trust decision. A user-assigned identity does not provide per-agent separation merely because every process has a different agent name.

Choose a separate principal when agents need different data or operations. Choose a shared principal only when the components intentionally belong to the same authorization domain. Keep the identity inventory tied to the tool connection and downstream resource so a reviewer can trace which actor holds each grant.

Separate the two permission planes

An Azure role assignment combines a security principal, a role definition, and a scope. Role definitions use Actions and NotActions for control-plane operations, and DataActions and NotDataActions for data-plane operations. The management plane changes resources; the data plane uses the service’s data or runtime API.

Azure Storage makes the distinction concrete. Storage Blob Data Reader grants blob read access. Storage Blob Data Contributor grants blob read, write, and delete access. Generic Azure Owner, Contributor, and Storage Account Contributor roles manage the account but do not grant blob data access through Entra authentication. A management role that includes Microsoft.Storage/storageAccounts/listKeys/action can nevertheless enable Shared Key access. Consider that alternative access path when evaluating effective authority.

For Foundry, Foundry Agent Consumer permits endpoint interaction without agent creation or modification. Foundry User is intended for building and testing agents. Foundry Account Owner covers resource management; Foundry Owner combines management with development capabilities. In the built-in role table, Foundry Account Owner has no project build-and-develop data actions, Foundry User and Foundry Owner have those data actions, and Foundry Agent Consumer has only endpoint interaction. Select the role for the operation, rather than treating every role containing “Owner” as interchangeable.

Make scope part of the grant

A blob reader that needs one container can receive Storage Blob Data Reader at container scope instead of storage-account, resource-group, or subscription scope. Higher-level assignments are inherited. Azure RBAC is additive: a narrow assignment does not remove a broader grant received elsewhere. Likewise, NotActions excludes operations from one role definition; it is not a deny that overrides another role’s grant.

Foundry also supports Foundry Agent Consumer at individual agent scope. That scope controls agent endpoint access, not broader management operations. The Foundry RBAC page directs you to Azure CLI for project- or agent-scoped consumer assignments because the portal’s consumer-role assignment surface supports account scope. Use az role assignment create with the intended principal and scope, then inspect assignments with az role assignment list. The agent resource scope follows this pattern:

/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.CognitiveServices/accounts/ACCOUNT_NAME/projects/PROJECT_NAME/agents/AGENT_NAME

Replace the uppercase placeholders with the target agent’s subscription, resource group, account, project, and agent names.

Key distinctions and trade-offs

Agent identity versus managed identity: A managed identity can authenticate a blueprint or be selected directly by a tool connection. The agent identity represents the independent agent. Grant the principal that reaches the target.

Management versus data: Permission to configure a resource is not permission to use its data through Entra authentication. Account-key retrieval can create another data-access route.

Identity reuse versus isolation: Reuse simplifies lifecycle management but combines permissions. Separate identities cost more administration and support smaller blast radii.

Narrow grant versus effective grant: A container-scoped role is insufficient evidence of least privilege if the same principal inherits broader roles. Review the full assignment set.

Architecture / decision scenario

An incident-analysis system contains a retrieval agent, a report-writing agent, and a deployment pipeline. Retrieval needs only the evidence container; report writing needs the output container; the pipeline manages infrastructure. End users only invoke the entry agent.

Use the agent object model’s distinct runtime identities for the two specialists. Grant retrieval Storage Blob Data Reader on the evidence container and report writing Storage Blob Data Contributor on the output container. The writer’s delete permission is part of that role, so confirm it matches the requirement before selecting it. Give users Foundry Agent Consumer on the entry agent through an agent-scoped CLI assignment.

The pipeline runs on supported Azure compute with a managed identity chosen for its lifecycle. For managing Foundry projects and models, assign Foundry Account Owner on the Foundry resource; this role carries no project build-and-develop data actions. Scope any other infrastructure permissions to the resources the pipeline deploys, separately from the specialists’ data permissions. Check that none of these principals inherits subscription-wide access or unnecessary account-key retrieval. If a tool connection uses the project managed identity, either deliberately authorize that shared principal or change the connection design; do not repair a failed call by granting every identity a broad role.

Common exam traps

  • Assigning downstream permissions to the project identity when the tool uses agent identity.
  • Treating unique agent names as unique security principals.
  • Applying the Agent Application publishing lifecycle to every agent object.
  • Assuming a management role grants blob data access through Entra authentication.
  • Expecting a narrow role or NotActions to cancel a broader assignment.
  • Granting consumer access at project scope when only one agent is intended.

What to remember

Trace each operation to its actual runtime principal. Separate management actions from data actions, choose identity lifecycles deliberately, and grant the smallest useful role at the narrowest useful scope. Review inherited permissions and alternate credential paths before calling the result least privilege.

Knowledge check

References