AI-agentconnectoren testen: identiteit en rechten per dienst

Je agent heeft net drie koppelingen gekregen. Hij leest een supportmail, zoekt een verwante GitHub-issue en zet een antwoord klaar in Slack. In het log staat dat de OAuth-toestemming is geslaagd. Toch weet je nog niet welke identiteit de agent bij elke dienst gebruikt, of een schrijfactie werkelijk wordt geweigerd en hoe je één verbinding stillegt.

Op 6 november 2026 kondigde OpenAI aan dat het met Hacktron hoog-prioritaire onderdelen van zijn systemen wil testen op interacties met externe diensten. De samenwerking noemt geen connectornamen, kwetsbaarheden of testresultaten. Dat maakt de uitvoerbare vraag voor jouw organisatie concreet: hoe bewijs je per dienst dat de juiste identiteit de juiste actie kan uitvoeren en een andere actie niet?

Een autorisatieproef per connector is een vaste reeks controles voor één verbinding met één externe dienst. Je legt vast wie de agent daar is, welke rechten de dienst verleent, welke acties moeten slagen en welke moeten worden geweigerd. Je test ook verlopen toegang, intrekking en het teruglezen van toegestane wijzigingen.

De vergelijking van tien AI-agent-authoplossingen die Mastra op 30 oktober 2026 bijwerkte, onderscheidt onder meer agentidentiteit, gedelegeerde toegang, toegang naar binnen en naar buiten, protocolsteun en waar beleid wordt afgedwongen. Mastra maakt daarbij expliciet dat een platform kan gaan over externe agents die jouw API of MCP-server aanroepen, of over jouw agent die toegang zoekt tot een externe dienst. Deze gids gaat over die tweede route: de uitgaande connectorproef. Mastra vergelijkt tien oplossingen langs de delen van het toegangspad die elk beheert.

Wat je nodig hebt

Een connectorproef heeft vier onderdelen: een aangewezen eigenaar, een testverbinding, een lijst met toegestane handelingen en een manier om na elke proef te zien wat er echt in de dienst gebeurde. Verzamel dit voordat je een token uitgeeft.

• De dienstaccounts en hun beheerders. Regel een ontwikkel- of testomgeving voor elke provider, bijvoorbeeld een apart Google Workspace-account, een Slack-testwerkruimte en een GitHub-testorganisatie. De beheerder van de dienst maakt of installeert de OAuth-app. De eigenaar van het proces bepaalt welke gegevens en handelingen nodig zijn.
• Een afgebakende opdracht. Schrijf op wat de agent voor de gebruiker moet doen. “Support opvolgen” is te vaag. “Berichten uit de supportmailbox lezen, een verwante GitHub-issue vinden en na menselijke goedkeuring een interne Slack-reactie plaatsen” is toetsbaar.
• Een verbindingenregister. Maak één record per combinatie van agent, dienst en account. Leg connection_id, eigenaar, externe account, authenticatiemodus, aangevraagde scopes, werkelijk verleende scopes, toegestane acties, toegestane doelobjecten, goedkeurder, vervaltijd en stoproute vast. Bewaar nooit het toegangstoken zelf in dit register.
• Een veilige plek voor geheimen. Gebruik de secret store die je organisatie al beheert. Geef de agent geen toegang tot de refresh-tokenopslag en zet tokens niet in een prompt, browserlog, foutmelding of trace. Een connectorlaag zoals Auth0 Token Vault kan ondersteunde externe OAuth-tokens per gekoppelde account bewaren en via een tokenuitwisseling beschikbaar maken; je moet nog steeds zelf de acties afbakenen.
• Een kleine uitvoerbare proefset. Neem minstens één actie op die hoort te werken, één schrijfactie die geweigerd moet worden, een verkeerd doel, een verlopen goedkeuring en een intrekking. Gebruik testrecords die je na de proef kunt verwijderen of herkennen.
• De mensen die beslissen. Benoem één technisch eigenaar voor tokens en logs, één applicatiebeheerder per dienst en één procesverantwoordelijke die de toegestane acties goedkeurt. Dezelfde persoon mag meerdere rollen hebben, maar de rol mag niet onduidelijk zijn.
• Een meetblad en een uitvoerbare cliënt. Een spreadsheet met test-ID, verwachte uitkomst, werkelijke status, doel-ID en read-back volstaat voor een eerste proef. Gebruik Postman of curl om een API-antwoord los van het taalmodel te controleren. Bewaar de ruwe tokenwaarden nergens in de resultaten.
• Tijd en geld. Voor drie bestaande diensten met een testomgeving is een eerste proef doorgaans 2 tot 4 ontwikkeldagen plus een halve dag van de proceseigenaar om handelingen, uitzonderingen en resultaten te beoordelen. Als rekenvoorbeeld kost dat € 2.000 tot € 3.600 bij een interne gemengde dagprijs van € 800. Dit is een planningssom, geen leveranciersprijs. Een nieuwe goedkeuringsinterface, ontbrekende API-functies of toegang tot echte productiegegevens vallen erbuiten.

