AI Blue Teaming uitgelegd: de drie lagen waarin een controle daadwerkelijk kan leven

Vraag een securityteam waar de AI-guardrails zich bevinden en het antwoord noemt meestal een beleidsdocument, een systeemprompt of een leveranciersfunctie. Geen daarvan is een beheersmaatregel. Een beheersmaatregel is iets dat op het moment van een actie beslist of de actie plaatsvindt — en voor een AI-agent zijn er slechts drie plekken die kunnen beslissen: het model, de gateway ervoor en de omgeving eromheen. Alles wat een blue team eerlijk kan beloven, komt uit de tweede en derde daarvan. Dit is de laagvraag, en die gaat vooraf aan elke andere beslissing van het blue team, inclusief wat je moet loggen en wie je moet bellen. Daarom doet de praktijkervaring ertoe: het AI-incidentenarchief bevat 400 agent-incidenten van 2024-12 tot en met 2026-10-17, en de meeste daarvan zijn geen verhalen over een model dat zich misdraagt. Het zijn verhalen over een deployment zonder laag die nee kon zeggen.

Blue teaming in de AI-betekenis is het werk om die lagen aan te brengen, af te stemmen waarop ze letten en een ingestudeerd antwoord klaar te hebben voor de dag dat een van die lagen afgaat. Het is weinig glamoureus, het levert geen score op, en het is de enige helft van het red-team/blue-team-paar die het risicocijfer verandert.

Wat een blue team erft, en wat niet

Traditioneel blue teaming berust op een reeks aannames die AI-implementaties stilletjes ondermijnen. Van logs werd aangenomen dat ze compleet waren, omdat het netwerk elk packet zag. Van assets werd aangenomen dat ze opsombaar waren, omdat iemand ze moest provisioneren. Van gedrag werd aangenomen dat het deterministisch was, omdat een programma hetzelfde doet bij dezelfde invoer. Geen van de drie doorstaat de confrontatie met een agent.

Wat een blue team in plaats daarvan erft, is een systeem waarin de meest ingrijpende beslissingen plaatsvinden binnen een request die de netwerklaag behandelt als gewoon HTTPS-verkeer naar één hostnaam. De prompt, de opgehaalde context, de tool calls, de completion — alles zit in een request body, en als niemand die body vastlegt en parseert, is de deployment functioneel onbewaakt, hoe goed de perimeter ook is. De eerste taak van het blue team is daarom niet detectie; het is het opzetten van een sensor. Zonder zichtbaarheid op request- en toolniveau is er niets om op te detecteren, en elke downstream controle is decoratief.

Wie kan de controle daadwerkelijk afdwingen?

Zodra er een sensor is, wordt de vraag waar elke maatregel mag staan. De nuttige manier om dit in kaart te brengen is op basis van eigenaarschap in plaats van technologie, omdat eigenaarschap bepaalt of een maatregel de volgende release overleeft.

De modellaag behoort toe aan wie hem heeft getraind. Je configureert hem niet, je kunt er niet in kijken, en zijn gedrag verandert wanneer de leverancier een nieuwe versie uitbrengt — en dat kan op elke dinsdag zijn. Wat je wel kunt doen, is een versie vastpinnen en een versiewijziging behandelen als een wijziging van je risicopositie die een hertest vereist. Wat je niet kunt doen, is hier aanspraak maken op een beheersmaatregel. "Het model weigert schadelijke verzoeken" is een eigenschap waarop je vertrouwt, niet een mechanisme dat je zelf bedient.

De gatewaylaag is de plek waar elke prompt en completion door een component gaat dat je zelf beheert. Hier zitten budget- en snelheidslimieten, hier worden allow-lists en toolmachtigingen afgedwongen, hier is logging van requests en responses inherent compleet, en hier kan een request worden herschreven, geblokkeerd of omgeleid voordat er ook maar één token wordt gefactureerd. Gateway-controls zijn bovendien de enige die gekoppeld blijven wanneer je van model wisselt, wat belangrijker is dan het klinkt: teams die hun controls in prompts stoppen, verliezen ze volledig op de dag dat ze migreren.

