AI Agent Governance: Vijf pijlers die u bouwt, niet schrijft

Waar agent governance daadwerkelijk over gaat

Jane, een support engineer, typt één zin in een support copilot: prepare a refund summary for ticket #4521. De copilot geeft de opdracht door aan een planner agent, die een research agent (Zendesk-ticket, gekoppelde Jira-bug) en een billing agent (Stripe-betalingsrecord) aanroept. Één menselijk verzoek, zes machine-to-machine-aanroepen, waarvan de meeste zijn gedaan door software die zelfstandig besloot om nog meer software aan te roepen.

Die keten — gebruiker → applicatie → agent → sub-agent → MCP tool — is het agentic call path, en dat is wat agent governance moet controleren. Elk enterprise-toegangsmodel rust op drie aannames: een gebruiker staat aan het begin van het verzoek, het onderdeel dat de aanroep doet is die gebruiker, en de scope is datgene waar de gebruiker toestemming voor heeft gegeven. Bij de derde hop zijn alle drie de aannames onjuist, waardoor drie vragen geen antwoord meer hebben:

• Voor wie is deze aanroep bedoeld? De gebruiker is drie hops geleden geauthenticeerd. Is diens identiteit nog aanwezig in het verzoek, of is deze vervangen door een service account?
• Wie voert de aanroep uit? Een bearer token bewijst het bezit van een credential, niet welke van uw tweehonderd agents deze bezit.
• Wat mag het doen? Een token dat is uitgegeven voor de eerste aangeroepene heeft te veel rechten voor elke volgende aangeroepene in de keten.

Het beantwoorden van alle drie de vragen bij elke hop, onderbouwd met bewijs, is wat agentic AI governance inhoudt — vijf systemen, niet zomaar een paragraaf over verantwoord gebruik.

De agent is een derde type principal

De meeste teams grijpen naar een van deze twee shortcuts: laat de agent het token van de gebruiker doorsturen, of geef de agent een gedeeld service account. Beide aanpakken zijn onjuist, omdat een agent geen van beide is.

Het toewijzen van een eigen verifieerbare identiteit aan elke agent is de beslissing waar al het andere van afhangt. Het levert attributie op, omdat de ontvanger kan zien welke agent heeft aangeroepen; beleid per agent, omdat Jane's copilot die Jira leest en haar engineering agent die erin schrijft verschillende principals zijn, hoewel beide namens Jane handelen; en geen anonieme agents, omdat een tool die alleen bereikbaar is via een geregistreerde identiteit de registratie het handhavingspunt maakt.

De noodzaak is duidelijk: machine-identiteiten zijn in de meeste ondernemingen al met meer dan 40 op 1 in de meerderheid ten opzichte van menselijke gebruikers, en agents vermenigvuldigen zich sneller dan service accounts ooit deden — iedereen met een framework en een API-sleutel kan er een maken.

De vijf pijlers

Volledige governance bestaat uit vijf functionaliteiten in een continue cyclus. De eerste twee draaien voordat een agent één enkele aanroep maakt, de middelste twee bij elke aanroep, de laatste continu — en voeden weer terug in de tweede.

Pijler 4 is het punt waar governance in de praktijk wordt toegepast. Bij elke hop herleidt de gateway de aanroeper, controleert of deze agent dit doel mag aanroepen en namens deze gebruiker mag handelen, geeft een nieuw token uit dat exact is afgebakend voor de volgende aangeroepene, voert guardrails uit, en stuurt het verzoek vervolgens door en legt het vast. Drie eigenschappen ontstaan hierbij automatisch: attributie per hop, tokens op basis van least-privilege (een gelekt token is slechts geldig voor één aangeroepene en één scope) en centrale intrekking.

Waarom de gateway, en niet de IdP

Elke pijler zou in een andere tool kunnen ondergebracht worden. Wat het model bij elkaar houdt, is de handhaving via een gateway in het call path — het enige onderdeel dat elke hop ziet, ongeacht het framework of de cloud, identiteit doorgeeft, autorisatie bij elke stap inperkt en platformneutraal is. Entra beheert Entra-agents, Okta beheert Okta-apps, Bedrock beheert Bedrock-agents; de gateway beheert het pad over alle platforms heen, want dat is waar het risico zich bevindt — een punt dat we verder uitwerken in het beheren van AI-agents over meerdere platforms. Een identity provider zonder gateway geeft perfecte credentials uit die vervolgens onbeperkt worden doorgestuurd; een registry zonder gateway is slechts documentatie.

