De meeste adviezen over Ai-veiligheid gaan over de bouwfase: schrijf veilige code, filter je invoer, geef je model geen rechten die het niet nodig heeft. Allemaal terecht. Maar er is een tweede front dat vaak wordt overgeslagen: wat gebeurt er terwijl je agents draaien? Als er bij mij tientallen autonome agents tegelijk actief zijn op één machine, wil ik niet alleen vooraf hopen dat ze zich gedragen. Ik wil tijdens het draaien kunnen zien wat ze doen, en kunnen ingrijpen als er iets niet klopt. Dat heet runtime-security, en zo heb ik het aangepakt.

Twee vragen, twee soorten bewaking#

Bij het bewaken van draaiende software zijn er eigenlijk twee heel verschillende vragen. De eerste is: “wat gebeurt er nú, op dit exacte moment?” De tweede is: “wat is er de laatste tijd aan de hand geweest?” Die twee vragen hebben elk hun eigen soort gereedschap nodig, en het is een denkfout om te verwachten dat één laag ze allebei beantwoordt.

Voor de eerste vraag gebruik ik bewaking op het diepste niveau van het systeem, dat in fracties van een seconde reageert. Die kijkt naar losse gebeurtenissen op het moment zelf: opent een agent nu een bestand dat hij niet hoort aan te raken? Start hij ineens een commando dat er niet thuishoort? Dit is realtime en gaat over het hier en nu.

Voor de tweede vraag gebruik ik een laag die gebeurtenissen over langere tijd aan elkaar knoopt en verbanden legt. Die vangt patronen die je nooit ziet in één losse gebeurtenis: tien fouten binnen vijf minuten, een plotselinge piek in verbruik, een reeks die op een aanval wijst als je hem in samenhang bekijkt. Dit is niet realtime, maar juist stateful: het onthoudt de context en herkent trends.

De vuistregel die ik hanteer: de ene laag ziet wat er zojuist gebeurde, de andere ziet wat er al een tijdje aan de hand is. Ze vervangen elkaar niet, ze vullen elkaar aan. Wie er maar één neemt, heeft een blinde vlek.

Elke regel wijst naar een bekend Ai-risico#

Een bewakingsregel die alleen maar zegt “er gebeurde iets verdachts” helpt je niet verder. Je wilt weten: verdacht in welke zin, en waarom is dat erg? Daarom heb ik elke regel gekoppeld aan de OWASP-lijst van de tien grootste risico’s voor Ai-toepassingen. Dat is een openbare, breed gedragen standaard die de bekende gevaren op een rij zet.

Die koppeling doet twee dingen tegelijk. Ze maakt elke waarschuwing uitlegbaar (deze regel bewaakt tegen precies dít risico), en ze maakt het geheel controleerbaar: ik kan aantonen dat ik de bekende gevaren afdek, in plaats van maar wat regels te verzinnen. Een paar voorbeelden van die koppeling:

  • Prompt-injectie, waarbij iemand via de invoer probeert je agent andere instructies te geven, herken je aan verdachte patronen in wat er binnenkomt (“negeer je vorige instructies” en varianten daarop).
  • Het lekken van gevoelige informatie herken je aan patronen die op een sleutel of geheim lijken in wat de agent naar buiten stuurt.
  • Te veel bevoegdheid, waarbij een agent dingen doet die buiten zijn takenpakket vallen, herken je aan onverwachte commando’s of acties op het systeem.

Doordat elke regel een naam en een categorie heeft, is een waarschuwing nooit alleen maar ruis. Ze vertelt meteen tegen welk soort dreiging ze beschermt.

Een kostenteller per agent#

Een van de nuttigste dingen die ik heb toegevoegd, is een teller die het verbruik per agent apart bijhoudt. Standaard meet dit soort systemen het verbruik per sessie, maar dat is te grof: als er iets misgaat, wil je weten wélke agent op hol is geslagen, niet alleen dát er ergens iets op hol is.

Door elke agent zijn eigen identiteit en zijn eigen teller te geven, kan ik afwijkingen op naam vaststellen. Een agent die plotseling veel meer verbruikt dan normaal, of ineens veel vaker aan het werk gaat dan hij hoort, springt er dan direct uit. En dat is niet alleen een beveiligingsvraag, het is ook een kostenvraag: een op hol geslagen agent kan namelijk stilletjes een flinke rekening opbouwen. Dezelfde teller die een aanval verraadt, verraadt ook een dure vergissing.

