Microsoft Copilot Studio-agents beheren: Identiteit, toegang en audit bij de gateway

Waarom Copilot Studio-agents een governance-probleem vormen

Met Copilot Studio kunnen zakelijke gebruikers agents bouwen zonder code te schrijven. Dat is het hele punt — en meteen ook het probleem. Er is niets aan te passen om een identiteitsheader toe te voegen, een tool te scopen of een auditregel te schrijven. Wanneer zo'n agent een MCP-server aanroept die echte data bevat, heb je identiteit, autorisatie en audit nodig die buiten de agent om werken. De enige plek waar dat kan plaatsvinden, is het pad dat de tool calls afleggen, en dat is waarom governance plaatsvindt bij de MCP gateway.

Twee identiteiten, twee taken

Microsoft en TrueFoundry bieden elk de helft van de oplossing:

• Entra Agent ID wordt automatisch aangemaakt door Copilot Studio en beheerd door Microsoft. Deze wordt gebruikt voor inventarisatie, sponsoring en Conditional Access — maar verschijnt niet in de tokens die naar de gateway worden verzonden.
• De TrueFoundry-agentidentiteit is een gespiegelde vermelding in de Agent Registry: een door een identiteitsprovider ondersteunde agent met een ingebedde configuratie (geen aanroepbare URL). De Subject hiervan is de applicatie-ID van de agent-client, die binnenkomt als de azp-claim.

Kort gezegd: Entra bepaalt wie de agent is; TrueFoundry bepaalt tot welke bronnen deze toegang heeft en namens wie. Je registreert de spiegeling op dezelfde manier als elke extern uitgegeven agent.

De drie modi

Hoeveel de gateway afhandelt — en of deze omzeild kan worden — hangt af van de modus die je kiest voor de connector en de MCP-server:

Bij passthrough is het token van de connector rechtstreeks geldig bij de MCP-server, waardoor alleen netwerkbeveiligingen de gateway in het pad houden. Bij on-behalf-of wijst de Resource URL van de connector naar agent-service; de MCP-server weigert die audience, waardoor de gateway altijd in het pad staat en de gebruiker behouden blijft. Bij client credentials voert de gateway een aanroep uit met alleen de app en de rol Tool.Invoke — de gebruiker vervalt bij de gateway, dus controles per gebruiker vinden alleen daar plaats.

Hoe de configuratie eruitziet

De volledige stroom is een Azure-en-Power-Platform-configuratie; op hoofdlijnen bestaat deze uit vier fasen:

1. Entra-app-registraties. Maak mcp-api (de audience van de MCP-server, die de scope Tool.Write en de app-rol Tool.Invoke blootlegt), agent-service (de audience waarnaar de gateway uitwisselt, met een geheim voor de gateway) en agent-client (de inloggegevens van de connector). Verleen beheerderstoestemming (admin consent); gebruik gedelegeerde machtigingen voor gebruikersstromen.
2. Custom connector (Power Apps). Importeer een Swagger 2.0-definitie met de gateway-host en het MCP-pad, stel x-ms-agentic-protocol in op mcp-streamable-1.0, en configureer OAuth 2.0 met Entra, agent-client en de Resource URL (agent-service voor OBO).
3. Copilot Studio. Stel orchestratie in op Generatief (klassieke orchestratie negeert MCP-tools stilzwijgend), voeg de connector toe als tool en maak een verbinding aan. Een korte toestemmingskaart betekent dat OBO actief is; een volledige inlogpagina betekent van niet.
4. TrueFoundry gateway. Registreer de MCP-server via zijn directe URL, stel Auth Data in (OAuth2 → Microsoft Entra, JWT Bearer grant, agent-service als client), voeg de toegestane audiences toe en voeg agent:<jouw-agent> toe als een MCP Server User.

De toewijzingen die er de toe doen, zijn de vertrouwde: welke servers een agent mag aanroepen (MCP Server User), namens welke gebruikers deze mag handelen (Agent Access) en wie deze beheert — het model in enterprise MCP access control.

Waar teams de mist in gaan

Orchestratie op klassiek laten staan. Bij klassieke orchestratie negeert Copilot Studio MCP-tools stilzwijgend — er verschijnen geen foutmeldingen, de tools worden gewoon nooit geactiveerd. Stel orchestratie eerst in op Generatief.

Passthrough naar productie sturen. De enige beveiliging van passthrough tegen omzeiling is je netwerkconfiguratie. Als het token van de connector rechtstreeks geldig is bij de MCP-server, kan een kwaadwillende die de server bereikt elke controle van de gateway omzeilen. Gebruik on-behalf-of voor alles wat voor productie bedoeld is.

Gebruikers koppelen op `sub`. In gedelegeerde modi is sub paarsgewijs per applicatie. Koppel gebruikers in plaats daarvan op oid, anders komen identiteiten tussen applicaties niet overeen.