Waar teams de fout in gaan

De registry behandelen als een spreadsheet. Een registry die door agents kan worden genegeerd, inventariseert alleen de agents waarvan u al op de hoogte was. Het wordt pas effectief als het een verplicht controlepunt is: geen geregistreerde identiteit betekent geen aanroep.

Één krachtig token overal naartoe doorsturen. De snelste manier om aanroepen te laten slagen, maar ook de snelste weg naar een datalek. Agents kunnen via prompt-injection worden misleid om de credentials die ze bezitten te misbruiken. Deze mogen dus nooit breder zijn dan wat nodig is voor de volgende aanroep.

Accounts beoordelen in plaats van ketens. Drie agents in een inkoopproces — één maakt leveranciersrecords aan, één leest bankgegevens van leveranciers, één initieert betalingen — lijken afzonderlijk acceptabel. In een keten vormen ze echter een betalingspad dat geen enkele auditor zou hebben goedgekeurd: functiescheiding, opnieuw gecreëerd door software.

Aannemen dat de scope van een agent statisch is. Een finance agent die toegang krijgt tot een nieuwe ERP-module kan gegevens gaan verwerken die nooit binnen de oorspronkelijke scope vielen. Dit is geen fout, maar komt doordat aanpassen precies is wat agents doen. Gedrag moet continu worden vergeleken met de vastgelegde bevoegdheden, niet slechts eenmaal per kwartaal.

Wilt u dit als een werkend systeem in plaats van een diagram?

Registreer een agent, geef deze een identiteit en verleen toegang tot één MCP server.

Gratis aan de slag

Het lastige gedeelte: twee antwoorden op “wie heeft dit gedaan?”

Wanneer de research agent de Jira-issues van Jane leest, is het eerlijke antwoord op de vraag wie dit heeft gedaan zowel Jane als de research agent. Als u een van beide weglaat, verliest u essentiële informatie. Er zijn twee manieren om dit op te nemen in een token, en die keuze bepaalt of u überhaupt over een bruikbaar auditspoor beschikt.

Voor agents wilt u vrijwel altijd delegation gebruiken. Het gedelegeerde token behoudt de gebruiker als sub en vermeldt de actor in act; bij opeenvolgende aanroepen worden de claims genest, waarbij de buitenste claim de meest recente actor vertegenwoordigt:

Twee aanvullende claims verdelen de taak. may_act is de toegangscontrole vooraf — mag deze actor handelen namens dit subject — die wordt gecontroleerd voordat het token wordt uitgegeven. act legt vast wie daadwerkelijk heeft gehandeld. Autoriseer op basis van de huidige actor plus subject plus policy; bewaar de geneste keten voor forensisch onderzoek.

Het onderliggende mechanisme is token exchange. RFC 8693 definieert dit proces: bied een subject token aan en optioneel een actor token, en ontvang een nieuw token dat is afgebakend voor een specifieke doelgroep (target audience). Leveranciers noemen dit On-Behalf-Of (OBO). Eén eigenschap is belangrijk om te onthouden — een exchange breidt de autorisatie nooit uit. Het uitgegeven token verleent de doorsnede van wat de gebruiker mag doen, wat de agent mag doen en wat het doel accepteert. Zo wordt elke hop meer beperkt dan de vorige. Tussen verschillende trust domains neemt het ID-JAG-protocol van het IETF (Cross App Access bij Okta) het over, door een kortstondige authorization grant aan te maken bij uw IdP die door de authorization server van het doel zelf wordt ingewisseld.

Hoe dit werkt in TrueFoundry

TrueFoundry vertaalt de vijf pijlers naar concrete productfunctionaliteiten. Het is belangrijk om transparant te zijn over wat vandaag beschikbaar is, dus de beschikbaarheid wordt eerlijk aangegeven.

De registry

Elke agent krijgt een vermelding, ongeacht het platform waarop deze draait — Bedrock, Vertex, LangGraph, een aangepaste HTTP-dienst, een A2A agent, of een copilot in de SaaS van een derde partij. Er hoeft niets te worden verplaatst of herschreven.

Registratie verloopt via een wizard in vier stappen: Metadata, Agent Identity, Config, Access Control.

Identiteit

