Forum Discussion
Copilot Studio custom MCP connector: server-verifiable identity of the calling agent?
I am evaluating a Copilot Studio agent calling a custom MCP connector with delegated Entra authentication and client federation. The private pilot uses a synthetic catalogue. In my published PALO Framework, the governance model binds the admitted identity, time-bound mandate and exact proposed action before execution: https://paloframework.org/PALO_AIGovernance.html . The point I want to clarify is how far that identity binding can go for the originating Copilot agent.
I read the Microsoft guidance on agent identities: https://learn.microsoft.com/en-us/microsoft-copilot-studio/govern-agents-identities-overview . An Agent ID in the registry and a connector client identity are different evidence. In our documented pilot, the delegated token admission and the Copilot tool trace are checked separately; I do not treat the connector client ID alone as cryptographic proof of the originating agent.
For this custom-connector path, is there a supported claim or signed attestation that a remote MCP server can validate to bind each call to the specific Copilot Studio agent? I would appreciate the documented validation rules and whether the test pane and published channels differ. If this is not supported on this path, which supported isolation pattern would you use for separate agent mandates? This is a design question from an evaluation pilot, not a production capability claim.
1 Reply
You need the MCP server to authenticate the originating agent, beyond identifying the delegated user or connector client. Microsoft's current identity guidance explicitly excludes custom connectors, MCP servers and REST tools from the Agent ID connector-permission model. Its Teams-only runtime enforcement statement therefore does not establish agent attestation for your custom path.
The remote MCP deployment guide federates the connector's issuer and subject to a client app registration; it does not document a per-agent assertion delivered to your server. I cannot confirm a supported claim or test-pane versus published-channel attestation contract here.
For isolation, I would provision separate connector/client registrations and server authorization boundaries for each mandate, restricting who can reuse each connection. Validate signature, issuer and your API's audience, then enforce delegated permissions server-side. Treat that as connector isolation, not cryptographic proof of an agent. Request Microsoft's documented per-call attestation contract before making that stronger governance claim.
