Skip to lesson

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

Authorize every edge between agent services

Completed by the knowledge check

Learning objective

Prevent lateral agent access through scoped tokens, call-graph restrictions, and tenant authorization.

Core idea

For a multi-agent solution, an allowed collaboration path must also be an authorized service call. If a coordinator can invoke a retrieval specialist, that does not imply the retrieval specialist can invoke every other agent or read every tenant’s records. Lateral access appears when a caller reuses broad credentials, discovers unrestricted endpoints, or supplies tenant context that the receiver trusts without checking.

Build an authorization rule for each edge: who calls, which target accepts the token, which operation is permitted, and which tenant’s data is involved. A workflow controls intended execution. The receiving endpoint controls whether an attempted call is allowed, including calls made outside the intended workflow.

See 4.1.1 for assigning runtime identities and 4.1.2 for private reachability. This lesson turns those components into a restricted service-call graph. User-token exchange is covered in 4.1.4.

How it works

Scope tokens to the receiver

In Foundry’s agent identity chain, Agent Service exchanges the agent identity token for an access token targeting the downstream audience. The audience is the OAuth resource identifier, such as https://storage.azure.com for Storage. It is not necessarily the hostname of a tool server.

The Foundry audience https://ai.azure.com identifies the service, not one individual specialist; see 2.4.10 for A2A connection configuration. An audience restriction therefore cannot, by itself, separate two agents that accept that audience. Combine it with target-specific authorization.

For a custom web API, validate the token’s intended audience before authorizing work. Microsoft’s claims-validation page distinguishes v2.0 tokens, whose aud is the API’s client ID, from v1.0 tokens, whose audience is an application ID URI declared by the receiving API. Do not invent one universal string format for every Azure or custom API.

A token accepted by one receiver is not permission to reuse it everywhere. Nor does decoding a token prove that it is authentic. Use token-validation middleware or a gateway policy, then apply operation and data authorization to the validated principal.

Turn allowed edges into target grants

Represent the security graph as caller-to-target grants rather than a list of endpoints in a prompt. For Foundry agent endpoints, assign Foundry Agent Consumer to the calling principal at the target agent’s scope. Project scope grants endpoint access to every agent in that project, which is broader than one edge.

Use the principal represented by the token. For service-to-service A2A, that is the calling agent identity, service principal, or managed identity. For an OBO request, grant the end user or a group containing the user. The incoming A2A page directs you to use the Entra object (principal) ID, not the application’s client ID, for the role assignment. It identifies instance_identity as the unique identity for an agent in the agent object model.

See 2.4.10 for enabling incoming A2A; enabling the protocol or publishing an agent card grants no caller permission to execute an operation.

Enforce a custom API’s caller and operation rules

For an API fronted by Azure API Management, the validate-azure-ad-token inbound policy provides a concrete enforcement point. Configure tenant-id, acceptable audiences, and appropriate client-application-ids or required-claims. Its claim rules support match="all" or match="any"; separator lets a rule interpret a multivalue claim such as space-separated scopes.

Apply the policy at the API or operation scope when different receivers or operations have different caller rules. A policy that validates a tenant and audience without restricting the authorized subject or operation can still accept an unintended collaborator. For independent agent principals, evaluate their authorized principal identifiers; an application-ID allowlist alone is not proof of per-agent isolation.

These policy fields are building blocks for an application-specific call graph. They do not constitute a universal Foundry setting named “call-graph restriction.” The receiver’s authorization logic must map the validated caller and requested operation to the allowed edge. Keep the backend’s own authorization consistent with that rule, including any route that can bypass the gateway.

Bind authorization to the data tenant

Microsoft’s claims-validation guidance requires tid to match the tenant context in which application data is stored. It also requires an authorized subject and actor. Checking only tid and the presence of oid can inadvertently authorize service principals as well as users in the directory.

Use immutable tid and oid together for principal-related application data where appropriate. Validate delegated permissions through scp and relevant application permissions or roles through the applicable authorization rules. Claims such as email, preferred_username, and unique_name are unsuitable authorization keys.

A customer tenant identifier inside an agent message is input, not proof. If your application’s customer partition differs from an Entra directory tenant, maintain a server-side mapping from the validated principal to permitted customer partitions. That mapping is your application policy; do not pretend that tid alone expresses every business tenancy model. Apply it before retrieval or writes, rather than filtering an already disclosed answer.

Key distinctions and trade-offs

Audience versus target grant: The audience limits the receiving service. An agent-scoped consumer assignment narrows which Foundry agent endpoint the principal can invoke.

Workflow edge versus security edge: A workflow determines the planned next executor. Receiver-side authorization rejects calls from a caller that should not reach it.

Directory tenant versus customer partition: tid identifies the directory tenant. A separate application tenancy model needs an explicit authorization mapping.

Discovery versus execution: A readable agent card is a capability description. It does not replace token validation or an endpoint grant.

Architecture / decision scenario

A support coordinator calls a knowledge agent. A separate settlement agent can authorize financial adjustments. Both targets reside in one Foundry project, while the knowledge service also fronts a custom evidence API for several customers.

Grant the coordinator Foundry Agent Consumer at the knowledge agent scope, not project scope. Do not give the knowledge agent a settlement-agent grant. Enable incoming A2A on the knowledge target with its card and protocol configuration, and configure the coordinator’s connection with the Foundry audience. A stolen knowledge-agent credential must not become permission to invoke settlement merely because both endpoints share that audience.

At the evidence API, use validate-azure-ad-token to validate the accepted tenant, audience, and caller claims for the read operation. The backend resolves permitted customer partitions from validated principal context and rejects a request for another partition. It does not accept the coordinator’s claimed customer ID as sufficient authority.

Test the permitted coordinator-to-knowledge call, the forbidden knowledge-to-settlement call, a wrong-audience token, an unauthorized caller from the same directory, and an authorized caller requesting another customer’s data. Those cases exercise separate controls; one successful collaboration is not evidence that lateral access is prevented.

Common exam traps

  • Treating a service audience as a grant to exactly one Foundry agent.
  • Assigning consumer access at project scope for a single approved target.
  • Confusing an application client ID with the principal ID used for RBAC.
  • Treating agent-card discovery or a prompt prohibition as authorization.
  • Checking the directory tenant while ignoring subject, actor, and operation.
  • Trusting customer context supplied by another agent without server-side authorization.

What to remember

Authorize every caller-to-target edge at the receiving service. Combine audience validation with scoped target grants, operation checks, and trusted tenant-to-data mapping. Intended orchestration and valid authentication do not establish permission for every reachable agent or partition.

Knowledge check

References