Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-102.4 Implement multi-agent orchestration

Authenticate remote agents before delegating work

Completed by the knowledge check

Learning objective

Integrate independently deployed agents securely using A2A and/or MCP.

Core idea

An independently deployed agent owns its runtime, credentials, and release cycle. Integrating it requires a public interaction contract and an explicit trust decision. Its endpoint or capability description does not grant the caller permission to use it, and successful authentication does not make its returned content trustworthy.

Use Agent2Agent (A2A) when you delegate work to another agent through its agent-facing contract. Use Model Context Protocol (MCP) when you expose capabilities as tools that the calling agent invokes. Microsoft Foundry supports both, but its service limits and version choices are narrower than everything a protocol specification might permit.

See 0.9 for the protocol distinction and 1.1.8 for communication choices. This lesson connects the remote deployment, version, caller identity, exposed capabilities, and result validation into one secure integration.

How it works

Select the supported A2A contract

Foundry Agent Service documents the a2a tool type, represented by A2ATool or A2AToolboxTool, as generally available for A2A v1.0. The a2a_preview tool type remains preview for v0.3. In the Python outgoing-tool example, A2ATool(a2a_version=A2AProtocolVersion.V1_0, project_connection_id=...) explicitly selects v1.0 and binds the project connection.

Create a project connection for the remote endpoint rather than embedding secrets in instructions. For a Foundry target, its connection target is the A2A base path ending in /agents/{agent}/endpoint/protocols/a2a, with audience https://ai.azure.com. Do not substitute the agent-card discovery URL for this interaction endpoint.

A remote capability card supports discovery; it is not an access grant. For non-Foundry endpoints whose card requires authentication, Foundry’s outgoing-tool documentation provides send_credentials_for_agent_card=true. Verify the remote endpoint and its ownership before enabling that option. Foundry targets resolve their card through the connection and do not require that separate field.

Expose a Foundry agent deliberately

Incoming A2A requires the responses protocol. Prompt agents support it by default. Configure agent_card and agent_endpoint.protocol_configuration, including both responses and a2a, through the documented agent PATCH operation or SDK path. The card declares the agent’s skills; describe the actual contract rather than advertising unrestricted access to internal tools.

Apply the version selection and endpoint constraints in 0.9; if header and query version selectors conflict, Foundry returns HTTP 400 with version-ambiguous.

Bind permission to the actual caller

Every Foundry incoming A2A URL, including the card, requires Microsoft Entra ID authentication. Key-based and anonymous incoming access are unsupported. Assign the Foundry Agent Consumer role to the principal that presents the token, at the target agent scope for one endpoint or target project scope for all endpoints in that project.

Choose OAuth identity passthrough when remote actions must enforce per-user permissions. Agent Service generates a consent link; the user signs in and authorizes access. Managed OAuth uses an app registration managed by Microsoft or the endpoint publisher; custom OAuth uses your app registration and configured scopes. Users need Foundry Agent Consumer on the project or agent hosting the calling agent and, for a remote Foundry target, on that target project or agent too.

For service-to-service delegation to a Foundry target, the outgoing-tool page prescribes --auth-type agentic-identity with --audience https://ai.azure.com. The project-managed-identity option instead shares the project’s identity across agents. Assign the selected service principal the target endpoint role; its grant does not demonstrate an end user’s data access. Direct token acquisition uses https://ai.azure.com/.default.

The configuration roles are different from invocation permission. The incoming setup page requires Foundry User or higher to configure the target. The MCP setup page requires Foundry User to create and test agents and Foundry Project Manager when creating the authentication connection. These role names replace their Azure AI equivalents; the documentation states that role IDs and core permissions remain unchanged. Do not grant a configuration role merely to make endpoint calls succeed.

Expose a constrained MCP surface

A separately deployed agent can expose selected capabilities through an MCP server when the caller needs a tool contract. In Foundry, configure MCPTool with server_label, server_url, and project_connection_id for stored authentication. Select allowed_tools to restrict which remote capabilities the model can invoke.

Use require_approval="always" when a consequential call needs review; see 2.3.4 for the correlated MCP approval exchange and 2.4.6 for durable approval storage and resumption.

Authentication, allowlisting, and approval enforce different rules. The project connection supplies credentials; allowed_tools narrows model-visible capabilities; approval controls a proposed invocation. The remote service must still authorize the acting principal for the requested resource. Do not turn off its authorization because the calling agent uses an approved tool.

Foundry’s MCP page identifies its .NET SDK as preview; the A2A tool page also identifies its .NET model packages as prerelease despite the GA v1.0 service contract. Scope these package statuses to the SDK paths and test the documented interface for the language you deploy.

Validate what crosses the deployment boundary

Treat remote MCP descriptions, annotations, and results as untrusted input, as Microsoft’s guidance requires. The same application discipline should apply to delegated agent output: validate the expected result contract and preserve provenance before admitting it as evidence. A remote instruction to obtain another credential or call an unrelated service is not part of the caller’s authorized task.

Track endpoint owner, connection, selected version, permitted capabilities, and the data categories sent. Reassess the integration when the operator or tool behavior changes. Keep credential material out of prompts and logs, and record only the minimized identifiers and outcomes needed for auditing.

Key distinctions and trade-offs

A2A preserves the remote agent’s delegation contract; MCP presents callable tools under the caller’s execution loop. Both can connect independent deployments. Choose from the interaction you need, not from which acronym appears more agent-specific.

Project-scoped Foundry Agent Consumer access reduces assignment overhead but covers more targets. Agent-scoped access narrows reach. User delegation preserves per-user authorization requirements, whereas service identity represents the backend caller. Neither identity choice removes remote resource authorization.

A Foundry A2A target offers a supported v1.0 path but imposes JSON-RPC, text, and nonstreaming limits. Preview v0.3 is not an automatic compatibility fix for production. Evaluate another integration design if a required contract cannot fit the supported endpoint.

Architecture / decision scenario

A claims supervisor delegates document assessment to an independently deployed specialist and invokes a separate case-update capability. The specialist must honor each user’s permissions; case updates need approval.

If the assessment agent is a Foundry prompt agent, enable incoming A2A and publish an accurate card. Apply 0.9’s v1.0 compatibility checks. Configure the supervisor’s A2A connection with the target base path and OAuth identity passthrough, using managed OAuth when available or custom OAuth with the required scopes. Complete the consent flow and grant Foundry Agent Consumer to the represented user or group at both the supervisor’s and specialist’s agent scopes.

Expose case updates through the remote MCP server. Store authentication in its project connection, allowlist only the required update tool, and require approval. Review the exact case identifier and proposed changes before returning the correlated approval response. The case service checks the caller’s access itself.

Test unauthorized users, wrong protocol versions, unexpected tools, and injected instructions in results. Reject invalid outputs before the supervisor acts. An authenticated specialist can still return an unusable answer, and an approved update can still fail remote authorization.

Common exam traps

  • Defaulting to A2A v0.3 while describing the integration as generally available.
  • Assuming a public card or a discovered skill grants endpoint access.
  • Granting project-wide configuration roles when agent-scoped invocation access is sufficient.
  • Expecting Foundry incoming v1.0 to stream or transfer files.
  • Treating an MCP allowlist or approval as downstream authorization.

What to remember

Pin the supported contract, authenticate the actual caller, and scope endpoint permission. Use A2A for remote delegation and MCP for constrained tool invocation. Validate remote content and keep approval, connection credentials, and resource authorization as separate checks.

Knowledge check

References