Wat is Zero-Trust-beveiliging voor AI-agents?

Zero trust is gebouwd voor een wereld van gebruikers, apparaten en diensten. Autonome AI-agents doorbreken de meeste van deze aannames. Een agent is geen mens achter een toetsenbord van wie u het gedrag kunt inschatten, en het is geen statische microservice met een vaste reeks calls. Het is een proces dat een doel krijgt, zelf beslist welke tools het aanroept en in welke volgorde, en handelt met bevoegdheden die zijn gedelegeerd door de gebruiker of het systeem dat het heeft gestart. Geef het een breed token voor de sessie en het zal elke scope van dat token gebruiken, in combinaties die niemand had voorzien, wanneer de redenering daartoe leidt.

Dat is het gat. De meeste agent-implementaties authenticeren de agent één keer, overhandigen een credential en vertrouwen vervolgens elke tool call die het gedurende de rest van de sessie maakt. De volgende actie van het model is slechts zo veilig als de redenering die erin resulteerde, en die redenering kan worden gestuurd door een prompt injection, een vergiftigd document of een toolresultaat dat de agent niet verwachtte. Staand vertrouwen plus onvoorspelbaar gedrag is precies de situatie waarvoor zero trust is ontworpen om te elimineren.

Dit artikel past zero-trust-principes concreet toe op agents: waarom het perimetermodel bij hen faalt, wat elke pijler betekent wanneer de actor een niet-menselijke agent is die tools aanroept, en hoe een gateway autorisatie per call, afgebakende toegang, egress-beheer en audit afdwingt bij elke afzonderlijke actie.

Wilt u autorisatie per call en een sterke identiteit voor elke AI-agent en tool call? Boek een demo.

Waarom agents het perimetermodel doorbreken

Het perimetermodel verleent vertrouwen op basis van locatie of een initiële authenticatie: zodra u zich binnen het netwerk bevindt, of zodra u bent ingelogd, wordt u vertrouwd voor wat volgt. Dit model stond al onder druk door werken op afstand en microservices. Agents doorbreken het volledig om drie redenen.

Ze handelen met gedelegeerde bevoegdheid. Een agent draait namens een gebruiker of een systeem en erft een deel van de rechten van die hoofdgebruiker. Als de delegatie grofmazig is, draagt de volledige reeks acties van de sessie de volledige bevoegdheid van de gebruiker, ongeacht of een specifieke actie die nodig had.

Ze roepen tools aan, wat betekent dat ze daadwerkelijke acties uitvoeren. Een agent beantwoordt niet alleen vragen. Het leest databases, verstuurt berichten, schrijft naar systemen, verplaatst geld, start workflows. Elke tool call is een actie met consequenties, en de agent beslist over elke actie dynamisch.

Ze koppelen acties aan elkaar op manieren die u vooraf niet kunt opsommen. De uitvoer van de ene tool wordt de invoer voor de volgende beslissing van de agent. Een leesactie kan leiden tot een schrijfactie; een zoekresultaat kan een instructie introduceren. U kunt de call-graph niet vooraf goedkeuren omdat de agent deze op runtime opbouwt, gedeeltelijk op basis van gegevens die het zojuist heeft ontvangen.

Voeg dat samen en een staand sessietoken is een geladen wapen. Als een geïnjecteerde instructie de agent overtuigt om delete_records of transfer_funds aan te roepen, zal een token op sessieniveau dat die rechten bevat de call doorlaten, omdat niets de specifieke actie opnieuw controleert tegen de specifieke context. Het probleem is niet dat de agent is geauthenticeerd; het is dat authenticatie werd behandeld als autorisatie voor alles wat volgde.

De zero-trust-pijlers, toegepast op agents

Zero trust wordt meestal samengevat in een paar principes: nooit vertrouwen, altijd verifiëren; least privilege; autorisatie per verzoek; ga uit van een inbreuk (assume breach); en audit alles. Dit is wat elk principe betekent wanneer de actor een agent is.

Nooit vertrouwen, altijd verifiëren. Vertrouw een agent niet omdat deze aan het begin van de sessie is geauthenticeerd of omdat deze binnen uw netwerk draait. Verifieer de identiteit en de bevoegdheid bij elk verzoek. De redenering van de agent is geen anker van vertrouwen; het kan worden gemanipuleerd door precies die gegevens die de agent verwerkt.

