De manier waarop organisaties AI-agents inzetten verandert snel. Waar eerder vooral werd gekeken naar snelheid en productiviteitswinst, zien securityteams dat incidenten steeds vaker draaien om één vraag: wat kan een agent bereiken zodra die actief is? En nog belangrijker: merken we het op tijd?
In de praktijk schuurt dat met een klassiek probleem: governance komt vaak pas later, terwijl agents al eerder worden uitgerold. De kern van Zero Trust AI-agents is daarom helder: je kunt niet beschermen of handhaven op basis van regels als je niet eerst weet wat je moet beveiligen.
Waarom zichtbaarheid de basis is van Zero Trust AI-agents
Zero Trust-principes helpen bij het opzetten van AI-governance, maar dan wel in de juiste volgorde. Het uitgangspunt is simpel: je kunt alleen besturen wat je kunt zien. Dat betekent dat een organisatie eerst moet weten welke agents er bestaan, wie ze gebruikt (of beheert), en binnen welke grenzen ze opereren.
Veel organisaties springen tóch naar de volgende stap: policy enforcement en detectie. Maar als er geen inventaris is—geen eigenaar, geen scope en geen lijst van bekende agents—dan staat die enforcement “boven een leeg veld”. Je kunt dan wel blokkeren of waarschuwen, maar je mist het object waar je controle op zou moeten uitoefenen.
Uitdaging 1: AI-agents worden een nieuwe vorm van Shadow IT
Nieuwe technologie wordt meestal eerst in het werkproces opgenomen en daarna pas ingekaderd. Bij AI en agents gebeurt dat in een tempo waarin security teams vaak achter de feiten aanlopen. Het gevolg: agents duiken op in de organisatie zonder dat er een compleet overzicht is.
Wanneer agents “onzichtbaar” zijn voor governance, is dat niet alleen een compliance-probleem. Het maakt het ook eenvoudiger voor een aanvaller om een ingang te vinden zonder veel te hoeven doorbreken. Eenmaal binnen kan een agent toegang inzetten om gegevens te verzamelen of externe systemen aan te spreken.
De lessen uit cloud- en tooling-ervaring zijn relevant: waar je in cloud wel stuurt op gebruik, kosten en het verwijderen van ongebruikte resources, ontbreekt vergelijkbare discipline vaak voor agents. Daardoor blijft het risico bestaan dat er systemen draaien die niet in je controlesysteem terugkomen.
Hoe pak je dit aan (Act Blue)
- Behandel AI- en agentkosten als discovery-signalen, net zoals je dat doet bij cloud-uitgaven.
- Gebruik procurement en finance als extra zichtlijn. Niet elke agent wordt via IT aangeschaft, maar financiële sporen kunnen helpen bij het lokaliseren van “nieuwe” workflows.
- Publiceer een route naar goedgekeurde providers voordat je iets blokkeert. Zo voorkom je dat legitiem gebruik eerst stilvalt.
- Start met het principe “know first, then restrict”: pas daarna komt beperking in beeld.
Uitdaging 2: er is geen ‘single camera’ voor alle agenten
Zodra je discovery serieus neemt, blijft er een tweede probleem: agents leven in verschillende omgevingen. Ze kunnen draaien op endpoints, in browsers, binnen netwerkcommunicatie naar externe AI-diensten, en in SaaS-omgevingen. Daardoor geeft één bron van informatie nooit het volledige plaatje.
Daar komt bij dat veel communicatie met AI-aanbieders versleuteld is. Een netwerkobservatie ziet dan vaak alleen bestemming en datavolume: niet wat er inhoudelijk wordt opgevraagd, welke tool-call wordt gebruikt of of data wordt geëxfiltreerd.
Endpointtools zien weer makkelijker processen en runtime-gedrag, maar missen regelmatig wat in de browser gebeurt. En SaaS-gebaseerde AI kan op zijn beurt buiten beeld blijven voor zowel netwerk- als endpointzicht.
Hoe pak je dit aan (Act Blue)
Het antwoord is correlatie. In plaats van één “camera” moet je meerdere signalen samenbrengen die elk een deel van de inventaris en het gedrag zichtbaar maken.
- Combineer netwerkzicht met DNS/SNI-gegevens, JA4-achtige vingerafdrukken en egress-proxy logs om modelprovider-communicatie te herkennen.
- Vul dit aan met endpointtelemetrie over processen en het gebruik van API-sleutels in omgevingsvariabelen of lokale runtimes.
- Neem ook browsertelemetrie mee: extensies, copilots in de pagina en logs van de enterprise-browser.
- Correlatie werkt pas echt als je het verbindt met identiteit en SaaS-gegevens, zoals OAuth-grants en administratieve acties in provider- of platformconsoles.
Een belangrijk aandachtspunt: een centrale LLM-gateway (zoals een gateway die verkeer centraliseert en beleid kan toepassen) kan governance verbeteren, maar ontdekt niet automatisch agents die niet naar die gateway zijn gericht. Met andere woorden: zelfs een sterke enforcement-laag is gebonden aan je inventaris. Zonder zicht op alle agents blijft er blindheid bestaan.
Uitdaging 3: audits en monitoring moeten het tempo kunnen bijbenen
Veel organisaties doen audits met een vaste cyclus. Dat is begrijpelijk, maar ongeschikt voor een wereld waarin agents snel worden uitgerold, gekloond of tijdelijk ingezet. Als de inventaris die je audit gebruikt veroudert vóórdat de audit klaar is, meet je eigenlijk een verleden werkelijkheid.
Continu monitoren klinkt als oplossing, maar brengt een ander risico met zich mee: als geautomatiseerde systemen geautomatiseerde systemen bewaken, ontstaat de vraag wie er verantwoordelijk is voor wat er gebeurt.
Hoe pak je dit aan (Act Blue)
- Maak de zichtbaarheid niet afhankelijk van één mens of één systeem. Laat mensen agents observeren en laat agents elkaar ook onderlinge signalen geven, zodat je geen enkele failpoint krijgt.
- Zorg dat auditability een naam heeft: ook als tooling rapporteert, moet iemand verantwoordelijk blijven voor de uitkomst van monitoring en response.
- Gebruik kwaliteitspoorten (quality gates) om risico vroeg te beperken, in plaats van pas te reageren als schade al is ontstaan.
- Bekijk het idee van een noodstop (“kill switch”) kritisch: die werkt alleen als je precies weet wat je wilt uitschakelen. Daarvoor is inventaris weer de randvoorwaarde.
Daarnaast speelt agent-identiteit een centrale rol. Zonder toeschrijving (attributie) heb je geen betrouwbare basis om drempels en alerts zinvol in te stellen. Het model dat een agent “wel of niet” doet, moet je daarom koppelen aan de agent zelf, niet uitsluitend aan de gebruiker die de agent heeft gestart.
Concreet vraagt dat om een verschuiving in logging: niet alleen prompts vastleggen, maar ook tool calls en acties die de agent uitvoert. Pas dan kun je echt begrijpen welke handelingen plaatsvinden en waarom.
Van zichtbaarheid naar governance: waar je programma moet beginnen
Als je het geheel samenvat, komt Zero Trust AI-agents neer op één volgorde: eerst discovery en inventarisatie, daarna pas architectuur, enforcement, en detective/response. Elk probleem dat je bij de drie uitdagingen tegenkomt, leidt terug naar dezelfde oorzaak: je bouwt controles zonder te weten welke agents er bestaan.
Begin dus met het zichtbaar krijgen van agents en hun scope. Correlatie van meerdere signaalbronnen—netwerk, endpoint, browser, identiteit en SaaS—helpt je inventaris actueel te houden. Vervolgens bouw je continue monitoring rond agents die een eigen identiteit hebben, zodat thresholds en logging passen bij het echte gedrag.
Zo wordt de enforcement laag geen abstract beleid, maar een sturingsmechanisme dat werkt tegen een bekende populatie agents. En dat is precies het punt waarop Zero Trust voor AI-agents waarde toevoegt: niet door sneller te blokkeren, maar door beter te weten waar je op stuurt.
Gerelateerd lezen
- Compromitteerde GitHub Actions weer actief: wat nu?
- Focus: stateful SOC en AI in incidentafhandeling
- OpenAI-modellen en overheidswebsites: wat weten we
Conclusie: wil je securityteams grip krijgen op AI-agents, dan moet de aanpak starten met zichtbaarheid. Inventariseren, signalen combineren en monitoring continu maken—dat zijn de voorwaarden om daarna echt beleid, enforcement en detectie effectief te laten landen.
Bron: https://thehackernews.com/2026/09/zero-trust-for-ai-agents-starts-with.html
