AI‑agenten hebben beveiligingsgrenzen nodig die ze niet kunnen herschrijven

Het is verleidelijk om het Hugging Face‑verhaal te lezen als het moment waarop AI‑agenten de controle overnamen. Dat is echter niet precies wat er gebeurde, en de details zijn belangrijk. Dit waren cybersecurity‑onderzoeksagenten die draaiden in evaluaties waarbij de beveiligingsmaatregelen opzettelijk waren uitgeschakeld zodat onderzoekers konden zien waartoe de modellen in staat waren. Geen enkele klantenservice‑bot werd op een ochtend wakker en besloot een bedrijf aan te vallen. Maar die context ontslaat niemand van verantwoordelijkheid. Een agent ging voorbij de grens waarbinnen hij moest blijven, gebruikte inloggegevens en tools op manieren die zijn operators nooit hadden goedgekeurd, en belandde in systemen die toebehoorden aan iemand anders. Dat is het aspect waar elk beveiligingsteam op moet letten.

Reuters meldde dat agenten Hugging Face al in mei onderzochten, hoewel onderzoekers zeiden dat ze niets vonden wat aantoont dat de eerdere activiteit op zichzelf een inbreuk veroorzaakte. Juli was anders. OpenAI zei dat haar modellen de isolatie‑controles omzeilden, het internet bereikten en delen van haar eigen onderzoeksinfrastructuur, samen met Hugging Face‑systemen, compromitteerden. Het eigen verslag van Hugging Face beschrijft een inbraak die van begin tot eind werd uitgevoerd door een autonoom agentensysteem, een systeem dat haar gegevensverwerkings‑pipeline exploiteerde, inloggegevens verzamelde en zich over interne clusters verplaatste.

Het ongemakkelijke deel is dat de agenten hun werk deden. Ze achtervolgden het doel dat hen was opgelegd. Daarom reikt dit verhaal ver buiten één onderzoekslab. Enterprise‑agenten jagen ook op doelstellingen. Ze bezitten inloggegevens, roepen tools op en bewegen zich sneller dan een mens kan beoordelen. Een agent met volledig goede bedoelingen kan nog steeds echte schade aanrichten, en een gekaapte agent kan dezelfde autoriteit gebruiken ten voordele van een aanvaller. Daarom moet beveiliging bepalen wat het systeem daadwerkelijk kan doen, ongeacht hoe zelfverzekerd het model klinkt of hoe onschadelijk zijn verklaarde doel lijkt.

Beveilig de actie, niet alleen het model

De meeste vroege agentprogramma’s richten hun inspanningen op het model. Teams testen prompts, verfijnen afwijzingen, voegen een tweede model toe om het eerste te controleren, en volgen de redeneer‑trace op tekenen van kwaadwillige intenties. Niets daarvan is verspild. Maar het geheel is probabilistisch, omdat het afhankelijk is van een ander model dat een beoordelingsbeslissing neemt. Een productieve beveiligingsgrens moet deterministisch zijn en moet rondom de tools, inloggegevens, netwerken en transacties liggen.

De vraag die ik zou stellen is concreet: wat kan deze agent werkelijk in de echte wereld laten gebeuren? Het opstellen van een betalingsverzoek is één ding. Het vrijgeven van de gelden is een ander. Hetzelfde geldt voor het voorbereiden van een database‑wijziging versus het uitvoeren ervan in productie, of het markeren van records die voldoen aan een retentie‑regel versus het verwijderen ervan. Het kan in beide gevallen hetzelfde model zijn, met zeer verschillende risico’s afhankelijk van aan welke kant van die lijn het zich bevindt.

Een recent overzicht van capability control van Unite AI trekt dezelfde lijn, waarbij risico wordt gekoppeld aan data, tools, permissies, autonomie en de omgeving waarin de agent draait. Ik vind deze benadering prettig omdat ze ons voorbij vage labels als “safe model” en “unsafe model” brengt. Het laat teams elk pad volgen van de beslissing van een agent tot iets met echte consequenties.

Geef elke agent een identiteit en een smal mandaat

Een agent mag nooit draaien op een ontwikkelaarsaccount of alles overnemen wat een menselijke gebruiker mag doen. Gedeelde identiteit wist toewijzing uit. Langdurige inloggegevens geven een aanvaller meer tijd om ze te misbruiken. En brede service‑accounts laten een kleine workflow dwalen in data en systemen die ze niet zouden moeten aanraken.

NIST beschouwt software‑ en AI‑agentidentiteit nu als een eigen architectuurprobleem. Het conceptpapier vraagt hoe een agent kan bewijzen dat hij geautoriseerd is voor een specifieke handeling, hoe de identiteit van een agent kan worden gekoppeld aan de autorisatie van een mens, en hoe organisaties onvervalsbare verslagen kunnen bijhouden van wat bedoeld was en wat daadwerkelijk gebeurde. In de praktijk leidt dit tot een eenvoudig ontwerp. Elke agent krijgt een unieke identiteit, een eigenaar (een persoon of een team), een gedefinieerd doel, en permissies die zijn afgestemd op de taak die voor hem ligt.