Bij Gmail en Slack zijn de account en token niet uitwisselbaar: Google kan een gebruikerstoken uitgeven voor een mailbox, terwijl een Slack-bot met een eigen botidentiteit spreekt. Kies daarom voor elke regel in het register één dienst, één account en één manier van handelen. Gebruik je een browseragent, dan moet je ook de accountsessie afbakenen, want een agentbrowser kan jouw bestaande zakelijke sessie en logins erven.

Concrete stappen: autorisatie per dienst beproeven

De volgorde is bewust praktisch: eerst bepaal je wie handelt, dan welke bevoegdheid de provider verleent, daarna test je de acties en pas als laatste de stoproute. De agent geeft alleen voorstellen door; een gewone applicatielaag beslist of de API-aanroep mag vertrekken.

1. Maak per dienst één controleerbare verbinding

Maak eerst een inventaris van alle diensten die de agent kan aanroepen. Schrijf per dienst de concrete API-handelingen uit: users.messages.get, chat.postMessage, GET /repos/{owner}/{repo}/issues en POST /repos/{owner}/{repo}/issues. De productnaam van een connector vertelt je niet wat hij werkelijk kan doen.

Geef elke verbinding een eigen connection_id, bijvoorbeeld support-agent:google-mail:pilot of support-agent:github:pilot. Voeg de eigenaar, het externe account, de omgeving en de datum van de laatste toets toe. Als een workflow twee accounts bij dezelfde dienst gebruikt, zijn dat twee records met eigen credentials en eigen stopstatus.

Controleer: elke toolaanroep in de agentconfiguratie verwijst naar precies één verbinding en één actie uit een allowlist. Een generieke manage_slack-tool of access_github-tool is te grof. Klaar als je voor elke connector één positieve actie en één verboden actie kunt benoemen.

2. Kies of de agent namens iemand handelt

Gebruik gedelegeerde toegang wanneer de handeling afhankelijk is van de persoon die de agent start. Een agent die een medewerker zijn mailbox laat doorzoeken, moet de macht van die medewerker erven en stoppen wanneer die medewerker zijn verbinding intrekt. Gebruik een workload- of applicatie-identiteit wanneer de agent een vaste achtergrondtaak uitvoert die niet aan een individuele gebruiker is gebonden.

Leg in het register beide identiteiten vast: initiating_user en service_principal of connected_account. “De agent werkt namens support” is geen identiteit. Noteer het concrete dienstaccount of de concrete gebruiker die toestemming gaf. Vermijd gedeelde wachtwoorden en brede domeindelegatie als één aparte mailbox of installatie het werk kan doen.

Voor een webshop geldt dezelfde scheiding: een voorstel, menselijke vrijgave, write en teruglezen zijn afzonderlijke delen van de testketen. Voor menselijke goedkeuring geldt een andere laag; de goedkeuringspoort hoort bij de actie en diens impact, niet bij de agent als geheel.

