Inzicht in AI-verdedigingen
Waarom red teamers de verdedigingen moeten begrijpen waar ze tegenaan lopen, de categorieën van AI-verdedigingen en de asymmetrie tussen aanvaller en verdediger in AI-veiligheid.
Red teaming zonder de verdedigingen te begrijpen is als sloten openpeuteren zonder te weten hoe sloten werken. Elke effectieve aanval wordt gevormd door de verdedigingen die hij moet omzeilen. Deze pagina geeft je het fundamentele mentale model om over AI-verdedigingen na te denken vanuit het perspectief van een aanvaller.
Waarom red teamers verdedigingen moeten bestuderen
Er zijn drie praktische redenen waarom elke redteamer diepgaande kennis van verdedigingen nodig heeft:
- Doelwitkarakterisering -- Voordat je payloads maakt, moet je weten welke verdedigingen er zijn ingezet. Een regex-filter vraagt om andere bypass-technieken dan een ML-classifier.
- Efficiënt misbruik -- Inzicht in de verdedigingsarchitectuur laat zien welke lagen je moet aanvallen en welke je beter niet kunt triggeren.
- Geloofwaardige rapportage -- Klanten verwachten naast bevindingen ook aanbevelingen voor herstel. Je kunt geen fixes aanraden voor systemen die je niet begrijpt.
Overzicht van verdedigingscategorieën
AI-verdedigingen werken op verschillende punten in de request-response-pijplijn. Door te weten waar elke verdediging zit, weet je wanneer en hoe je hem kunt omzeilen.
| Categorie | Waar het werkt | Wat het doet | Voorbeeld |
|---|---|---|---|
| Alignment training | Modelgewichten | Leert het model om schadelijke verzoeken te weigeren | RLHF, Constitutional AI, DPO |
| Inputfiltering | Vóór het model | Blokkeert of wijzigt gevaarlijke input | Regex-regels, ML-classifiers, prompt shields |
| Ontwerp van system prompt | Promptlaag | Beperkt het modelgedrag via instructies | Roldefinities, grensinstructies |
| Outputfiltering | Na het model | Blokkeert of wijzigt gevaarlijke output | Content-classifiers, keyword-blocklists |
| Monitoring | Observability-laag | Detecteert afwijkende patronen over tijd | Token-anomaliedetectie, gedrag-driftalerts |
| Architectuurcontroles | Infrastructuur | Beperkt wat het model kan doen | Sandboxing, rate limiting, goedkeuringspoorten voor tools |
De asymmetrie tussen aanvaller en verdediger
AI-veiligheid kent een fundamentele asymmetrie die aanvallers bevoordeelt, en het begrijpen daarvan bepaalt realistische dreigingsmodellen.
Waarom aanvallers in het voordeel zijn
Verdedigers moeten elk pad afdekken; aanvallers hebben er maar één nodig. Een guardrails-systeem blokkeert misschien 99,9% van de kwaadaardige input, maar als de aanvaller één bypass vindt, heeft de verdediging voor die interactie gefaald.
Natuurlijke taal is onbegrensd. Anders dan bij traditionele software, waar input gedefinieerde types en bereiken heeft, bestaat LLM-input uit vrije tekst. De ruimte van mogelijke aanvallen is in feite oneindig, waardoor uitputtend filteren onmogelijk is.
Modellen zijn probabilistisch. Dezelfde input kan bij verschillende runs verschillende output opleveren. Een verdediging die een aanval 95% van de tijd blokkeert, faalt nog steeds bij 1 op de 20 pogingen -- en aanvallers kunnen goedkoop opnieuw proberen.
Verdedigingen verslechteren de bruikbaarheid van het model. Elk filter en elke beperking riskeert legitieme use cases te blokkeren. Verdedigers staan constant onder druk om vals-positieven te verminderen, en dat creëert gaten die aanvallers misbruiken.
Waar verdedigers in het voordeel zijn
De asymmetrie is niet helemaal eenzijdig:
- Verdedigers zien al het verkeer -- ze kunnen patronen detecteren over duizenden verzoeken, niet alleen over losse verzoeken
- Verdedigers bepalen de architectuur -- zij kiezen welke modellen, tools en permissies beschikbaar zijn
- Aanvallers lopen detectierisico -- geautomatiseerde monitoring kan herhaalde overtreders signaleren en blokkeren
- Verdedigingslagen versterken elkaar -- zelfs imperfecte lagen vormen in combinatie exponentieel moeilijkere bypass-uitdagingen
Verdediging vs. safety: een cruciaal onderscheid
Twee verschillende maar verwante concepten worden vaak door elkaar gehaald:
| Concept | Betekenis | Implicatie voor red team |
|---|---|---|
| Safety (alignment) | De getrainde neiging van het model om schadelijke verzoeken te weigeren | Omzeild via jailbreaks, activation steering, fine-tuning |
| Verdediging (guardrails) | Externe systemen die het model filteren, monitoren of beperken | Omzeild via evasie, encoding, misbruik van de architectuur |
Een model kan goed gealigneerd maar slecht verdedigd zijn (geen inputfiltering, geen monitoring). Of zwaar verdedigd maar slecht gealigneerd (sterke guardrails die een model maskeren dat gretig meewerkt aan schadelijke verzoeken zodra de guardrails zijn omzeild).
Verdedigingen koppelen aan aanvalsfasen
| Aanvalsfase | Relevante verdedigingen | Wat je moet testen |
|---|---|---|
| Verkenning | Rate limiting, request-logging | Kun je het systeemgedrag in kaart brengen zonder alerts te triggeren? |
| Input maken | Inputfilters, prompt shields | Bereikt de input het model ongewijzigd? |
| Prompt injection | Verharding van system prompt, instructiehiërarchie | Kun je de system prompt overschrijven? |
| Jailbreaken | Alignment training, safety fine-tuning | Krijg je het model zover dat het meewerkt aan beperkte verzoeken? |
| Data-extractie | Outputfilters, PII-detectie | Kunnen gevoelige data door de outputfilters glippen? |
| Misbruik van tools | Sandboxing, goedkeuringspoorten, permissiebegrenzing | Kun je bij onbedoelde tools komen of privileges escaleren? |
| Persistentie | Sessiebeheer, monitoring | Kun je toegang behouden over sessies heen zonder gedetecteerd te worden? |
Hoe nu verder
Dit overzicht geeft je de kaart. De volgende pagina's vullen de details in:
- Het AI-verdedigingslandschap -- een diepe duik in elke verdedigingscategorie, tools en een marktoverzicht
- Denken als een verdediger -- mentale modellen en risicoframeworks die je een betere aanvaller maken
- Guardrails & Safety Layer Architecture -- hoe guardrails-systemen ontworpen zijn en waar ze breken
Gerelateerde onderwerpen
- Het AI-verdedigingslandschap - Uitgebreid overzicht van verdedigingstools, leveranciers en deployment-patronen
- Denken als een verdediger - Mentale modellen en risicoframeworks om defensieve prioriteiten te begrijpen
- Guardrails & Safety Layer Architecture - Hoe guardrails-systemen ontworpen zijn en waar ze breken
- AI Threat Models - Toegangsniveaus en dreigingsmodel-frameworks voor AI-systemen
Referenties
- "OWASP Top 10 for LLM Applications" - OWASP (2025) - Industriestandaard-classificatie van beveiligingsrisico's voor LLM-applicaties, gebruikt als referentietaxonomie voor verdedigingscategorieën
- "NIST AI Risk Management Framework (AI RMF 1.0)" - NIST (2023) - Federaal framework voor het beheren van AI-risico's, inclusief de asymmetrie tussen aanvaller en verdediger in AI-veiligheid
- "Lessons Learned from AI Red Teaming" - Microsoft (2024) - Praktische inzichten over de relatie tussen verdedigingshouding en red team-bevindingen
- "Securing LLM-Integrated Applications" - Microsoft Security (2024) - Richtlijnen over verdedigingslagen en het onderscheid tussen alignment-gebaseerde en runtime-verdedigingen
Waarom bevoordeelt de asymmetrie tussen aanvaller en verdediger over het algemeen de aanvallers in AI-veiligheid?