Stap twee bepaalt hoe de agent zijn identiteit bewijst. TrueFoundry-backed betekent dat TrueFoundry het token uitgeeft en ondertekent; dit is de standaardkeuze voor agents die u zelf beheert. Identity provider-backed betekent dat de agent een token aanbiedt van Okta, Entra, een willekeurige OIDC-provider, of een SPIFFE/SPIRE-endpoint, waarbij claimwaarden worden gekoppeld aan de agent.

De stap Config bepaalt of de Agent Gateway er voor staat. Proxy via Gateway betekent dat aanroepers een TrueFoundry-URL aanspreken en dat de gateway authenticeert, handhaaft en doorstuurt. Embedded betekent dat alleen governance wordt toegepast: een identiteit en machtigingen, zonder inkomende proxying. Dit is de manier om een copilot te beheren binnen een product van een derde partij — u kunt de toegang aan de voorkant niet beheren, maar de uitgaande aanroepen lopen nog steeds via uw gateways.

Agent access control

Toegangsbeheer werkt op basis van een allow-list; er is geen instelling voor weigeren, omdat de afwezigheid van een machtiging automatisch weigering betekent. Collaborators kunnen een gebruiker, een team of een andere agent zijn, met de rol Agent Manager (bekijken en bewerken) of Agent Access (aanroepen en namens gehandeld worden). Owner is een afzonderlijk optioneel veld dat een team moet zijn — het ankerpunt voor verantwoordelijkheid.

Let op wat deze enkele lijst doet: het definieert zowel wie de agent mag aanroepen als namens wie de agent mag handelen. Als u dit toewijst aan het ingebouwde everyone-team, krijgt de agent delegatierechten voor de gehele tenant — breder dan de meeste agents nodig hebben.

De andere richting werkt op identieke wijze: voeg de agent toe als collaborator op elke MCP server of elk model, met als subject agent:<name>, in dezelfde selectiemogelijkheid als voor gebruikers en teams.

Als u een agent wilt beperken tot een specifieke selectie van tools op een server, stelt u die selectie samen als een Virtual MCP Server en verleent u daar toegang toe; de mogelijkheid om tool-scoping per agent in te stellen binnen de machtiging wordt binnenkort verwacht.

Guardrails, bij elke hop

Toegangsbeheer bepaalt of een aanroep plaatsvindt. Guardrails bepalen wat de aanroep mag bevatten, ongeacht wie de aanroeper is. Agents verhogen het risico om één reden: een chatbot met een verkeerd antwoord is vervelend, een agent met een verkeerd antwoord voert het uit. Elk resultaat van een tool komt opnieuw terecht in de context van het model en kan een injection bevatten, waardoor invoer moet worden gecontroleerd, zelfs als de gebruiker wordt vertrouwd.

Een effectieve basis: PII-redactie en prompt-injection-detectie op LLM-invoer, detectie van geheimen op uitvoer, een SQL sanitizer en code-safety linter vóór de tool, en redactie na de tool. Start elke regel in de modus Audit en schaal daarna op — één geblokkeerde hop kan een gehele keten laten mislukken.

Audit

Doordat handhaving en observatie op dezelfde plek plaatsvinden, is het auditspoor van nature compleet. Elke trace legt vast welke agent de aanroep heeft uitgevoerd en namens welke gebruiker is gehandeld — beide delen van het vraagstuk met twee antwoorden.

Elke guardrail die is uitgevoerd verschijnt als een eigen span: wat is gecontroleerd, of de controle is geslaagd, en wat er is gevonden of afgeschermd. Geblokkeerde verzoeken worden eveneens gelogd — een geweigerde hop levert bewijs op en vormt geen gat in de verslaglegging.

Boven de afzonderlijke traces biedt één dashboard overzicht over elke geregistreerde agent, ongeacht waar deze draait: aantallen verzoeken, latency-percentielen, foutpercentages en gebruik in de tijd. Drift detectie en meldingen bij afwijkingen bouwen hierop voort en volgen binnenkort.

Een uitgewerkt voorbeeld

We richten de governance in voor de refund-summary copilot uit het begin van dit artikel.

Registreer de agents. Planner, research en billing krijgen elk een vermelding met een beschrijving en een Owner-team. De copilot van de leverancier wordt geregistreerd als Embedded — geen URL, alleen governance, maar de uitgaande aanroepen vallen nu onder het beheer.