Least privilege. Verleen de agent alleen de rechten die een specifieke taak nodig heeft, en alleen voor zolang als nodig is. Een agent die facturen samenvat heeft leestoegang tot facturen nodig, geen schrijftoegang tot het betalingssysteem. Least privilege voor agents is afgebakend per actie, niet verleend voor de hele sessie.

Autorisatie per verzoek. Autoriseer elke tool call individueel, met de volledige context: welke agent, handelend voor welke gebruiker, roept welke tool aan, met welke argumenten, op dit exacte moment. Dit is de pijler die het meest direct een antwoord biedt op het probleem van gekoppelde acties, omdat elke schakel in de keten wordt geëvalueerd, niet alleen de eerste.

Ga uit van een inbreuk (assume breach). Ontwerp alsof de agent al gedeeltelijk is gecompromitteerd, omdat prompt injection dat een alledaagse situatie maakt, geen uitzondering. Als u ervan uitgaat dat de agent kan worden gestuurd naar een kwaadwillige call, stopt u met vertrouwen op de zelfregulering van de agent en verplaatst u de controle naar buiten de agent.

Audit alles. Elke actie die een agent onderneemt moet herleidbaar en gelogd zijn: voor wie het was, welke identiteit de call maakte, wat er werd verzocht en wat het beleid heeft besloten. Zonder dit kunt u een incident niet onderzoeken of naleving bewijzen, en kunt u achteraf geen legitieme actie onderscheiden van een gemanipuleerde actie.

Pijler één: sterke agent-identiteit

Alles wat volgt hangt af van het weten wie de actor is, en voor agents is dat moeilijker dan voor mensen. Een agent is een niet-menselijke identiteit. Het heeft een eigen credential nodig, geen API-key van een mens die voor het gemak is geleend, en geen gedeeld geheim dat in een image is ingebakken.

Goed uitgevoerd heeft een agent een afzonderlijke, verifieerbare identiteit, en weet het systeem ook namens welke mens of dienst deze handelt. Die dubbele identiteit, de agent plus de delegerende hoofdgebruiker, maakt autorisatie betekenisvol. Gevestigde mechanismen voor niet-menselijke identiteiten zijn hier van toepassing: workload identity frameworks zoals SPIFFE verstrekken kortstondige, verifieerbare identiteiten aan diensten, en OAuth 2.1-patronen regelen hoe gedelegeerde bevoegdheden worden gerepresenteerd en doorgegeven. De details over het vaststellen en doorgeven van die identiteit worden behandeld in AI agent identity en MCP authentication.

Het anti-patroon is de gedeelde, langdurige sleutel. Wanneer tien agents één API-key delen, kunt u een actie niet toeschrijven aan een specifieke agent, kunt u niet één agent intrekken zonder de andere te onderbreken, en kunt u rechten niet per agent afbakenen. Identiteit is de pijler die elke andere pijler handhaafbaar maakt, en komt daarom op de eerste plaats.

Bekijk hoe TrueFoundry least-privilege, afgebakende toegang voor agents afdwingt bij de gateway. Boek een demo.

Pijler twee: autorisatie per call, geen vast token

Dit is de kern van zero trust voor agents, en de meest radicale breuk met hoe de meeste systemen vandaag de dag werken.

Het gebruikelijke patroon verstrekt de agent bij de start van de sessie een token met alle rechten die het mogelijk nodig heeft, en vertrouwt vervolgens elke call die van dat token is voorzien. Zero trust vervangt dat door autorisatie bij elke call. Wanneer de agent een tool wil aanroepen, wordt het verzoek, voorzien van de identiteit van de agent én de delegerende gebruiker, geëvalueerd tegen het beleid voordat het wordt uitgevoerd. Het beleid kan rekening houden met de tool, de specifieke argumenten, de eigen rechten van de gebruiker en de context.

Concreet is "mag deze agent de database-tool aanroepen" de verkeerde vraag. De juiste vraag is "mag déze agent, handelend voor déze gebruiker, op dit moment déze specifieke query uitvoeren op déze tabel." Een leesactie van de eigen records van de gebruiker: toestaan. Een leesactie van de records van een andere gebruiker, of een DELETE: weigeren, ongeacht het feit dat de agent een database-tool in zijn catalogus heeft staan.