De Entra Agent ID in het token verwachten. Deze reist niet mee met de aanroep; toeschrijving per hop bevindt zich in de audit-trail van de gateway, gekoppeld aan azp en de opgeloste identiteit.

No-code agents beheren die toegang hebben tot echte data?

TrueFoundry Gateway

Wat je MCP-server ontvangt

In gedelegeerde modi (passthrough / OBO) ontvangt de server een token waarbij aud is ingesteld op mcp-api, scp de waarde Tool.Write bevat, en een gebruiker is inbegrepen. In de modus client-credentials ontvangt deze een token met rollen waarin Tool.Invoke staat en geen gebruikersclaims. In beide gevallen heeft de gateway de agent en de gebruiker al opgelost, de policy toegepast en de auditregel weggeschreven — de server hoeft alleen te valideren en te leveren.

Handige valkuilen om te weten

• De Copilot Studio Entra Agent ID kan niet meereizen met de aanroep. Als je de eigen identiteit van de agent in het token nodig hebt, heb je een agent nodig die zijn eigen uitwisseling uitvoert (zoals Azure AI Foundry).
• `azp` wordt bij elke uitwisseling overschreven, dus toeschrijving over meerdere hops vindt plaats in de audit-trail van de gateway, niet in het downstream token.
• Gebruik gedelegeerde machtigingen, geen applicatiemachtigingen, voor gebruikersstromen — het door elkaar halen hiervan is een veelvoorkomende oorzaak van ontbrekende scopes.
• Stel `requestedAccessTokenVersion: 2` in op de registraties, anders zijn de azp- en issuer-waarden onjuist.
• Client credentials laat de gebruiker vervallen bij de gateway, dus elke controle per gebruiker moet daar plaatsvinden — de MCP-server ziet alleen een app-identiteit.

De drie Entra-app-registraties

De configuratie rust op maximaal drie Entra-app-registraties. Als je weet waar elke registratie voor dient, wordt het OAuth-proces begrijpelijk in plaats van magisch:

Token passthrough heeft alleen mcp-api en agent-client nodig (twee registraties); on-behalf-of en client credentials voegen agent-service toe (drie). Verleen beheerderstoestemming (admin consent) op elke registratie, en — het detail waar iedereen over struikelt — gebruik gedelegeerde machtigingen voor gebruikersstromen en applicatiemachtigingen alleen voor de app-rol bij client-credentials. Bij client credentials moet daarnaast de app-rol Tool.Invoke op mcp-api worden toegewezen aan agent-service als een applicatiemachtiging.

In de praktijk de modus kiezen

De drie modi zijn geen drie gelijkwaardige opties — ze vormen een beveiligingsspectrum, en de juiste standaardwaarde voor alles wat met echte data werkt, is on-behalf-of. Hier is de redenering die een reviewer moet toepassen. Token passthrough stuurt het token van de connector ongewijzigd door naar de MCP-server; omdat dat token rechtstreeks geldig is bij de server, is netwerkconfiguratie het enige dat de gateway in het pad houdt. Een kwaadwillende die de server kan bereiken, omzeilt dus elke controle. Dit is prima voor een sandbox, maar gevaarlijk in productie. On-behalf-of laat de Resource URL van de connector wijzen naar agent-service; de MCP-server weigert die audience, waardoor de gateway de tweede uitwisseling moet uitvoeren en niet overgeslagen kan worden, terwijl de gebruikersidentiteit behouden blijft in de claim oid. Client credentials laat de gebruiker vervallen bij de gateway en voert een aanroep uit met alleen de app en de rol Tool.Invoke — alleen geschikt voor echt onbeheerde automatisering. Hierbij worden alle autorisatiebeslissingen per gebruiker verplaatst naar de gateway, omdat de MCP-server nooit een gebruiker ziet. Als je niet kunt onderbouwen waarom een agent niet op on-behalf-of staat, zou deze dat wel moeten staan.

Gerelateerde artikelen

• Agent Identity and On-Behalf-Of Delegation — het onderliggende delegatiemodel
• What Is an MCP Gateway? — tool calls beheren
• Enterprise MCP Access Control — de toewijzingen achter elke aanroep
• MCP Authentication, Explained — inkomende identiteit en uitgaande inloggegevens
• AI Agent Governance — de vijf pijlers waar dit binnen past

Conclusie

Een no-code agent werkt nog steeds met echte systemen, en "no code" betekent dat er binnenin geen plek is om identiteit, autorisatie of audit toe te voegen. Copilot Studio draagt die taak over aan de gateway: de custom connector en de MCP gateway handelen de identiteit af via OAuth, Entra bepaalt wie de agent is, en TrueFoundry bepaalt tot welke bronnen deze toegang heeft en namens wie — waarbij beide bij elke aanroep worden vastgelegd.

Kies voor on-behalf-of, houd de gateway in het pad, en een black-box-agent verandert in een controleerbare agent.

Zorg dat elke Copilot Studio-tool call geïdentificeerd en gecontroleerd wordt.

Plan een demo