Geef elke agent een identiteit. Gebruik TrueFoundry-backed voor de drie agents die u zelf beheert; de embedded copilot verwijst naar uw IdP, met gekoppelde claimwaarden.

Verleen minimale rechten (least privilege), in beide richtingen. Voeg op de research agent het supportteam toe met Agent Access — hiermee bepaalt u wie de agent mag aanroepen én namens wie de agent mag handelen. Voeg vervolgens agent:research-agent toe als collaborator op de Zendesk en Jira MCP-servers, en verder nergens anders. Billing krijgt toegang tot Stripe. Geen van beide heeft toegang tot de tools van de ander, omdat het ontbreken van een machtiging resulteert in een 403-foutmelding.

Geef de identiteit mee bij elke aanroep. Een gedelegeerde aanroep bevat twee bearer tokens: de gebruiker in Authorization, en de agent in x-tfy-agent-authorization. Elke agent voegt zijn eigen agent-header toe en stuur het token van de gebruiker door. Zo controleert de gateway elke hop op basis van de agent die de actie daadwerkelijk uitvoert.

Schakel guardrails in en monitor het gebruik. Koppel prompt-injection-detectie aan de modellen en redactie na de tool op de servers. Controleer vervolgens in Request Traces of bij een aanroep van de research-agent de research-agent als aanroeper staat vermeld en Jane als de gebruiker namens wie is gehandeld.

Een reële beperking op dit moment: momenteel wordt het token van de gebruiker doorgegeven naast de agent-header, in plaats van bij elke hop te worden omgeruild voor een nieuw token met een specifiek afgebakende doelgroep (audience). Volledige token exchange per hop wordt binnenkort ondersteund.

Klaar om een agent achter een echt handhavingspunt te plaatsen?

Registreer de agent, baken de scope af tot één MCP server en bekijk de trace.

Start gratis op TrueFoundry

Aandachtspunten uit de praktijk

Een agent kan geen OAuth2 authorization-code flow voltooien. Er is immers geen mens aanwezig om het toestemmingsscherm goed te keuren, en het token zou in dat geval alsnog aan die persoon toebehoren. Een dergelijke server geeft een melding dat MCP server authentication required is voor een agent-token, zelfs wanneer de agent als collaborator is ingesteld. Gebruik in plaats daarvan client credentials.

Output guardrails worden overgeslagen bij gestreamde responses. Deze hebben namelijk de volledige response nodig om een evaluatie uit te voeren. Kies daarom voor stream: false bij stappen van agents waarvan de uitvoer wordt gebruikt voor een tool-aanroep.

Het token van de agent is de agent zelf. Houd het token buiten versiebeheer (source control) en zorg dat het model dit op geen enkele manier kan uitlezen. Een agent die via een prompt kan worden misleid om de eigen token prijs te geven, kan worden geïmpersoneerd.

Gerelateerde artikelen

• Governing AI Agents Across Multiple Platforms — wanneer governance stopt bij de grens van het platform
• Graph Engineering for AI Agents — het evalueren van de node versus het beheren van de edges
• MCP Access Control with an MCP Gateway — permissies op tool- en serverniveau
• RBAC vs ABAC for AI Agents — het onderliggende toegangsmodel voor machtigingen
• Building an AI Governance Framework — het bredere beleidsmatige kader

Conclusie

Veel artikelen over enterprise AI agent management benaderen governance als een administratieve taak: definieer acceptabel gebruik, stel een commissie aan en publiceer de richtlijn. Geen van deze maatregelen houdt stand bij de derde hop van een call path. Daar draait het immers niet om de vraag of een actie passend was, maar of uw infrastructuur kan aantonen wie deze heeft uitgevoerd.

De vijf pijlers zijn waardevol omdat elke pijler verwijst naar een concreet systeem in plaats van een theoretisch principe. Ontdekking is een scanner. Registratie is een database die niet door de gateway kan worden omzeild. Authenticatie bestaat uit twee credentials in een verzoek. Autorisatie is een machtiging die bij afwezigheid een 403-foutmelding geeft. Audit is een trace waarin zowel de agent als de gebruiker zijn vastgelegd. Wanneer u deze systemen bouwt, kunt u de belangrijkste vraag — wie heeft dit gedaan, en namens wie — onderbouwen met een aanwijsbaar resultaat.

Beheer uw eerste agent op TrueFoundry

Gratis starten