MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-101.1 Design logical architecture for multi-agent solutions
Authorize tools for the acting principal
Completed by the knowledge check
Learning objective
Specify tool scopes, delegated permissions, and authentication boundaries.
Core idea
A tool definition tells a model what it can request. Authorization determines whether the acting principal can perform that request against the selected resource. You need both: a narrow tool catalog reduces the actions an agent can propose, while downstream permission checks stop unauthorized execution even when the model produces a plausible call.
For a multi-agent solution, specify three separate contracts: which tools each agent receives, whose authority each call uses, and which service accepts the resulting token. Delegating a task does not automatically delegate the user’s permissions or transfer the orchestrator’s credentials. See 1.1.3 for delegation ownership and 1.2.3 for agent identity lifecycle and role reassignment.
How it works
Restrict the exposed operation set
For a remote Model Context Protocol (MCP) tool in Microsoft Foundry Agent Service, server_label identifies the server to the agent, and server_url identifies its endpoint. The optional allowed_tools list restricts the tools that the agent can access. Omitting it exposes all tools in that MCP server. Specify the list when an agent needs only a subset, rather than relying on instructions such as “never delete records.”
An exposed read operation can still accept dangerous arguments. Define the resource selection rules in the tool implementation: permitted tenant, document collection, account, and operation. These are application checks, not implicit properties of allowed_tools. A catalog restriction to lookup_invoice does not by itself prevent looking up another tenant’s invoice.
Foundry’s project_connection_id selects the project connection that stores authentication and other connection details for the MCP server. Keep credentials in that connection rather than conversation text. Review the tool implementation and credential together: a narrowly named tool backed by a broadly privileged credential still needs downstream restrictions.
Choose attended or unattended access
Foundry documents two agent identity authentication scenarios. Attended access uses the OAuth 2.0 on-behalf-of (OBO) flow to act for a human user. Agent Service exchanges the user’s token for a token carrying the agent identity and the user’s delegated permissions. Access remains constrained by consent and the user’s authorization.
Unattended access uses the client credentials flow. The agent acts under its own authority, governed by its role-based access control (RBAC) assignments, Microsoft Graph application permissions, or the target’s authorization policy. No human user supplies the authority for that operation.
Choose the flow from the business requirement. A user’s request to inspect their own records usually calls for attended access. A scheduled reconciliation worker might require application-only access to an explicitly approved collection. Do not switch to a privileged unattended connection when attended access fails: that changes whose authority the operation uses.
The Microsoft identity platform’s OBO flow uses delegated scopes, not application roles. In a custom middle-tier API, the incoming token’s aud claim must identify that API. The API uses its credentials and the incoming token as an assertion to obtain a token for the downstream API, with a scope identifying the requested delegated permissions. It cannot redeem a token intended for a different application.
Consent is not a substitute for the resource’s permission checks. A user consenting to an application does not gain access to records they were never authorized to read. Likewise, adding a delegated scope does not make it an application permission suitable for an unattended job.
Match authentication to the target resource
Foundry’s runtime token exchange obtains an agent identity token and then a scoped access token for the downstream audience. For Azure Storage, the documented audience is https://storage.azure.com; for Microsoft Graph it is https://graph.microsoft.com. The audience is the downstream resource identifier, not automatically the MCP server’s URL.
The downstream service validates the token and checks the agent identity’s applicable permissions; see 1.2.3 for reassigning roles when the identity changes. Authentication answers which principal presented a valid token for this service; authorization answers which operations that principal can perform here.
Record each hop separately. The user-to-application token, application-to-Agent-Service authentication, and agent-to-tool token have different recipients and purposes. Do not relay a middle-tier access token to an unrelated service or expose it to the client as a reusable tool credential. Microsoft’s OBO documentation explicitly restricts access tokens to their intended audience.
Keep execution approval separate
MCP require_approval controls whether a proposed call needs approval; its default is always. Approval is a decision about executing the specific tool call, not a token exchange or permission grant. See 1.1.9 for the request and response mechanism and 1.1.6 for checkpoint placement.
Even an approved call must pass tool argument validation and resource authorization. Conversely, a valid token does not mean a human approved the proposed action. This separation lets you explain a denied operation accurately: missing permission, wrong audience, rejected proposal, and invalid arguments require different remedies.
Key distinctions and trade-offs
Catalog scope versus data scope: allowed_tools limits exposed operation names. The tool and downstream service enforce which records those operations can access.
Delegated access versus application-only access: OBO preserves the user’s authorization context. Client credentials use the agent’s authority. Application-only access suits unattended work but requires independently bounded permissions.
Authentication versus authorization versus approval: A token establishes a principal for a recipient; permissions constrain its access; approval permits a proposed action to proceed. None replaces the others.
Separate connections and identities add configuration work but make the acting authority explicit. A shared privileged connection is simpler to provision, yet makes a mistaken tool call more consequential and attribution harder. Choose isolation from the operations each agent actually needs, not from its persona name.
Architecture / decision scenario
A support orchestrator delegates invoice lookup to a read specialist and adjustment drafting to a billing specialist. Both use an MCP server, but their allowed_tools lists differ. Lookup receives only retrieval operations; billing receives a proposal operation. The tool implementation also validates the authenticated tenant and account before selecting records.
Interactive lookup uses attended OBO access, preserving the customer’s permitted record set. An overnight reconciliation agent uses application-only access to its approved data collection. The architecture records these as different authorities rather than treating every agent call as the signed-in customer.
The MCP service fronts Azure Storage, so its token exchange targets https://storage.azure.com, not the MCP hostname. If an adjustment proposal is approved, the executor still checks resource permissions and arguments. A wrong audience is repaired in connection configuration; a forbidden record is denied; a rejected proposal never executes. The orchestrator reports the actual result instead of replacing a denied user operation with its reconciliation credential.
Common exam traps
- Treating an instruction or
allowed_toolslist as record-level authorization. - Assuming delegated task ownership also transfers credentials.
- Using the MCP endpoint URL as every downstream token audience.
- Replacing failed OBO access with a broader application-only identity.
- Treating human approval as an RBAC assignment or user consent.
What to remember
Specify the operation set, acting authority, token recipient, and resource permission check for every tool hop. Use allowed_tools to narrow exposure, OBO for delegated user access, and independently constrained application-only access for unattended work. Approval authorizes a proposal to continue; it does not expand the principal’s permissions.
Knowledge check
An invoice specialist’s MCP allowed_tools contains only lookup_invoice, but calls can name an account in another tenant. Which boundary addresses that remaining risk?
allowed_tools narrows operation names, not the records those operations may access. The tool implementation and downstream service must validate resource selection and permissions; approval and descriptive wording do not grant or deny record-level access.An interactive assistant reads records through attended OBO access for the signed-in customer. The downstream service denies one record the customer is not authorized to read, although an overnight reconciliation agent’s application-only connection could read it. What should the assistant do?
An MCP service fronts Azure Storage. A proposed operation is approved, but its access token was requested for the MCP hostname. Which change addresses the authentication failure?
allowed_tools listhttps://storage.azure.com audiencehttps://graph.microsoft.com through the same connectionhttps://storage.azure.com . allowed_tools changes which operations are exposed, and approval permits a proposal to proceed, but neither repairs a token audience. Storage still checks the principal’s permissions once the audience is right.