Dit is waar fijnmazige autorisatiemodellen essentieel zijn. Role-based access control (RBAC) biedt een basislijn, maar acties van agents vereisen vaak beslissingen op basis van attributen en taken die rekening houden met het specifieke verzoek. De afwegingen tussen deze modellen worden uitgelegd in RBAC vs ABAC en fine-grained authorization. Specifiek voor agents is het afbakenen van bevoegdheden tot de taak die de agent momenteel uitvoert, in plaats van een brede rol, het idee achter task-based access control: de agent krijgt de bevoegdheid voor de taak die voor hem ligt en niets meer.

Pijler drie: afgebakende en net-in-time tooltoegang

Least privilege wordt werkelijkheid via twee mechanismen: scope en tijd.

Scope beperkt wat een toewijzing omvat. In plaats van "toegang tot de CRM", is de toewijzing "leestoegang tot de contacten die deze gebruiker bezit." Hoe smaller de scope, hoe minder een agent kan doen als zijn redenering wordt gemanipuleerd, en hoe minder een aanvaller wint bij een enkele vergiftigde instructie.

Tijd beperkt hoe lang een toewijzing geldig is. Just-in-time toegang verstrekt een kortstondig credential voor de specifieke actie en laat dit verlopen, in plaats van een langdurig token aan te houden dat geldig, en steelbaar, blijft voor de hele sessie en daarna. Een credential dat één call en tien seconden overleeft, is veel minder nuttig voor een aanvaller dan een credential dat gedurende de hele sessie geldig is.

Samen beperken ze de impact van een inbreuk op beide assen. Een gecompromitteerde agent met een afgebakende, just-in-time toewijzing kan gedurende een kort tijdsbestek één specifieke actie uitvoeren. Dezelfde agent met een breed token voor de hele sessie kan alles doen wat dat token toestaat zolang de sessie duurt.

Pijler vier: egress-beheer

Agents maken verbinding naar buiten toe, met toolservers, API's en externe eindpunten. Dat uitgaande pad is een eigen controleoppervlak. Egress-beheer regelt waar een agent gegevens naartoe mag sturen en welke externe bestemmingen het kan bereiken.

Zonder dit beheer kan een gecompromitteerde agent data exfiltreren: een geïnjecteerde instructie draagt de agent op om de verzamelde context naar een eindpunkt van een aanvaller te sturen, en niets stopt die uitgaande call. Met egress-beheer kan de agent alleen goedgekeurde bestemmingen bereiken, en worden pogingen om andere bestemmingen te bereiken geblokkeerd en gelogd. In een MCP-context betekent dit ook het beheren van de toolservers waarmee een agent überhaupt verbinding mag maken, zodat deze niet kan worden omgeleid naar een vervalste of kwaadaardige server. Dit sluit rechtstreeks aan op enterprise MCP governance, waar het beheren en auditen van toolserver-toegang de kernfunctionaliteit is.

Pijler vijf: continue verificatie en audit

Zero trust is geen eenmalige controle; het is een continu proces. Elk verzoek wordt opnieuw geverifieerd en elke beslissing wordt vastgelegd.

De audit-trail voor agents moet voor elke actie antwoord geven op de vragen: welke agent heeft dit gedaan, voor welke gebruiker, welke tool en argumenten waren erbij betrokken, wat heeft het beleid besloten en wanneer. Dat dossier dient twee doelen. Voor beveiliging is het de manier om te onderzoeken of een actie legitiem was of het resultaat van een gemanipuleerde keten. Voor compliance is het het bewijs dat de toegang gecontroleerd en herleidbaar was. Omdat agents snel en in grote aantallen handelen, moet de audit automatisch en volledig zijn; steekproeven zullen precies die ene kritieke call missen.

Hoe een gateway zero trust afdwingt

De reden waarom een gateway het natuurlijke handhavingspunt is, is dezelfde reden waarom het werkt voor andere overkoepelende beheermechanismen: het is de enkele laag waar elke tool call van een agent doorheen gaat. Het afdwingen van zero trust in de code van elke afzonderlijke agent zou betekenen dat u elke agent vertrouwt om zichzelf te controleren, wat precies de aanname is die zero trust verwerpt. Door de handhaving te verplaatsen naar de gateway, bevindt de controle zich buiten de entiteit die mogelijk gecompromitteerd is.