De omgevingslaag is de laag die volledig van jou is: inloggegevens en hun scopes, uitgaand netwerkverkeer, bestandstoegang, sandboxlimieten voor kloktijd en uitgaven. Het is ook de plek waar een gecompromitteerde uitvoering haar schade aanricht. Een agent die ertoe is overgehaald kwaadwillig te handelen, is precies zo gevaarlijk als wat de omgeving die actie liet bereiken — en de omgeving is de enige plek waar "least privilege" een configuratiewijziging is in plaats van een onderzoeksprobleem.

De praktische test voor elke voorgestelde AI-controle is één vraag: welke van deze drie lagen handhaaft die? Als het antwoord de modellaag is, is de controle een hoop. Als het antwoord "de systeemprompt" is, is het een suggestie binnen de modellaag, wat erger is dan een hoop, omdat er documentatie bij zit die het tegendeel beweert.

Detecteren: wat een agent daadwerkelijk uitzendt

Detectie voor agents draait op een andere set signalen dan detectie voor mensen. Er is geen loginanomalie om mee te correleren. Wat er in plaats daarvan is, is een verzoekstroom met een ongewoon rijke structuur, en vier families van signalen die alarmering rechtvaardigen.

• Volume en vorm van tool-aanroepen. Een agent die plotseling veertig keer een bestandslees-tool aanroept binnen één taak, of waarvan de tool-sequentie verandert van drie stappen naar dertig, is het bekijken waard — niet omdat hij kwaadwillig is, maar omdat de distributie is verschoven.

• Herkomst van content aan de grens. Welke tekst in de prompt afkomstig was van de gebruiker, welke uit retrieval, welke uit een toolresultaat en welke uit het geheugen. De meeste detectie van prompt-injectie komt neer op "instructietekst verscheen in een kanaal dat alleen gegevens zou moeten bevatten", en dat kun je niet berekenen tenzij de gateway de herkomst bij binnenkomst labelt.

• Egress- en scopegrenzen. Verzoeken naar bestemmingen buiten de allowlist, het lezen van paden buiten de scope, pogingen om credentials te gebruiken buiten de dienst waarvoor ze bedoeld zijn. Dit zijn zeer precieze signalen en ze zijn goedkoop, omdat de omgeving al weet wat was toegestaan.

• Uitgaven en latentie als proxy. Een op hol geslagen lus en een compromittering zien er beide uit als een kostencurve waarvan de helling verandert. Budgetwaarschuwingen zijn de minst glamoureuze detectie in de stack en behoren tot de snelste die zichzelf terugverdienen.

Wat opzettelijk ontbreekt in die lijst, is een classifier die moet beoordelen of een completion schadelijk was. Het is het detectie-idee waar teams het eerst naar grijpen en het idee dat het slechtst veroudert: het verschuift mee met het model, het heeft een percentage fout-positieven dat je analisten aanleert het te negeren, en het levert je niets op om in een runbook te zetten.

Inperken: de drie knoppen die een slechte run stoppen

Inperking voor een agent is eenvoudiger dan het lijkt, want met drie knoppen dek je bijna alles af. Budget begrenst wat een run kan uitgeven, waarmee zowel de financiële schade als de impactradius van een loop wordt beperkt. Scope begrenst waar een run aan kan komen — de tools die voor die taak zijn ingeschakeld, de paden, de tenants. Sandbox begrenst hoe lang hij kan draaien en wat hij tijdens het draaien kan bereiken. Alle drie zijn gateway- of omgevingsinstellingen, wat een andere manier is om te zeggen dat ze afdwingbaar zijn.

Het ontwerpprincipe dat ertoe doet, is scope per taak in plaats van scope per agent. Een agent met een vaste set rechten is een agent waarvan de rechten zich zullen opstapelen tot iemand ze controleert; een agent die voor de duur van een taak een aan die taak gebonden credential krijgt, heeft een grens die vanzelf verloopt. Het tweede kost meer werk om te bouwen en is veel goedkoper om te verdedigen.

Het is ook waar een gateway zijn naam verdient. Controles die vóór elke modelaanroep staan — tool- en MCP-aanroepen die worden beoordeeld voordat ze worden uitgevoerd, contentbeleid en masking van persoonsgegevens die worden toegepast voordat de aanvraag in rekening wordt gebracht — zijn dezelfde controles, of het model erachter nu het model is dat je vorig kwartaal gebruikte of het model dat vorige week werd uitgebracht. Die continuïteit is het eigenlijke product: geen betere filter, maar een plek waar de filter kan staan die niet meebeweegt wanneer het model dat doet.