Controleer: voer één toegestane leesactie uit met de gekozen gebruiker of workload en controleer dat het dienstlog diezelfde identiteit laat zien. Klaar als de aanvrager, agent en externe account afzonderlijk terug te vinden zijn.

3. Vertaal handelingen naar scopes en providerrechten

Vraag per dienst de kleinste set providerrechten die nodig is. Vergelijk de aangevraagde scopes niet alleen met de consentweergave, maar ook met de API-methode die je gaat aanroepen.

Voor Gmail geeft gmail.readonly toegang tot berichten en instellingen, gmail.send kan mail versturen en gmail.modify laat lezen, opstellen en verzenden toe. Google classificeert gmail.readonly en gmail.modify als restricted en gmail.send als sensitive; openbare apps moeten OAuth-verificatie voltooien, en servers die restricted data bewaren of doorsturen moeten een beveiligingsbeoordeling doorlopen. De scopepagina is bijgewerkt op 10 september 2026 en adviseert waar mogelijk niet-gevoelige scopes te kiezen. Een aparte supportmailbox verkleint het bereik, maar vervangt die voorwaarden niet. Gmail’s gmail.readonly beperkt toegang niet tot één bericht of label.

Slack onderscheidt bot scopes van user scopes. Een bot handelt als app-bot; een user scope laat de app handelen namens de gebruiker die hem installeerde. Voor berichten lezen kan een bot bijvoorbeeld channels:history nodig hebben; voor posten chat:write. De tweede scope is geen toestemming om iedere bedrijfsregel te negeren. Een GitHub App krijgt repository- en organisatierechten zoals Issues: read of Issues: write. In de REST API-versie 2026-03-10 vereist issue aanmaken Issues-repositoryrechten op write-niveau. Beperk de installatie tot de repositories waar de agent bij moet en vraag geen Contents: write als hij issues aanmaakt.

Controleer: lees de verleende scope- of permissielijst terug uit de providerconfiguratie en leg hem naast de actiematrix. Klaar als elke write een expliciete reden heeft en een write die niet in de matrix staat niet door het providerrecht alleen kan ontsnappen.

4. Richt de OAuth-toestemming veilig in

Voor een webapp gebruik je de authorization-codeflow met PKCE, een vooraf vastgelegde callback-URI en een eenmalige state-waarde. Sla de client_secret server-side op. Laat de browser of het taalmodel nooit een refresh token zien. Plaats access tokens niet in URL’s, prompts of toolresultaten.

De OAuth Security Best Current Practice is vastgelegd in RFC 9700. De standaard vereist exacte matching van redirect-URI’s en PKCE voor publieke clients, en raadt PKCE aan voor vertrouwelijke clients. Leg de redirect, gebruikte provider, gevraagde scopes en eigenaar van de OAuth-client vast in je verbindingenregister.

Bewaar access- en refresh-tokens versleuteld en haal ze pas op in de backend die de API-aanroep uitvoert. Een Auth0 Token Vault is één mogelijkheid wanneer je gebruikers aan ondersteunde Google-, GitHub- of Microsoft-accounts koppelt. Token Vault bewaart externe access- en refresh-tokens per verbonden account en geeft ze via een tokenuitwisseling terug. De applicatie blijft verantwoordelijk voor de beslissing of bijvoorbeeld chat.postMessage of issues.create voor deze actie is toegestaan.

Controleer: probeer de terugkeer van OAuth met een verkeerde state en een niet-geregistreerde callback. Beide moeten worden afgewezen voordat er een token wordt opgeslagen. Klaar als je testlog de account-ID en verleende scopes toont, maar geen tokenwaarde.

5. Behandel een remote MCP-server als aparte grens

Als een connector een remote MCP-server via HTTP gebruikt, test je eerst de toegang tot die MCP-server en daarna de toegang die hij tot de achterliggende dienst heeft. Het zijn twee verbindingen. Een geldig MCP-token geeft niet vanzelf recht op een Gmail-, GitHub- of Slack-write.

