Copilot Studio Agent ID en connectors: identiteit is geen gebruikersconsent

Een Copilot Studio Agent ID geeft de agent een eigen Microsoft Entra-identiteit, terwijl een connector de credentials van een maker of eindgebruiker kan gebruiken. Die instellingen beantwoorden verschillende vragen. De Agent ID maakt de agent zichtbaar en beheersbaar; connectorconfiguratie en runtimebeleid bepalen mede of een concrete actie kan slagen.

Deze uitleg is beperkt tot Microsoft Copilot Studio en Power Platform-connectors. Ze is gebaseerd op Microsoft Learn-documentatie die op 15 oktober 2026 is gecontroleerd. Er is geen tenantconfiguratie, connector of Conditional Access-beleid getest.

Wat doet een Copilot Studio Agent ID?

Een Entra Agent ID is de identiteit van de agent zelf. Microsoft beschrijft Agent IDs als service principals met het subtype Agent. Nieuwe Copilot Studio-agents krijgen die identiteit automatisch; oudere agents kunnen nog een traditionele app registration hebben. Het OAuth-gebaseerde authenticatiemodel blijft volgens Microsoft gelijk, terwijl Agent IDs extra zichtbaarheid en levenscyclusbeheer bieden.

Denk aan een agent als een service die via een kanaal met gebruikers en andere systemen praat. De Agent ID helpt Microsoft Entra herkennen welke agent aan die communicatie deelneemt. Dat maakt de agentidentiteit nog niet gelijk aan de persoon die met de agent chat en ook niet aan de verbinding waarmee een connector bij een achterliggend systeem aanmeldt.

Welke connector-scopes verschijnen in Entra?

Na publiceren voegt Copilot Studio API-permissies aan de Agent ID toe die de geconfigureerde Power Platform-connectors vertegenwoordigen. Microsoft zegt expliciet dat dit connector-scopes zijn, geen ruwe permissies zoals Microsoft Graph Mail.Read of Files.Read.All. De zichtbaarheid helpt beheerders begrijpen welke connectoren een agent kan gebruiken.

De scope hangt mede af van hoe de tool is toegevoegd. Een connector op agentniveau kan een bredere operatie-permissie tonen; wanneer je losse connectoracties toevoegt, kunnen specifiekere scopes verschijnen. Voor connectoren zonder fijnmazige scopes kan een generieke fallback gelden. Voeg of verwijder je connectoren of acties, dan worden de scopes bij de volgende publicatie bijgewerkt.

Er zijn twee belangrijke grenzen:

• De scopeweergave geldt voor Entra Agent IDs; legacy app registrations krijgen deze connector-scopes niet.
• Microsoft beschrijft deze scopekoppeling voor first-party en gecertificeerde Power Platform-connectors. Custom connectors, MCP-servers en REST API-tools voegen volgens de huidige documentatie geen API-permissies aan de Agent ID toe.

Een zichtbare scope is dus een nuttig inventarisatiesignaal. De scope is geen bewijs dat een willekeurige client rechtstreeks toegang heeft tot Microsoft Graph of dat een specifieke gebruiker toestemming heeft gegeven.

Wie meldt de connector aan?

De connector gebruikt een credentialconfiguratie. Dat is een andere laag dan de Agent ID. De actuele connector-how-to beschrijft dat een verbinding standaard gebruikerscredentials gebruikt; een maker kan voor ondersteunde scenario's ook maker-provided credentials instellen. De maker is dan de accountcontext van de verbinding, niet automatisch de persoon die de agent op dat moment gebruikt.

Een beleid dat makercredentials uitschakelt kan de toegang beperken tot wat de eindgebruiker zelf mag. Dat is vaak een betere grens voor een gedeelde agent die bedrijfsdata toont. Er zit wel een praktische consequentie aan: wanneer een tool een live aanmelding van een gebruiker nodig heeft, kan een scheduled of autonome uitvoering zonder actieve gebruiker mislukken. Microsoft noemt dit expliciet als risico van het beperken van makercredentials.

Omgekeerd maken makercredentials een achtergrondscenario niet vanzelf veilig. Als één makerverbinding meer mag dan iedere agentgebruiker nodig heeft, kan de gedeelde agent data of acties beschikbaar maken die een gebruiker niet zelf zou mogen gebruiken. Beoordeel daarom zowel de credentialkeuze als de rechten van de verbinding.

Waarom moet je connectorrechten per kanaal testen?

Teams is op dit moment de enige Copilot Studio-channel waarvoor Microsoft de runtime-enforcement van Conditional Access op de Agent ID-token voor deze connectorcalls beschrijft. In andere kanalen zijn scopes nog zichtbaar in Entra, maar lopen connectorcalls via de bestaande Power Platform-connector-authenticatie. Een Teams-test bewijst daarom niet hoe dezelfde agent zich gedraagt op een website, in SharePoint of bij een event trigger.

Ook de trigger is van belang. Een interactieve chat heeft mogelijk een gebruiker die kan inloggen of toestemming kan geven. Een geplande of autonome trigger heeft die gebruiker niet per definitie. Maak daarom een matrix met minstens deze dimensies:

Deze tabel is een testplan, geen claim dat de tests zijn uitgevoerd. Gebruik een niet-productieomgeving met synthetische records. Laat een test niet afhangen van echte klantdata of een brede makerverbinding.

Hoe controleer je de configuratie stap voor stap?

1. Leg de omgeving en agentversie vast. Noteer alleen de testomgeving, agentnaam of interne test-ID, publicatieversie en datum. Gebruik geen productie-identifiers in een publiek rapport.
2. Inventariseer connectoren en acties. Schrijf per tool op of de volledige connector of een beperkte actie is toegevoegd. Koppel elke actie aan een concreet gebruiksdoel.
3. Controleer credentials. Noteer maker- of eindgebruikerscredentials en lees het omgevingsbeleid voordat je de keuze verandert. Zo voorkom je dat één wijziging alle agents raakt.
4. Controleer Agent ID-scopes na publiceren. Bekijk in Entra welke connector-scopes zichtbaar zijn. Publiceer opnieuw na een connectorwijziging en controleer dat de scopeweergave die wijziging volgt.
5. Controleer data policies. Kijk of connector, kanaal, HTTP-tool of event trigger door Power Platform-beleid wordt geblokkeerd. Microsoft documenteert dat policies realtime kunnen worden afgedwongen en dat een overtreding in de makerervaring zichtbaar kan worden.
6. Voer positieve én negatieve tests uit. Test een toegestane read, een gebruiker zonder bronrecht, een geblokkeerde connector, een wijziging aan connectoracties en een background-trigger zonder interactieve gebruiker.
7. Herhaal per kanaal. Teams en een ander kanaal zijn afzonderlijke condities. Bewaar per run de verwachte en werkelijke uitkomst.
8. Leg veilige observability vast. Registreer agentversie, kanaal, trigger, connectoractie, credentialmodus, scopewijziging en foutcategorie. Log geen access tokens, geheime connection strings of onnodige promptinhoud.

Een praktische observabilityregel is dat iedere toolcall een correlatie-ID, connectoractie en beleidsuitkomst krijgt. Daarmee kun je een geweigerde call onderscheiden van een verkeerd gekozen actie. De gegevensstroom zelf hoort buiten een openbaar artikel of screenshot te blijven wanneer daarin tenant- of gebruikersinformatie zit.

Welke fouten komen vaak voor?

• Agent ID verwarren met gebruikersconsent. De ID vertelt welke agent betrokken is; controleer apart welke connectorverbinding en gebruikersrechten gelden.
• Scopes als universele autorisatie lezen. De Agent ID-scopes representeren Power Platform-connectors; de connectorruntime blijft beleid toepassen en de scopes zijn geen rechtstreekse Microsoft Graph-toegang.
• Een connectorniveau-tool te breed maken. Een hele connector kan een bredere set operaties zichtbaar maken dan één specifieke actie. Voeg alleen toe wat de taak nodig heeft.
• Eén kanaal als representatief behandelen. Conditional Access-runtimecontrole via Agent ID geldt volgens Microsoft op dit moment voor Teams. Test elk ander kanaal afzonderlijk.
• Makercredentials uitzetten zonder triggers te inventariseren. Een bestaande scheduled of autonome agent kan een interactieve gebruiker nodig krijgen en daardoor stoppen.
• MCP, custom connectors en REST API-tools in dezelfde scopecheck opnemen. Microsoft noemt die integraties als niet opgenomen in de beschreven Agent ID-connector-scopeweergave. Beoordeel hun eigen authenticatiepad apart.

Wanneer is deze aanpak geschikt?

Gebruik deze matrix wanneer een Copilot Studio-agent connectoren inzet voor bedrijfsdata of acties, zeker wanneer dezelfde agent via meerdere kanalen of triggers draait. Begin met beperkte read-acties, verifieer de Entra-scopeweergave en test de rechten van de werkelijke connectorverbinding.

Een bredere makerverbinding kan soms nodig zijn voor een goedgekeurde achtergrondtaak, maar vraagt om expliciete compensaties: beperkte tools, data policies, beperkte agentdeling en logging van iedere actie. Kies een andere integratie of een vaste workflow wanneer het platform de benodigde credential- of triggercombinatie niet veilig kan uitvoeren.

Voor algemene productiegrenzen kun je verder lezen over AI-agenten in productie en over AI-agenten testen met een minimale evalset. Voor een Azure-vraagstuk rond identity, connectoren en platformgrenzen vind je de passende route op Azure AI-engineering.

Samenvatting

Een Copilot Studio Agent ID maakt agentidentiteit zichtbaar en kan bij publicatie connector-scopes tonen. Behandel dat als één controle in een groter autorisatiepad. Leg daarnaast connectoractie, maker- of gebruikerscredential, data policy, kanaal en trigger vast. Test ook weigeringen en achtergrondscenario's. Zo voorkom je dat zichtbare identity-informatie wordt aangezien voor een volledige toestemmingstest.