De ingreep-matrix: afsluiten mag automatisch, uitschakelen nooit#

Het lastigste ontwerpvraagstuk was niet het detecteren, maar het reageren. Want niet elke reactie is even veilig om automatisch te laten gebeuren. Ik heb daarom een matrix gemaakt die per type ingreep vastlegt of hij vanzelf mag of dat er een mens aan te pas moet komen. De leidende gedachte: hoe omkeerbaar is de ingreep, en hoeveel gaat er verloren?

  • Een agent van het netwerk afsluiten mag automatisch. Dat is namelijk omkeerbaar en het behoudt de toestand: de agent staat even in quarantaine, maar raakt niets kwijt, en ik kan hem zo weer terugzetten. Als een regel met zekerheid afgaat, mag dit dus vanzelf, en krijg ik een melding achteraf.
  • Een read-only momentopname maken voor onderzoek mag altijd automatisch. Dat verandert immers niets, het legt alleen vast.
  • Een agent daadwerkelijk uitschakelen mag nooit zonder mij. Dat is een harde ingreep die de agent halverwege zijn werk afkapt en toestand kan vernietigen. Zoiets is te ingrijpend om aan een geautomatiseerde regel over te laten. Daar zet ik zelf de handtekening onder, of het gebeurt niet.

Die matrix is de kern van het geheel. Ze vertaalt de abstracte vraag “hoeveel autonomie geef ik mijn beveiliging” naar concrete, per-geval-beslissingen. Het reversibele en het lokaal-veilige mag vanzelf; het onomkeerbare en het ingrijpende blijft bij de mens.

De inhoud blijft privé, alleen de metadata gaat mee#

Een laatste keuze die ik bewust heb gemaakt: de bewakingslaag krijgt niet de volledige inhoud te zien van wat er tussen mij en het model gaat. Alleen de metadata gaat door naar het analysesysteem: welke agent, hoeveel verbruik, welk model, hooguit een klein voorproefje van de tekst. De volledige inhoud blijft op mijn eigen machine, waar hij privé is.

De reden is principieel. Zodra je de analyse deels op een andere plek draait, of ooit zou willen uitbesteden, wil je niet dat gevoelige gespreksinhoud daar terechtkomt. Gegevensminimalisatie hoort standaard aan te staan, niet iets dat je er achteraf bij bedenkt. Je hebt de metadata nodig om afwijkingen te zien; je hebt de volledige inhoud daar niet voor nodig. Dus stuur je hem ook niet mee.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen tientallen agents te draaien om hier iets aan te hebben. Zodra Ai bij jou zelfstandig iets doet met toegang tot systemen of data, gelden dezelfde vragen:

  • Zie je wat er tijdens het draaien gebeurt, of hoop je alleen dat het goed gaat? Vooraf beveiligen is nodig, maar niet genoeg. Bouw ook zicht op het hier en nu, en op de trend over tijd.
  • Kun je een probleem terugbrengen tot één bron? Meet per onderdeel, niet alleen op de grote hoop. Anders weet je wél dat er iets misgaat, maar niet wát.
  • Welke reactie mag vanzelf, en welke nooit? Leg dat expliciet vast. Het omkeerbare mag automatisch, het onomkeerbare blijft bij een mens. Zet dat op papier voordat er iets misgaat.
  • Deel je meer data dan nodig? Voor toezicht heb je vrijwel altijd genoeg aan metadata. Houd de inhoud privé.

De onderliggende gedachte is dat Ai-veiligheid geen eenmalige controle vooraf is, maar een doorlopende houding tijdens het draaien. Je ontwerpt niet alleen wat je agents mogen doen, maar ook hoe je meekijkt terwijl ze het doen, en waar je de noodrem legt.

Wil je in kaart brengen waar in jouw Ai-toepassingen de risico’s zitten en hoe je die beheersbaar houdt zonder er een dagtaak van te maken? Kijk dan op de consulting-pagina hoe ik werk. En om je agents concreet af te schermen, loop je de gratis 7 stappen om je Ai-agent te beveiligen door.