De huidige MCP-specificatie is versie 2026-07-28. Voor HTTP-transport werkt de client met OAuth-toestemming voor de beschermde MCP-server. Het token moet de MCP-server als beoogde resource hebben; de server moet controleren dat het token voor zijn eigen resource is uitgegeven en mag andere tokens niet accepteren of doorsturen. Scope-challenges kunnen aangeven welke extra rechten voor één bewerking nodig zijn. Een MCP-server moet controleren dat tokens alleen voor zijn eigen resource zijn uitgegeven.

Registreer dus zowel de MCP-verbinding als de achterliggende serviceverbinding. Leg per tool vast of de server alleen leest, een voorstel opslaat of een externe write uitvoert. Als de MCP-server een breed provider-token gebruikt, moet jouw policylaag de exacte actie en het doel alsnog controleren.

Controleer: stuur een MCP-token naar de API van de achterliggende provider en controleer dat die token daar wordt geweigerd. Stuur daarna een provider-token naar de MCP-server en controleer dat die daar ook niet wordt geaccepteerd. Klaar als ieder token alleen werkt bij de resource waarvoor het is uitgegeven.

6. Zet een policycontrole vóór elke write

De prompt is geen toegangsbeleid. Plaats een controle in de uitvoerende applicatielaag, tussen de toolaanroep en de API. Die laag controleert de identiteit, verbinding, actienaam, doel-ID, payload en goedkeuring. Als één veld ontbreekt of niet overeenkomt, stopt de write.

Maak de goedkeuring gebonden aan de exacte handeling: actor, dienst, tool, doelobject, genormaliseerde parameters, goedkeurder, tijdstip en vervaltijd. Een werkbare begininstelling is een goedkeuring die na 15 minuten vervalt. Elke wijziging aan doel of parameters maakt de goedkeuring ongeldig. Laat onbekende tools en onbekende doelen altijd weigeren. Sla dit besluit op als een afzonderlijk logrecord.

Ook bij remote MCP moet de uitvoerende service de gebruiker, actie en het doelrecord controleren.

Controleer: wijzig na goedkeuring één veld in de payload en probeer de write opnieuw. De uitvoerder moet vragen om een nieuwe goedkeuring. Klaar als dezelfde goedkeuring nooit voor een ander doel of gewijzigde inhoud kan worden hergebruikt.

7. Test eerst de toegestane writes en lees ze terug

Maak in elke testomgeving één wegwerpdoel aan. Geef alleen de testuitvoerder het providerrecht dat nodig is om daarop te schrijven. Laat de agent een voorstel maken, toon dat voorstel aan de aangewezen goedkeurder en laat de backend de API-aanroep uitvoeren.

Controleer de volledige uitkomst. Bij Slack vergelijk je de teruggegeven channel-ID, message timestamp en tekst. Bij GitHub controleer je de issue-ID, repository, titel en status. Bij Gmail kan de proef read-only blijven; je hoeft geen verzendrecht toe te kennen om te bewijzen dat lezen werkt. Als je de write-route voor mail later nodig hebt, test je die apart met een tweede verbinding en een mailbox die geen echte klanten kan bereiken.

Een 200- of 201-response is geen read-back. Lees het doel opnieuw op en vergelijk de opgeslagen toestand met de goedgekeurde payload. De Shopify-proef voor agentwrites gebruikt dezelfde combinatie van vrijgave en teruglezen. Houd een eigen request_id bij, zodat je dezelfde proef terugvindt in je policylog en providerlog.

Controleer: elke toegestane write heeft een provider-ID en een read-back met dezelfde doel-ID en relevante velden. Klaar als een verschil, ontbrekend record of onbekende response de status unknown oplevert en niet automatisch een nieuwe write start.

8. Probeer de weigering, vervaldatum en stoproute echt uit

Maak negatieve tests voor minstens vijf situaties: ontbrekende scope, verkeerde account, niet-toegestaan doel, verlopen goedkeuring en ingetrokken verbinding. Voeg een verzoek toe waarin instructietekst uit een supportbericht de agent vraagt om een niet-toegestane handeling. De agent mag die opdracht formuleren; de uitvoerende laag moet haar blokkeren.

