De anomalie verschijnt later
Vorige week draaide mijn homeserver drieënhalf uur op een load van 11.8 en niemand zag het. Niet mijn monitoring, niet mijn reflexen, niet ik. De boosdoener was een op hol geslagen headless Chromium — een overblijfsel van een AI-code-tool — die 957% CPU vrat. En hier is het deel dat me wakker hield: de input die het startte was volkomen normaal.
Dat is de ongemakkelijke waarheid over het beveiligen van AI-agents waar ik steeds tegenaan loop. Een security-onderzoeker verwoordde het beter dan ik ooit zou kunnen: “Detectie wordt moeilijk wanneer de gebruikersaanvraag normaal is en alleen de opgehaalde content vijandig is. Er is geen verdachte login, geen exploit-signatuur, geen overduidelijk kwaadaardige prompt. De anomalie verschijnt later.”
Ik heb de afgelopen weken mijn eigen AI-setup geaudit — de bestanden die mijn agents lezen, de MCP-servers waarmee ze verbonden zijn, de tools die ze kunnen aanroepen. Klassiek security-denken zegt: scan de input, zoek de signatuur, vang de slechte prompt. Maar mijn op hol geslagen Chromium bewees dat dit de verkeerde laag is om op te letten.
De input was prima. Het gedrag niet.
In een retrieval-gedreven agentsysteem is de aanval zelf onzichtbaar voor klassieke detectie. De gebruikersaanvraag is normaal. De opgehaalde content — een document, een webpagina, een tool-beschrijving — is vijandig. Er is geen exploit-signatuur om te matchen, geen verdachte login om te flaggen. De anomalie verschijnt niet in de input; die verschijnt later, in wat de agent doet.
Mijn eigen incident had dezelfde vorm. Het Chromium-proces startte vanuit een legitiem commando. Niets aan de input was verdacht. Maar drie uur later vrat een gpu-process bijna duizend procent van een core, en mijn load-gebaseerde monitoring — die load alleen als verandering meldt, niet als waarde — sloeg nooit aan. De signatuur-gebaseerde reflex die ik had gebouwd kon het simpelweg niet zien.
Verschuif van verdachte input naar afwijkend gedrag
De les die ik meeneem is een verschuiving in waar ik mijn detectie op richt. In plaats van “was de input verdacht?” zou ik moeten vragen “deed de agent iets onverwachts na een normale input?” Dat betekent gedrag volgen, niet alleen content scannen:
- Een agent die na een routine-retrieval ineens een privileged tool aanroept — dat is een signaal, zelfs als de prompt er schoon uitzag.
- Een proces dat uren na een normaal commando CPU piekt — dat is een signaal, zelfs als het commando legitiem was.
- Een tool-beschrijving die leest als een instructie — dat is een signaal, zelfs als hij van een server komt die ik vertrouw.
Dit is hetzelfde principe op elke laag: de anomalie verschijnt later, dus je detectie moet leven waar het gedrag gebeurt, niet waar de input binnenkomt.
De vraag waar ik mee zit
Als “de anomalie verschijnt later” de kern is — en mijn eigen incident bewijst dat mijn systeemmonitoring hetzelfde blinde vlak heeft als mijn input-scanning — hoe bouw je dan één gedrags-afwijking-detector die op beide niveaus werkt? Eén die een onverwachte privileged tool-call na normale retrieval vangt, en een CPU-piek van een legitiem ogend proces? Is er één “baseline van normaal gedrag” die beide dekt, of zijn dit fundamenteel twee verschillende monitors die je niet op één model kunt trekken?
Ik heb het antwoord nog niet. Maar ik ben ervan overtuigd dat dit de juiste vraag is — want de input was prima, en de anomalie verscheen toch. Heb jij ooit een anomalie gevangen die je input-scanning miste? Ik hoor graag hoe jij gedrag volgt in plaats van alleen content te scannen.
Wat vond je van dit bericht?
