De manier waarop we over AI-agenten praten is aan het veranderen, en de manier waarop we ze implementeren vereist een nog fundamentelere verandering. Terwijl het eerdere discours zich concentreerde op hoe snel organisaties agenten konden tegenhouden en hoeveel productiviteit ze konden beloven, heeft een reeks recente incidenten, waaronder een veelbesproken inbraak bij Hugging Face tijdens een evaluatie van OpenAI-agenten, organisaties ertoe aangezet om te onderzoeken of de snelheid de mogelijkheid heeft overtroffen om te beveiligen wat wordt ingezet. Beveiligingsteams vragen zich steeds vaker af wat een agent kan bereiken als deze eenmaal actief is, en of iemand het zou merken voordat het ertoe doet. Hoe verleidelijk het ook mag zijn om direct in te grijpen op handhavingscontroles en -detecties, u moet eerst kijken voordat u de stap zet.
Uit onderzoek van Veeam blijkt dat 70% van de organisaties toegeeft dat AI-workflows al in contact komen met gevoelige bedrijfsgegevens zonder dat er volledig toezicht op bestaat, en 67% meldt dat IT de autonome workflows die werknemers bouwen niet volledig kan volgen. Schaduw-AI is slechts een van de uitdagingen voor de zichtbaarheid van AI-agenten, maar het illustreert hoe snel en alomtegenwoordig deze fundamentele eerste stap aan uw greep kan ontglippen.
Zero Trust-principes kunnen een AI-governanceprogramma ondersteunen, maar alleen in de juiste volgorde. “Je kunt niet besturen wat je niet kunt zien” is het onderliggende principe bovenaan het SANS-spiekbriefje, Zero Trust for AI Agents: The Security Checklist. Het spiekbriefje plaatst inventarisatie vóór elke handhavingscontrole en beschouwt dit niet voor niets als een fundamentele voorwaarde. In de praktijk kunnen organisaties overgaan naar een beleidshandhavingspunt of een autorisatieschema voor een agent die geen benoemde eigenaar, geen gedefinieerd bereik en geen vermelding in een inventaris heeft. Die volgorde van werken is een diagnose van waar Zero Trust-programma’s kunnen mislukken. Een proxy- of autorisatielaag die voor een onbekende populatie agenten staat, heeft niets echts om tegen af te dwingen.
Hier zijn drie zichtbaarheidsuitdagingen waar u op moet letten, met implicaties waarmee u rekening moet houden als u ‘rood denkt’ als een aanvaller, en de oplossingen die u kunt gebruiken als u ‘blauw handelt’ als een geïnformeerde verdediger.
Uitdaging één: Agentgebruik is een nieuwe vorm van schaduw-IT
Bij elke nieuwe technologie volgt eerst de adoptie en volgt het bestuur later, als dat al het geval is. Zodra beveiligingsteams dit gat opmerken, is het eerste instinct vaak preventie, wat kan bestaan uit het blokkeren van niet-goedgekeurde tools, het afsnijden van de toegang of het afsluiten van alles wat onbekend is. Het budget en de aandacht stapelen zich eerst op voor deze processen, maar als je dingen blokkeert voordat iemand een beeld heeft van wat er al bestaat, riskeer je het legitieme gebruik ervan, samen met de schaduwimplementaties, stop te zetten. Hoewel het probleem van schaduw-IT al lange tijd wordt erkend en aangepakt in andere technologieën, zijn we nog steeds aan het kruipen als het gaat om het doen van dit voor AI.
Denk rood: Wanneer de agent feitelijk onzichtbaar voor je is, hoeft een aanvaller niet veel te doorbreken om voet aan de grond te krijgen. Een recent voorbeeld in het nieuws was een incident bij METR, de non-profitorganisatie die onlangs bekend stond om hun evaluatie van het Hugging Face-incident. Een aanvaller ontdekte de persoonlijke EC2-instantie van een werknemer waarop een vibe-gecodeerde agent-app draaide, omzeilde vervolgens triviaal de authenticatie en vroeg de agent om de API-sleutel van zijn modelprovider te overhandigen. Gedurende drie weken gebruikte de indringer het equivalent van $600.000 aan tokens, omdat er geen bestedingslimiet was voor de API-sleutel. Het interne dashboard van METR toonde eenvoudigweg helemaal geen gegevens over verzoeken met een beperkte snelheid, en het tokenvolume alleen was niet voldoende om enige waarschuwing op te wekken.
Akte Blauw: De cloudtechnologie heeft dezelfde groeipijnen doorgemaakt, en daar kunnen we de weg naar zichtbaarheid zoeken. Elk bedrijf heeft nu strengere controles rond de cloud, zoals het monitoren van het gebruik en de uitgaven van AWS/Azure, en het garanderen dat ongebruikte VM’s worden uitgeschakeld of vernietigd; maar niemand doet dit nog voor agenten. Beschouw AI- en agentuitgaven, samen met de uitgifte van API-sleutels, als ontdekkingssignalen. Financiën en inkoop zijn een ander gezichtspunt dat wellicht over het hoofd wordt gezien. Publiceer een pad met goedgekeurde providers voordat u iets blokkeert, zodat legitiem gebruik ergens heen kan, en als het om de werkingsvolgorde gaat, begin dan met het principe van ‘eerst weten, dan beperken’.
Uitdaging twee: Geen enkele camera kan het volledige beeld maken
Zelfs als een organisatie zich eenmaal tot ontdekking heeft verbonden, is er geen enkel gezichtspunt dat je de hele bevolking biedt. Agenten bevinden zich in het hele netwerk, op het eindpunt, in de browser en in SaaS die elders wordt gehost, en elke lens laat grote blinde vlekken achter.
Verkeer naar AI-providers is TLS-gecodeerd, zodat een inline-sensor een bestemming en het aantal bytes ziet, en geen prompt, een tool-oproep of een data-exfiltratie, die vaak naar exact dezelfde domeinen gaat als legitieme apps. Netwerkanalyse alleen kan dit niet onderscheiden van al het andere op de draad. Eindpunttools missen browser-embedded AI, en SaaS-embedded AI is voor beide onzichtbaar.
Denk rood: Stel je voor dat een marketinganalist een browsertool installeert die klantgegevens samenvat en uitgaande e-mail opstelt. Eindpunttools zien het nooit, omdat het in de browser draait. Netwerkmonitoring ziet alleen gecodeerd verkeer naar een domein dat ook een tiental goedgekeurde SaaS-producten host. De tool, en welke aanvaller deze ook kan compromitteren, kan toegang krijgen tot een CRM vol gevoelige gegevens zonder dat iemand anders zich realiseert dat de tool bestaat.
Akte Blauw: Het herstellen van de zichtbaarheid betekent dat u elke enkele bron moet opgeven en in plaats daarvan een verscheidenheid aan bronnen moet correleren die u elk een deel van de zichtbaarheid geven. Hoewel verkeer zich gemakkelijk kan camoufleren of verbergen in lokale MCP-servers of CLI-tools, kunnen metadata u vertellen dat er iets met een modelprovider praat, via DNS/SNI, JA4-vingerafdrukken en logbestanden voor uitgaande proxy’s. Vergroot de zichtbaarheid van uw netwerk met eindpunttelemetrie over processen, API-sleutels in omgevingsvariabelen of runtimes van lokale agenten. Zoek ook naar telemetrie op browserniveau, over extensies, in-page copilots en bedrijfsbrowserlogboeken, evenals identiteits- en SaaS-logboeken zoals OAuth-subsidies, uitgifte van API-sleutels en beheerdersconsoles van providers. Wanneer u al deze signalen met elkaar in verband brengt, kunnen zij u een inventarisatie geven.
Een LLM-gateway zoals LiteLLM kan zowel de zichtbaarheid als het bestuur centraliseren door op te treden als beleidshandhavingspunt waar het spiekbriefje om vraagt, maar het bestuurt alleen agenten die er al op zijn gericht, waardoor het probleem terugvloeit naar onze ontbrekende inventaris. Een gateway kan agenten controleren die u kent, maar ontdekt niet degenen die u niet kent.
Uitdaging drie: Audits moeten gelijke tred houden met wat u controleert
Traditionele audits en monitoring zijn onvoldoende om de zichtbaarheid te behouden. Bij een jaarlijkse beoordeling kunnen alleen de activa worden gezien die een jaar geleden zijn waargenomen, wat u vrijwel niets vertelt. Wanneer het seconden duurt voordat agenten worden ingezet en gekloond, is de geproduceerde inventaris tegen de tijd dat een beoordelingscyclus wordt gesloten al onnauwkeurig. Continue monitoring is het meest voor de hand liggende antwoord, maar het verwijderen van een mens uit die kring brengt zijn eigen risico met zich mee
Denk rood: Als een organisatie periodiek een audit uitvoert, kan een aanvaller hiervan profiteren door een gecompromitteerde agent te vertellen kortstondige klonen te spawnen om een taak te voltooien, waarbij elke kloon de toegang van de ouder overneemt voordat deze wordt beëindigd. De klonen bestaan net lang genoeg om gegevens te exfiltreren of andere kwaadaardige activiteiten uit te voeren, maar ze zijn verdwenen voordat de reguliere controle ze ooit zou zien.
Akte Blauw: Hier werken verschillende veranderingen samen. U kunt mensen agenten laten observeren en agenten elkaar laten observeren, zodat uw zichtbaarheid niet berust op één enkel falend punt. Houd er echter rekening mee dat als geautomatiseerde systemen geautomatiseerde systemen in de gaten houden, wie dan verantwoordelijk is? Voor de controleerbaarheid is nog steeds een persoon met naam nodig die verantwoordelijk is voor het resultaat, ongeacht wat de automatisering rapporteert. Met kwaliteitspoorten kunt u vooraf een bepaald risico beperken.
De recente druk van de Amerikaanse wetgever om een noodstop in te stellen laat zien dat het idee van een ‘kill switch’ voor autonome AI ook serieus wordt genomen. Maar onthoud onze voorwaarde hier: Kill-switches hebben alleen betekenis als je weet wat je moet uitschakelen, wat ons eerst weer bij de zichtbaarheid brengt.
Agentidentiteit maakt deel uit van deze vereiste en maakt uw bewakingsdrempels betekenisvol. Om het spiekbriefje nogmaals te herhalen: je kunt niet bepalen wat je niet kunt toeschrijven. Douglas McKee en ik hebben een aantal concepten naar voren gebracht die nuttig kunnen zijn in The Monday Brief on Substack: “Toegang tot agenttools moet worden gemodelleerd als een afzonderlijk identiteits- en beleidshandhavingsprobleem, niet als een verlengstuk van de gebruiker die de agent heeft ingezet. Geef elke agent zijn eigen identiteit, koppel machtigingen aan de actieve taak, beperk welke gegevens de omgeving mogen verlaten en plaats een autorisatielaag tussen het model en de verbonden services.” Bij het loggen is dezelfde verschuiving nodig: van het loggen van alleen aanwijzingen naar het registreren van de tooloproepen en acties die een agent onderneemt.
Waar dit uw programma plaatst
Waar zichtbaarheid verschijnt in de volgorde van uw activiteiten, vormt de basis voor elke andere bestuursstap die u moet nemen. Elke hierboven behandelde uitdaging is terug te voeren op dezelfde wortel: een handhavingslaag die is opgebouwd voordat er een inventaris bestond, heeft niets echts om tegen af te dwingen. Begin met ontdekken, correleer vervolgens de bronnen die tot uw beschikking staan en die elk een deel van het plaatje kunnen bestrijken, en bouw een continue monitoring op rond elke agent met zijn eigen identiteit. De volledige Zero Trust For AI Agents-beveiligingschecklist doorloopt alle drie de niveaus (inventarisatie en beheer, architectuur en handhaving, en detectie en respons) in de volgorde waarin ze moeten plaatsvinden.
Voor een diepere uitleg van deze controles kunt u met mij meegaan naar SEC530: Defensible Security Architecture and Engineering, Implementing Zero Trust for the Hybrid Enterprise, in december op SANS Cyber Defense Initiative 2026.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Ismael Valenzuela.