OWASP beveelt gestructureerde agentbeveiligingstests vóór productie en na wijzigingen aan tools of beleid. De testmatrix noemt onder meer ongeautoriseerd toolgebruik, privilege-escalatie, datalekken en het omzeilen van goedkeuring. Een geweigerde API-aanroep telt pas als geslaagd wanneer je ook controleert dat de doeltoestand niet veranderde.

Test intrekking op twee niveaus. Zet de lokale verbinding eerst op disabled, zodat je uitvoerlaag onmiddellijk blokkeert. Trek daarna de toestemming of token in bij de provider. RFC 7009 beschrijft hoe een OAuth-client een access- of refresh-token bij de autorisatieserver kan intrekken. Verifieer met een nieuwe API-aanroep dat de verbinding niet meer werkt; vertrouw niet op een groen bericht in je eigen beheerscherm. Bij GitHub verlopen installatietokens na één uur en kan een token tot gekozen repositories en rechten worden beperkt, dus test bij die dienst ook dat een verlopen token geen write uitvoert en dat een nieuw token alleen de ingestelde rechten krijgt.

Controleer: 100 procent van de verboden writes wordt geweigerd, 100 procent van de toegestane writes is teruggelezen en er staat geen token in de logs. Klaar als intrekking één verbinding stopt zonder de andere diensten van de agent mee te trekken.

Valkuilen

Een scope aanzien voor een complete bedrijfsregel

Je ziet een geldige scope en denkt dat de actie daarmee veilig is. Een scope beschrijft wat de API in die categorie toestaat; hij kent niet je bedraggrens, klantstatus of goedkeuringsregel. Gmail gmail.readonly geeft toegang tot de berichten van het gekoppelde account. Slack chat:write zegt niet of de agent in jouw proces al akkoord heeft gekregen.

Houd de scope klein, gebruik zo nodig een aparte dienstaccount en controleer elk doel en elke parameter in je uitvoerlaag. De businessregel staat in jouw policy, niet in de naam van de OAuth-scope.

De mens en de agent als één identiteit loggen

Je ziet support@bedrijf.nl als actor en weet niet of een medewerker, een achtergrondagentaak of een bot de actie startte. Dat maakt incidentonderzoek en vertrek van een medewerker lastig. Leg de gebruiker, agent, externe account en credential-ID als afzonderlijke velden vast.

Leg per actie een herleidbare log en een noodstop vast, omdat je zonder actiegerichte agentlogs een incident moeilijk kunt reconstrueren. Neem in deze proef minstens de verbinding, tool, actor, doel-ID, besluit, providerstatus en read-backstatus op.

Een ingetrokken token lokaal blijven gebruiken

De beheerder verwijdert de OAuth-toestemming, maar een worker houdt een token in geheugen of cache. Nieuwe calls blijven dan mogelijk doorgaan, ook wanneer jouw dashboard al “verbinding verbroken” toont. Zet de lokale verbinding eerst op disabled, maak caches leeg en blokkeer de worker. Roep daarna de intrekkingsroute van de provider aan en controleer het resultaat met een nieuwe aanvraag.

Eén globale noodstop is onvoldoende als een verbinding per dienst kan worden uitgezet. Bewaar per connection_id een stopstatus die de uitvoering vóór tokenophaal controleert.

Alleen het succespad doorlopen

Een probe die één toegestane read uitvoert, zegt niets over een ontbrekende scope, ongeldige approval of verkeerd doel. Test minimaal één negatieve write per provider. Probeer de geweigerde actie ook buiten het model met hetzelfde credential, zodat je onderscheid ziet tussen providerweigering en weigering door je eigen policylaag.

Kijk bij GitHub naar de status en de vereiste permissie. Kijk bij Slack of de fout missing_scope, not_in_channel of een read-only beperking betekent. Een 403 is diagnose-informatie, geen reden om automatisch de macht te verbreden.

MCP-toegang als recht op alle achterliggende diensten behandelen

