Governing Microsoft Copilot Studio Agents: Identity, Access, and Audit at the Gateway

Why Copilot Studio agents are a governance problem

Copilot Studio lets business users build agents with no code. That is the point — and the problem. There is nothing to modify to add an identity header, scope a tool, or write an audit line. When such an agent calls an MCP server holding real data, you need identity, authorization, and audit that live outside the agent. The only place that can sit is the path its tool calls take, which is why governance happens at the MCP gateway.

Two identities, two jobs

Microsoft and TrueFoundry each hold one half of the answer:

• Entra Agent ID is created automatically by Copilot Studio and managed by Microsoft. It is used for inventory, sponsorship, and Conditional Access — but it does not appear in the tokens sent to the gateway.
• The TrueFoundry agent identity is a mirror entry in the Agent Registry: an identity-provider-backed agent with an embedded config (no callable URL). Its Subject is the agent-client application ID, which arrives as the azp claim.

Put simply: Entra decides who the agent is; TrueFoundry decides what it may access and on whose behalf. You register the mirror the same way you register any externally-issued agent.

The three modes

How much the gateway brokers — and whether it can be bypassed — depends on the mode you pick for the connector and MCP server:

In passthrough, the connector's token is valid at the MCP server directly, so only network controls keep the gateway on the path. In on-behalf-of, the connector's Resource URL points at agent-service; the MCP server rejects that audience, so the gateway is always on the path and the user is preserved. In client credentials, the gateway makes an app-only call with the Tool.Invoke role — the user is dropped at the gateway, so per-user checks happen only there.

What the setup looks like

The full flow is an Azure-and-Power-Platform configuration; at a high level it is four stages:

1. Entra app registrations. Create mcp-api (the MCP server audience, exposing the Tool.Write scope and Tool.Invoke app role), agent-service (the audience the gateway exchanges into, with a secret for the gateway), and agent-client (the connector's credentials). Grant admin consent; use delegated permissions for user flows.
2. Custom connector (Power Apps). Import a Swagger 2.0 definition with the gateway host and the MCP path, set x-ms-agentic-protocol: mcp-streamable-1.0, and configure OAuth 2.0 with Entra, agent-client, and the Resource URL (agent-service for OBO).
3. Copilot Studio. Set orchestration to Generative (classic orchestration silently ignores MCP tools), add the connector as a tool, and create a connection. A short consent card means OBO is active; a full sign-in page means it is not.
4. TrueFoundry gateway. Register the MCP server by its direct URL, set Auth Data (OAuth2 → Microsoft Entra, JWT Bearer grant, agent-service as client), add the allowed audiences, and add agent:<your-agent> as an MCP Server User.

The grants that matter are the familiar ones: which servers an agent may call (MCP Server User), which users it may act for (Agent Access), and who administers it — the model in enterprise MCP access control.

Where teams get this wrong

Leaving orchestration on classic. Under classic orchestration, Copilot Studio silently ignores MCP tools — nothing errors, the tools just never fire. Set orchestration to Generative first.

Shipping passthrough to production. Passthrough's only bypass protection is your network configuration. If the connector's token is valid at the MCP server directly, an attacker who reaches the server skips every gateway control. Use on-behalf-of for anything real.

Keying users on `sub`. In delegated modes, sub is pairwise per application. Key users on oid instead, or identities won't line up across apps.

Expecting the Entra Agent ID in the token. It does not travel with the call; per-hop attribution lives in the gateway audit trail, keyed on azp and the resolved identity.

‍