Doorloop eens één tool call. De agent, voorzien van zijn eigen identiteit, vraagt om een tool aan te roepen. De gateway ontvangt de call met doorgifte van de identiteit van de agent én van de delegerende gebruiker. Het evalueert het beleid voor deze specifieke call: mag deze agent, voor deze gebruiker, deze tool gebruiken met deze argumenten. Zo ja, dan verstrekt het een afgebakende, kortstondige toewijzing, stuurt het de call door en controleert het de egress-bestemming. Zo nee, dan weigert het de call en retourneert het een gedefinieerde foutmelding. In beide gevallen wordt de beslissing vastgelegd in de audit-trail, gelabeld per gebruiker, team en model.

Dit is hoe de AI gateway and MCP gateway van TrueFoundry zijn gebouwd: identiteitsdoorgifte, fine-grained authorization bij elke tool call, beheerde tooltoegang en egress-beheer, en observatie per verzoek met een volledige audit-trail, allemaal afgedwongen op de laag waar het verkeer toch al doorheen stroomt. Omdat het datavlak in uw eigen omgeving kan draaien (SaaS, VPC, on-premise of air-gapped), blijven het handhavingspunt en de audit binnen uw eigen grenzen.

Waar teams de fout in gaan

De agent authenticeren en vervolgens de sessie vertrouwen. De meest voorkomende fout. Één login, een breed token, en elke opeenvolgende tool call wordt zonder meer goedgekeurd. Dit is staand vertrouwen, precies wat zero trust elimineert, en het betekent dat een prompt injection halverwege de sessie het volledige token erft.

Agents menselijke credentials geven. Het hergebruiken van de API-key van een mens, of een gedeelde sleutel van een dienst, voor een agent vernietigt herleidbaarheid en afbakening. U kunt niet vaststellen welke agent wat heeft gedaan, en u kunt één agent niet intrekken of beperken zonder de andere te beïnvloeden. Agents hebben hun eigen niet-menselijke identiteiten nodig.

Rolgebaseerde toegang (RBAC) als het volledige verhaal zien. Een grofmazige rol ("agents mogen de database gebruiken") autoriseert de tool, niet de actie. Zero trust vereist dat de beslissing rekening houdt met de specifieke call, de argumenten en de gebruiker voor wie deze bestemd is. Dat is waar autorisatie op basis van attributen en taken om de hoek komt kijken.

Handhaven in de eigen code van de agent. Als de beleidscontrole binnen de agent zelf zit, kan een gecompromitteerde agent eromheen redeneren. Uitgaan van een inbreuk betekent dat het handhavingspunt zich buiten de agent moet bevinden, op het call-pad, waar de agent er niet langs kan praten.

Geen egress-beheer. Teams beveiligen wat een agent kan lezen, maar vergeten waar het gegevens naartoe kan sturen. Exfiltratie vindt plaats op het uitgaande pad. Zonder egress-beheer staat er niets in de weg van de laatste stap van een gecompromitteerde agent: het naar buiten sturen van de data.

Conclusie

Zero trust voor AI-agents is één enkel idee dat consequent wordt toegepast: geen enkele actie wordt vertrouwd op basis van wie de actor is of omdat deze zich eerder heeft geauthenticeerd. Elke tool call wordt geverifieerd tegen een daadwerkelijke agent-identiteit en op zichzelf geautoriseerd, met de minimale rechten die de taak vereist, voor de kortst mogelijke tijd, en elke beslissing wordt vastgelegd. De pijlers zijn bekend; wat verandert is dat de actor autonoom handelt, daadwerkelijke acties uitvoert en kan worden gestuurd door de gegevens die het verwerkt.

Het praktische gevolg is architecturaal. Omdat u er van uit moet gaan dat de agent gecompromitteerd kan worden, hoort de handhaving buiten de agent te liggen, bij de gateway waar elke tool call doorheen stroomt. Daar wordt de identiteit doorgegeven, wordt elke call geautoriseerd met de volledige context, is de toegang afgebakend en kortstondig, wordt egress beheerd en is de audit-trail compleet. Als u het daar bouwt, blijft een gecompromitteerde agent beperkt tot één enkele, specifieke actie in plaats van alles wat een sessietoken toestaat.

Breng zero trust naar uw AI-agents. Boek een demo.