Een remote MCP-server kan een cliënt toelaten, maar de agent gebruikt daarna nog steeds providercredentials. Verwar dus de toegang tot de MCP-server niet met toegang tot de mailbox of repository. Test de audience van het MCP-token, de token van de provider en de policy van iedere tool apart.

De MCP-specificatie van 28 juli 2026 vereist dat een beschermde server alleen tokens accepteert die voor die server zijn bedoeld. Een MCP-server die een token voor een andere dienst doorstuurt, doorbreekt die grens.

Intrekking verwarren met het wissen van de gebruikerssessie

Een gebruiker kan zijn browseraccount sluiten zonder dat hij de OAuth-grant van de agent intrekt. Andersom kan hij de OAuth-grant intrekken terwijl je eigen applicatie nog een actieve verbinding toont. Bied daarom een stopknop per dienst, toon wie die verbinding heeft verleend en leg de providerstatus na intrekking vast.

Beslis-kader: wanneer koop je een verbindingslaag?

De goede route hangt af van twee vragen: moet de agent met een persoon meebewegen, en hoe groot is de schade van één toegestane write? Een connectorbroker helpt bij veel OAuth-verbindingen en tokenlevenscycli. Een policylaag helpt wanneer scopes de bedrijfsregels niet precies genoeg uitdrukken. Die functies vullen elkaar aan.

• Kant-en-klare workflow met bestaande connector past als de taak vaste stappen heeft en geen taalmodel hoeft te kiezen tussen acties. Denk aan een formulier dat altijd één record leest en daarna een interne notificatie verstuurt. Een no-code workflow kan dat snel verbinden. Voeg geen agent toe om een vaste regel uit te voeren.
• Provider-native OAuth per dienst past bij hooguit 2 diensten en 10 verbindingen, wanneer de agent vooral leest of interne concepten maakt. Je team beheert dan de consentflow, secrets, verversing en intrekking zelf. Deze route houdt het eenvoudig zolang gebruikers en scopes overzichtelijk blijven.
• Verbindingsbeheer met identity-platform past vanaf 3 diensten of meer dan 10 gebruikersverbindingen, als iedere gebruiker eigen toestemming verleent en je refresh, herautorisatie en accountintrekking centraal moet beheren. Auth0 Token Vault is een voorbeeld: de documentatie beschrijft externe verbonden accounts met eigen toegang- en verversingstokens. Controleer voor aanschaf welke provider, scope en lifecycle-handeling in jouw omgeving ondersteund zijn.
• Service-identiteit met eigen stoproute past bij een vaste achtergrondtaak zonder handelende eindgebruiker. Kies dan een identiteit die de doelservice tot één repository, mailbox of project kan beperken. GitHub Apps zijn hiervoor een concreet voorbeeld: installatiepermissies zijn aan een account en repositoryverzameling gebonden en de installatietokens verlopen na één uur.
• Eigen policylaag en release-worker past zodra een write geld, klantdata of externe communicatie raakt, een API-scope ruimer is dan je procesregel of een goedkeuring aan exacte parameters moet vastzitten. De policylaag controleert actor, doel en payload vóór elke write en houdt een aparte stoproute bij.
• Geen productie-write is de enige verstandige keuze als je nog geen eigenaar hebt die kan vrijgeven en herstellen, of als een verboden write in de test toch slaagt.

Gebruik 3 diensten of 10 gebruikersverbindingen als signaal om centraal verbindingsbeheer te beoordelen, niet als technische grens van Auth0 of een andere leverancier. De harde vrijgavegrens is strenger: alle verboden writes moeten worden geweigerd, alle toegestane writes moeten terug te lezen zijn en er mag geen token in je log staan. Eén onverwacht toegestane write blokkeert livegang. Een verwachte weigering die goed wordt teruggelezen is juist een geslaagde test.

Maatwerk wordt logisch wanneer de uitvoerlaag procesregels moet afdwingen die geen provider of connector kan uitdrukken.