Herstellen: opnieuw afspelen, patchen, opnieuw testen

Herstel na AI-incidenten heeft één voordeel ten opzichte van herstel na netwerkincidenten: de hele run wordt meestal vastgelegd. Prompt, context, tool-aanroepen, completions, timings — als de gateway ze heeft gelogd, kan het incident opnieuw worden afgespeeld, wat een sterker startpunt is dan de meeste forensische onderzoeken krijgen.

Replay dient drie doelen, in deze volgorde. Het stelt vast wat er werkelijk is gebeurd, in plaats van wat het transcript suggereert dat er is gebeurd nadat meerdere mensen het hebben samengevat. Het identificeert de controle die had moeten afgaan, wat het verschil is tussen een symptoom verhelpen en een grens herstellen. En het levert de regressiecase op: een vastgelegde invoer die nu geblokkeerd moet worden, uitgevoerd tegen de nieuwe configuratie om te bewijzen dat dat ook gebeurt.

De patchstap is waar blauwe teams er het vaakst naast mikken. Als de bevinding een modelgedrag was, liggen alle beschikbare mitigaties buiten het model — een verkleining van de scope, een filter bij de gateway, een permissie die uit de omgeving is verwijderd. Als de bevinding systeemgedrag was, zit de oplossing in de configuratie en is de regressietest goedkoop. Hoe dan ook, opnieuw testen is niet optioneel, omdat zowel de oplossing als de modelversie verandert, en een controle die tegen de build van vorige maand is geverifieerd, is een bewering over vorige maand.

Oefenen voor de dag dat het afgaat

Een runbook dat nooit onder druk is gelezen, is een document, geen vermogen. De oefening die loont, is smal en specifiek: neem één plausibel agentincident, loop het van begin tot eind door en klok elke stap. Wie merkt het? Hoe lang duurt het voordat een mens naar de juiste logregel kijkt? Wie kan de run stoppen — één met naam genoemde persoon, of een commissie? Wie kan de credential intrekken, en hoe lang duurt het voordat de intrekking zich heeft verspreid? Wie beslist of iemand buiten het bedrijf op de hoogte wordt gebracht?

Twee van die vragen laten teams steevast de mist ingaan. "Wie kan de run stoppen" gaat mis wanneer stoppen iemand vereist die slaapt, dus het antwoord moet een mechanisme zijn in plaats van een persoon — een budgetplafond of een kill switch die een dienstdoende engineer alleen kan omhalen. "Hoe lang duurt het intrekken" gaat mis omdat inloggegevens vaak in de cache staan van componenten die niet in het diagram voorkwamen.

Het archief lezen is de goedkoopste vorm van oefening die beschikbaar is, omdat je er de incidentstructuur van anderen mee erft in plaats van je eigen structuur te bedenken. Neem een handvol vermeldingen die op je uitrol lijken en stel voor elk daarvan de drie bovenstaande vragen. De vermeldingen waarop je ze niet kunt beantwoorden, zijn de hiaten in je runbook, en je hebt ze vóór het incident gevonden in plaats van erna.

De asymmetrie die het waard is om ronduit te benoemen

Red teaming en blue teaming zijn geen symmetrische activiteiten en zouden niet zo begroot moeten worden alsof ze dat wel zijn. Een red-teamrun is begrensd door een planning en levert een reeks bevindingen op die verouderen naarmate het doel verandert. De beheersmaatregelen van een blue team blijven bestaan, versterken elkaar en zijn het enige dat daadwerkelijk tussen een slechte input en een slechte uitkomst staat. Het ene kan een grens vinden; alleen het andere kan die grens bewaken.

Wat de eerlijke standaard voor een blue team ongeglamoureerd en controleerbaar maakt. Voor elke beheersmaatregel die je claimt, zou je de laag moeten kunnen noemen die deze afdwingt, de logregel die bewijst dat hij is afgegaan, de melding die je vertelt wanneer dat niet gebeurde, en de persoon die de run kan stopzetten. Vier zinnen. Als een daarvan ontbreekt, is de beheersmaatregel een beleidsdocument, en beleidsdocumenten lezen geen request bodies.