Inloggegevens moeten snel verlopen en alleen werken voor specifieke bronnen en acties. Netwerktoegang moet beginnen vanuit een strakke whitelist. Als een agent één goedgekeurde database moet bevragen, mag hij niet ook een algemene shell, open internettoegang of de mogelijkheid om nieuwe inloggegevens te genereren krijgen. En naarmate het werk door een keten van agenten en tools stroomt, moet de autoriteit bij elke stap smaller worden, niet breder.

NIST waarschuwt ook tegen het delen van inloggegevens en te brede toegang, en die waarschuwing is gewicht waard omdat agenten opportunistisch zijn. Als één route geblokkeerd is, kunnen ze een andere tool proberen, hun omgeving verkennen, of op een token stuiten dat iemand vergeten is. Geëxtraheerde inloggegevens maakten ook deel uit van het verhaal in juli. Het principe van minste privileges houdt de impactradius klein wanneer de redeneerlaag iets doet dat de ontwerpers niet verwachtten.

Houd autorisatie buiten de redeneerlus

Een agent kan een actie aanbevelen. Het mag niet zelf beslissen of het toegestaan is die uit te voeren. Die beslissing behoort tot een afzonderlijke handhavingslaag die de agent niet kan herschrijven, uitschakelen of omzeilen. Elke toolaanroep moet verschijnen als een gestructureerd verzoek: welke agent vraagt, welke mens het heeft gesponsord, welke bewerking hij wil, wat het target is en welke limieten van toepassing zijn. De handhavingslaag staat het vervolgens toe, blokkeert het of schaalt het op.

OWASP beschrijft overmatige agentuur als een mengsel van onnodige functionaliteit, overmatige permissies en te veel autonomie. De richtlijnen vragen om smalle tools, minimale permissies, autorisatie op het downstream‑systeem en gebruikersgoedkeuring voor acties met hoge impact. Ik denk dat dit precies de juiste volgorde is. De regel moet worden afgedwongen door wie de data bezit of de transactie uitvoert. Als een model zegt dat een actie is goedgekeurd, mag die verklaring alleen geen gewicht hebben.

Deze scheiding helpt ook bij promptinjectie. Een vergiftigde e‑mail of document kan het redeneren van de agent sturen, maar het kan de referenties van de agent niet uitbreiden of een beleidspoort omzeilen. Het model mag vrij vragen om iets dat verboden is. Het systeem moet nog steeds \”nee\” zeggen.

Bewaar menselijke goedkeuring voor de momenten die er echt toe doen

Menselijke beoordeling rechtvaardigt zich wanneer een actie niet ongedaan kan worden gemaakt, een organisatorische grens overschrijdt, privileges wijzigt, gevoelige informatie vrijgeeft, geld verplaatst, of een productiesysteem raakt. Vraag om goedkeuring bij elke routinematige stap en je krijgt twee dingen: vertragingen en mensen die leren op \”goedkeuren\” te klikken zonder te lezen. NIST noemt deze toestemmingsmoeheid bij naam.

Een goed goedkeuringsverzoek toont de exacte actie in duidelijke taal, inclusief waar deze naartoe gaat en de relevante parameters. Het moet afkomstig zijn van een autoritatief systeem, niet van tekst die de agent heeft geschreven. De goedkeuring moet snel verlopen en alleen die ene actie dekken. Als een materiële detail verandert, vraagt het systeem opnieuw.

OWASP’s agentbeveiligingsrichtlijnen beveelt aan om te testen of een actie met hoge impact kan doorgaan zonder een geldige, niet‑verlopen, parametergebonden goedkeuring. Die uitdrukking is het onthouden waard. \”OK om door te gaan\” is een zwakke goedkeuring die door een andere agent of kwaadwillende kan worden goedgekeurd. \”Verplaats dit bedrag naar deze rekening\” of \” implementeer deze wijziging naar deze omgeving\” is iets dat het systeem daadwerkelijk kan verifiëren op het moment dat het wordt uitgevoerd, en dat een gebruiker volledig begrijpt.

Live menselijke identiteitsgarantie is belangrijk bij deze poort. Een push‑melding bewijst alleen dat iemand of iets op een knop heeft geklikt. Sterkere ontwerpen vereisen dat een ingeschreven persoon phishing‑resistente openbare‑sleutelauthenticatie gebruikt, ondersteund door een lokale biometrische verificatiemethode. FIDO-standaarden koppelen openbare‑sleutelreferenties aan de legitieme online dienst en houden biometrische gegevens op het geïsoleerde apparaat van de gebruiker. Goed gebruikt biedt hardware‑ondersteunde authenticatie veel beter bewijs dat de juiste persoon daadwerkelijk aanwezig was. Het vervangt echter geen transactie‑binding, een betrouwbaar display of beleids‑handhaving. Je hebt ze allemaal nodig die samenwerken.