Uitgewerkt voorbeeld: drie diensten voor supporttriage

Kade & Kompas is een fictief softwarebedrijf met een supportteam van 8 mensen. Het team verwerkt 40 supporttickets per week. De agent moet e-mails lezen, verwante GitHub-issues vinden en een interne Slack-reactie voorstellen. Hij mag tijdens de proef geen klantmail versturen. Schrijven kan alleen naar een afgeschermd Slack-kanaal of een testrepository en pas nadat iemand de exacte inhoud heeft goedgekeurd.

Het team richt 3 verbindingen in:

De proceseigenaar maakt 8 testgevallen per dienst, dus 24 in totaal. De Gmail-set bevat 4 leesacties die moeten slagen, 2 verboden writes, een poging buiten het gekoppelde account en een proef na intrekking. De Slack-set bevat 2 reads, 3 goedgekeurde posts, 2 verboden posts en een intrekking. De GitHub-set bevat 3 reads, 1 goedgekeurde issue, 2 verboden writes, een verlopen installatietoken en een ingetrokken installatie. Voor de GitHub-vervalproef wacht de test tot het token ouder is dan één uur.

De eerste ronde heeft 23 van de 24 verwachte uitkomsten. Eén toegestane Slack-post naar #support-agent-test mislukt met not_in_channel. De app heeft chat:write, maar een Slack-app kan niet posten in een privékanaal waarvan hij geen lid is. De beheerder nodigt de bot uit voor dat testkanaal en voert dezelfde proef opnieuw uit. Het team voegt geen chat:write.public toe, want die scope lost lidmaatschap van een privékanaal niet op. De Slack-documentatie beschrijft zowel de scope als de lidmaatschapseis en de fout not_in_channel; een geldig bericht hangt dus ook af van het exacte kanaal en de botlidmaatschap.

Na de correctie halen alle 24 testgevallen hun verwachte uitkomst. De app leest de vier testberichten, de vier toegestane writes in Slack en GitHub krijgen een ID en een terugleescontrole, en alle zes verboden writes veranderen geen doelrecord. De twee verboden GitHub-writes zijn de test zonder approval en de test naar een repository buiten de installatie. De herhaalde Slack-post is de enige gecorrigeerde proef; het totaal blijft 24.

Daarna draait het team twee weken in pilotmodus. Bij 40 tickets per week zijn dat 80 tickets. De agent leest en stelt voor, de goedkeurder ziet een vaste payload en pas daarna kan een interne Slack-post of testissue worden gemaakt. Gmail blijft read-only. De app logt per handeling de gebruiker, agent, verbinding, scopeversie, doel-ID, approval-ID, providerresponse en read-backstatus. De logs bevatten geen access- of refresh-token.

De pilot bevat geen nieuwe goedkeuringsinterface en geen klantmail-write. Als het team later externe mail wil versturen, krijgt dat een aparte verbinding, aparte testmatrix en eigen vrijgavebesluit.

De fout die deze proef vond was geen te brede OAuth-scope. Het was een app die geen lid was van het bedoelde kanaal. Dat verschil bepaalde de fix: één bot uitnodigen in een testkanaal was genoeg. Een algemene publieke schrijfscope had de fout verstopt en meer macht toegevoegd.

Vergelijkingstabel: vijf routes voor connectorautorisatie

De product- en protocolgegevens hieronder zijn gecontroleerd op 8 november 2026. Mastra’s vergelijking van tien AI-agent-authoplossingen is bijgewerkt op 30 oktober 2026. Dit zijn verschillende lagen: een OAuth-broker beheert verbonden accounts, een MCP-server beschermt een toolendpoint en een policylaag beslist of de bedrijfsactie mag doorgaan.

Een provider bepaalt de technische bovengrens van zijn scopes. Jouw policy bepaalt of deze concrete actie voor deze actor en dit doel mag doorgaan. Een consent-scherm is daarom geen vrijgavebewijs. Alleen geweigerde writes, teruggelezen toegestane writes en een werkende stoproute bewijzen dat de inrichting klopt.