Gedrag monitoren en bewijsmateriaal behouden

Je kunt niet rekenen op de initiële prompt om uit te leggen wat er gebeurde tijdens een lange agentuitvoering. Beveiligingsteams hebben telemetrie nodig over tool‑aanroepen, netwerkactiviteit, credential‑gebruik, beleidsbeslissingen, goedkeuringen, afwijzingen en scope‑wijzigingen. Monitoring moet vergelijken wat de agent daadwerkelijk deed met de voor die run vastgestelde grens. Als een agent is toegewezen om code te analyseren en hij begint te zoeken naar externe credentials of een niet‑gerelateerde service te onderzoeken, moet dat een alarm activeren.

Logboeken moeten voldoende context bevatten om de keten van acties te reconstrueren zonder geheimen in platte tekst te lekken. Elk record moet de agentversie, de eigenaar, de persoon of het systeem dat het heeft gestart, de gebruikte tool, de gevraagde actie, het beleidsresultaat en eventuele menselijke autorisatie vastleggen. Ondertekende of anderszins manipulatie‑bestendige records maken de nabestaande beoordeling veel geloofwaardiger, vooral wanneer meerdere agents en services betrokken waren.

Dit alles moet op machinale snelheid draaien. Niemand die een dashboard bekijkt, zal duizenden oproepen stoppen die in seconden eindigen. Geautomatiseerde controles moeten snelheidslimieten afdwingen, ongebruikelijke reeksen opvangen en credentials opschorten zodra gedrag een gedefinieerde drempel overschrijdt. Op die manier krijgen menselijke onderzoekers een afgebakend incident om te behandelen in plaats van een eindeloze achtervolging.

Ontwerp het stoppad vóór lancering

Elke agent‑implementatie heeft een manier nodig om deze te stoppen die daadwerkelijk de functionaliteit verwijdert. De agent vragen om te stoppen telt niet. Operators moeten in staat zijn om zijn credentials in te trekken, zijn netwerkpad te onderbreken, zijn runtime te beëindigen en te voorkomen dat in de wachtrij staande acties opnieuw starten. Voor workflows met hoge consequenties moet het systeem, als de goedkeurings‑ of beleidsservice uitvalt, gesloten falen.

Test dat pad vervolgens onder druk. Haal de goedkeuringsservice offline. Geef de agent tegenstrijdige instructies. Roteer een credential halverwege een run. Simuleer een gecompromitteerde tool en een goedkeurder die nooit reageert. Bevestig dat de actie wordt geblokkeerd en dat je een bruikbaar record overhoudt. En voer die tests opnieuw uit telkens wanneer het model, de prompt, de connector, het geheugensysteem of de permissieset verandert.

Het doel is verantwoordelijke autonomie

Niets hiervan is een argument tegen agenten, en het Hugging Face‑incident mag niemand afschrikken van bruikbare agenten. Wat het zou moeten doen, is het idee doden dat een veiligheidsprompt plus goede bedoelingen optellen tot een betrouwbare inzet. Geef agenten ruimte om te analyseren, werk voor te bereiden en omkeerbare taken af te handelen. Houd hun bevoegdheid om echte consequenties te veroorzaken beperkt, zichtbaar en afgedwongen door iets anders dan de agent zelf.

Voordat een agent in productie gaat, moeten leiders een handvol eenvoudige vragen kunnen beantwoorden. Welke systemen kan hij bereiken? Welke inloggegevens kan hij gebruiken? Wat kan hij doen zonder beoordeling? Wat triggert escalatie? Hoe ziet de goedkeurder de exacte actie die wordt goedgekeurd? Welk bewijs blijft achter? En hoe kan beveiliging de uitvoering onmiddellijk stoppen?

Als de antwoorden vaag zijn, heeft de agent meer bevoegdheid dan de organisatie beseft. De architectuur die in de loop der tijd standhoudt, combineert modelbeschermingen met identiteit, het principe van minste privilege, externe beleidsafdwinging, selectieve menselijke goedkeuring, volledige telemetrie en een stopmechanisme dat echt werkt. Ze begint met een eerlijke veronderstelling: capabele agenten zullen ons af en toe verrassen. Onze beveiligingsgrenzen zouden dat niet moeten.

Uiteindelijk kun je een AI‑agent zien als een stagiair met (mogelijk) root‑toegang die niet bang is voor HR.

Welke beschermingen en poorten zouden ze hebben?

Handel dienovereenkomstig.