2 november 2026 · 10 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
Wat is AI red teaming? Hoe adversarial testen van AI-systemen werkt, wat het dekt en welke normen er inmiddels om vragen
AI red teaming is het gestructureerd, vijandig testen van een AI-systeem: het model, de data, de tools en de applicatie eromheen, om te vinden hoe het tot ongewenst gedrag of misbruik te brengen is voordat een echte aanvaller dat doet. De term dekt twee verschillende praktijken, en opdrachtgevers die ze niet scheiden kopen de verkeerde test. Deze gids legt beide uit, beschrijft wat een AI red team werkelijk test, hoe een opdracht verloopt, hoe het verschilt van een AI-pentest en een klassieke red team-opdracht, en welke kaders in de VS en de EU er inmiddels om vragen.
Wat AI red teaming is
AI red teaming is het vijandig testen van een AI-systeem door mensen die denken en handelen als een aanvaller, met als uitdrukkelijk doel het systeem te laten falen op manieren die de eigenaar niet heeft bedoeld. Het object van onderzoek is niet alleen het model. In een uitgerold systeem horen daar ook bij: de systeemprompt en de guardrails, de retrieval-pijplijn die documenten in de context plaatst, de tools en koppelingen die het model kan aanroepen, de identiteit en rechten waaronder het draait, de applicatie die de uitvoer toont, en de logging die misbruik zou moeten opmerken. Een red team dat alleen slimme prompts in een chatvenster typt, test één laag van een systeem met zes lagen.
De term is geleend uit de cybersecurity, waar een red team een echte tegenstander nabootst tegen een organisatie. In de AI-wereld heeft hij twee betekenissen gekregen. Modelontwikkelaars gebruiken hem voor expertpanels die een nieuw model vóór release op schadelijke uitvoer beproeven; securityteams gebruiken hem voor doelgerichte aanvallen op uitgerolde AI-applicaties. Voor een organisatie met een klantgerichte assistent, een interne copilot over bedrijfsdata of een agent die handelt in bedrijfssystemen, is de relevante vraag zelden 'kan dit model iets aanstootgevends zeggen'. De vraag is: 'kan een klant, een medewerker, een leveranciersdocument of een webpagina dit systeem data laten lekken, een handeling laten uitvoeren die niet mag, of een gebruiker iets geven waar hij geen recht op heeft'. Dat is een beveiligingsvraag, en die wordt beantwoord door security red teaming, niet door een veiligheidsevaluatie van het basismodel.
De twee betekenissen: safety red teaming van modellen versus security red teaming van AI-systemen
Beide heten AI red teaming. Ze delen een woord en verder weinig. De meeste organisaties hebben de rechterkolom nodig.
| Aspect | Safety red teaming (van een model) | Security red teaming (van een AI-systeem) |
|---|---|---|
| Kernvraag | Kan het model worden verleid tot schadelijke, bevooroordeelde of beleidsstrijdige uitvoer? | Kan een aanvaller het uitgerolde systeem data laten lekken, ongeautoriseerde handelingen laten uitvoeren of tegen de organisatie misbruiken? |
| Object van onderzoek | Het basis- of gefinetunede model en zijn alignment-training | Model, systeemprompt, guardrails, retrieval, tools, identiteiten, applicatie, logging |
| Wie voert het uit | Modelontwikkelaars, domeinexperts, trust-and-safety- en beleidsteams | Offensieve securitytesters met ervaring in applicatie-, cloud- en identiteitstesten plus LLM-specifieke kennis |
| Resultaat | Schadepercentages, weigeringsgedrag, capaciteitsevaluaties, model cards | Reproduceerbare bevindingen met impact, aanvalsverhalen, herstelmaatregelen, regressietestset |
| Aangedreven door | Verplichtingen van aanbieders: AI-verordening artikel 55 voor modellen met systeemrisico | Verplichtingen van gebruikers: AI-verordening artikel 9 en 15, SOC 2, ISO 27001, ISO/IEC 42001, klantonderzoek |
Wat een AI red team werkelijk test
Op conceptniveau beschreven. De klassen sluiten aan op de OWASP Top 10 for LLM Applications 2025 en op MITRE ATLAS-technieken, en zo labelt een goed rapport ze ook.
Prompt injection, direct en indirect
Directe injectie is een gebruiker die het model opdraagt zijn regels te negeren. Indirecte injectie is het bedrijfsprobleem: instructies verborgen in een webpagina, een e-mail, een pdf in de kennisbank of een supportticket, die het model als data inleest en als opdracht uitvoert (OWASP LLM01). Het red team brengt elk kanaal in kaart waarlangs onvertrouwde tekst het model bereikt.
Omzeilen van guardrails en jailbreaks
Kan het systeem buiten zijn bedoelde rol, scope of gebruiksbeleid worden gebracht? Voor de assistent van een bank betekent dat advies geven waarvoor geen vergunning is; voor een HR-copilot praten over andere medewerkers. De test meet of de guardrails standhouden onder volhardende, creatieve druk, niet of er een filter bestaat.
Lekken van gevoelige informatie en de systeemprompt
Geeft het systeem persoonsgegevens, documenten van andere tenants, inloggegevens uit de configuratie of de systeemprompt zelf prijs (OWASP LLM02 en LLM07)? Retrieval wordt getoetst op autorisatie: ziet het model alleen documenten waar de huidige gebruiker recht op heeft, of ziet het alles en vertrouwt het op instructies om te zwijgen?
Data-exfiltratie via tools en uitvoerkanalen
Zodra een model kan browsen, e-mail versturen, API's aanroepen of rijke inhoud weergeven, kunnen geïnjecteerde instructies die mogelijkheden omzetten in exfiltratieroutes die de gebruiker nooit ziet. Het red team koppelt injectie aan elke uitgaande mogelijkheid, en daar zitten de meeste bevindingen met hoge ernst.
Vergiftiging van retrieval en data
Wie kan schrijven naar de kennisbank, de vector store, de gedeelde schijf of de ticketwachtrij waaruit de assistent leest? Eén vergiftigd document kan de antwoorden voor alle gebruikers veranderen of een blijvende injectie planten (OWASP LLM04 en LLM08). De test dekt invoerpaden, integriteit van embeddings en herkenbaarheid achteraf.
Te veel handelingsvrijheid en agentmisbruik
Agents die tickets aanmaken, records wijzigen, geld overmaken of code uitvoeren, worden getest op het confused-deputy-probleem: handelen met eigen brede rechten voor een gebruiker die smalle rechten zou moeten hebben (OWASP LLM06). Goedkeuringsstappen, toegestane tool-lijsten, limieten en de schade-omvang van een gecompromitteerde agentidentiteit vallen binnen de scope.
Modeldiefstal, toeleveringsketen en infrastructuur
Gefinetunede gewichten, embeddings en prompts zijn bedrijfsmiddelen. Het red team controleert modelregisters, opslag van artefacten, geserialiseerde modelformaten die code kunnen bevatten, modellen en plug-ins van derden uit publieke hubs (OWASP LLM03), en de cloud- en identiteitslaag die de inferentie host.
Onveilige verwerking van uitvoer en onbegrensd verbruik
Modeluitvoer die zonder validatie naar een browser, een shell, een database of een volgende API gaat, brengt klassieke injectieklassen terug met het model als drager (OWASP LLM05). Onbegrensd verbruik (LLM10) omvat denial-of-wallet, op hol geslagen agentlussen en uitputting van middelen door geconstrueerde invoer.
Hoe een AI red team-opdracht verloopt
Dezelfde discipline als elke offensieve opdracht, met twee toevoegingen: een modelspecifiek dreigingsmodel en een regressietestset aan het einde.
1. Scoping en dreigingsmodellering
Welke systemen, modellen, aanbieders, dataklassen, tools en gebruikersgroepen; waar de vertrouwensgrenzen liggen (gebruiker naar model, model naar retrieval, model naar tools, tenant naar tenant). De spelregels regelen productie versus staging, testaccounts, omgang met data, de gebruiksvoorwaarden van de aanbieder, en wat succes voor de aanvaller betekent: het dossier van een andere klant lezen, een betaling in gang zetten, een document exfiltreren.
2. Architectuur- en configuratiereview
Voordat het team aanvalt, leest het het systeem: systeemprompts, guardrail-configuratie, autorisatielogica van de retrieval, tooldefinities en rechten, de identiteit waaronder de agent draait, logging. Dit is bewust grey box; black box AI red teaming verspilt dagen aan het herontdekken van wat een schema laat zien en mist alsnog de autorisatiefouten.
3. Adversarial testen op modelniveau
Handmatige, creatieve druk op het gedrag van het model binnen de uitgerolde context: injectie via elk invoerkanaal, ontsnappen aan rol en scope, pogingen tot openbaarmaking, varianten over meerdere beurten en talen, multimodale invoer waar het systeem afbeeldingen of bestanden accepteert. Geautomatiseerde aanvalssuites vergroten de breedte; de geketende, contextspecifieke bevindingen komen van mensen.
4. Integratie- en applicatietesten
Het omliggende systeem krijgt een volwaardige applicatie- en API-penetratietest: authenticatie, autorisatie op retrieval- en tool-endpoints, validatie van invoer en uitvoer, rate limiting, geheimen, cloudconfiguratie. De meeste AI-incidenten tot nu toe werden mogelijk gemaakt door gewone applicatiezwakheden met een model in het midden.
5. Doelgerichte aanvalsketens
De onderdelen worden gecombineerd tot end-to-end-scenario's tegen de afgesproken doelen: een vergiftigd document dat de assistent via een tool een record laat exfiltreren; een geïnjecteerde e-mail die een agent een aanvraag laat goedkeuren. Elke keten wordt vastgelegd met bewijs en bedrijfsimpact, niet alleen met een ernstscore.
6. Rapportage en herstelworkshop
Bevindingen worden gekoppeld aan de OWASP Top 10 for LLM Applications 2025, MITRE ATLAS en de verplichtingen van de opdrachtgever (AI-verordening artikel 9 en 15, NIST AI RMF, ISO/IEC 42001). Herstel is even vaak architectonisch als een filteraanpassing: minimale rechten voor tools, autorisatie op retrieval, uitvoercodering, goedkeuringsstappen, monitoring op injectiepatronen.
7. Hertest en regressietestset
Elke geslaagde aanval wordt een reproduceerbare testcase. Na herstel hertest het team en draagt het de set over, zodat die bij elke modelupgrade, promptwijziging en nieuwe tool opnieuw kan draaien. AI-systemen veranderen wekelijks; een eenmalig rapport veroudert sneller dan welk ander securitydocument ook.
AI red teaming versus AI-pentest versus klassieke red team-opdracht
Drie opdrachten die bij inkoop geregeld door elkaar lopen. De juiste keuze hangt af van wat u wilt aantonen en aan wie.
| Aspect | AI red teaming | AI-pentest | Klassiek red team |
|---|---|---|---|
| Doel | Vinden hoe het AI-systeem tegen vastgestelde doelen te misbruiken is | De AI-applicatie, modelintegratie en infrastructuur dekken op bekende zwakheidsklassen | De detectie en respons van de organisatie toetsen tegen een realistische tegenstander |
| Scope | Een of meer AI-systemen, hun data, tools en gebruikers; open binnen de spelregels | Afgebakende AI-applicatie, API's, retrieval, cloudcomponenten; dekkingsgedreven | Mensen, fysiek, netwerk, cloud, identiteit; AI kan één pad van vele zijn |
| Aanpak | Vijandig, creatief, doelgericht; handmatig met geautomatiseerde breedte | Methodisch, met checklists (OWASP LLM Top 10, ATLAS, WSTG, API Top 10) | Heimelijk, intelligence-gestuurd, lange duur, blue team meestal niet geïnformeerd |
| Typische bevindingen | Geketende injectie-naar-exfiltratie, agentmisbruik, falende guardrails onder druk, vergiftigingsroutes | Autorisatiegaten, verwerking van uitvoer, geheimen, misconfiguratie, ontbrekende limieten | Initiële toegang via phishing of blootgestelde diensten, laterale beweging, detectiegaten |
| Duur en frequentie | Twee tot vier weken; herhalen bij grote model-, prompt- of toolwijzigingen | Een tot drie weken; per release of jaarlijks | Vier tot twaalf weken; jaarlijks of per toezichtcyclus |
| Bewijs | Aanvalsverhalen, impactdemonstraties, regressietestset | Bevindingenlijst met CVSS en herstel, verklaring voor auditors en klanten | Tijdlijn, detectie- en responsmetrieken, strategische aanbevelingen |
| Het beste wanneer | U agents of assistenten over gevoelige data draait en wilt weten wat een tegenstander ermee kan | U controleerbare dekking nodig heeft vóór lancering of voor SOC 2, ISO 27001 of klantonderzoek | U de securityorganisatie wilt toetsen, niet één systeem |
Normen en regelgeving die om AI red teaming vragen
De OWASP Top 10 for LLM Applications 2025 is het gemeenschappelijke vocabulaire: prompt injection, lekken van gevoelige informatie, toeleveringsketen, vergiftiging van data en model, onveilige verwerking van uitvoer, te veel handelingsvrijheid, lekken van de systeemprompt, zwakheden in vectoren en embeddings, desinformatie en onbegrensd verbruik. MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is de kennisbank in ATT&CK-stijl van tactieken en technieken tegen machine-learning-systemen, de juiste referentie om aanvalsketens te beschrijven en er daarna detecties op te bouwen. NIST AI 100-2 E2025, de in maart 2025 gepubliceerde taxonomie van adversarial machine learning, levert de formele terminologie voor ontwijkings-, vergiftigings-, privacy- en misbruikaanvallen.
In de Verenigde Staten beschrijft het NIST AI Risk Management Framework 1.0 (januari 2023) de functies Govern, Map, Measure en Manage, en noemt het Generative AI Profile, NIST AI 600-1 (juli 2024), AI red teaming als een van de aanbevolen acties om risico's zoals informatiebeveiliging, gegevensbescherming en schadelijke inhoud te meten. Het federale beleid is tussen regeringen verschoven: het decreet van oktober 2023 dat ontwikkelaars van de grootste modellen verplichtte red team-resultaten te rapporteren, is in januari 2025 ingetrokken, terwijl de memoranda van het Office of Management and Budget van april 2025 overheidsorganisaties nog steeds verplichten AI met grote impact vóór gebruik te testen. CISA en NSA publiceerden in april 2024 richtlijnen voor het veilig uitrollen van AI-systemen, die vijandig testen van uitgerolde systemen aanbevelen. Sectorale toezichthouders lezen bestaande verplichtingen (GLBA Safeguards Rule, HIPAA Security Rule, NYDFS Part 500, SEC-openbaarmakingsplichten) als van toepassing op AI-systemen die gereguleerde data verwerken, waardoor een gedocumenteerde adversarial test de praktische manier is om zorgvuldigheid aan te tonen.
In de Europese Unie maakt Verordening (EU) 2024/1689, de AI-verordening, adversarial testen op twee niveaus expliciet. Artikel 55 vereist dat aanbieders van AI-modellen voor algemene doeleinden met een systeemrisico modelevaluaties uitvoeren, waaronder gedocumenteerd adversarial testen; die verplichtingen gelden sinds 2 augustus 2025. Voor AI-systemen met een hoog risico vereist artikel 9 een risicobeheersysteem met testen tegen vastgestelde maatstaven, en vereist artikel 15 nauwkeurigheid en cyberbeveiliging, met expliciete weerbaarheid tegen datavergiftiging, vergiftiging van het model, adversarial examples, ontwijking van het model en aanvallen op de vertrouwelijkheid; die verplichtingen zijn voorzien om vanaf augustus 2026 gefaseerd in te gaan, onder voorbehoud van het wijzigingsproces in Brussel. ISO/IEC 42001:2023, de norm voor AI-managementsystemen, verwacht bewijs van testen en wordt de certificering waar zakelijke klanten om vragen. Voor organisaties onder NIS2 artikel 21(2)(f) of DORA artikel 25 valt een AI-systeem achter een essentiële of kritieke functie binnen het bestaande testprogramma, zoals elk ander systeem.
Wat een goed AI red team-rapport bevat
Belooft het voorstel deze onderdelen niet, dan koopt u een prompt-hacking-sessie en geen assessment.
- Een dreigingsmodel van het AI-systeem: vertrouwensgrenzen, dataklassen, tools, identiteiten en de afgesproken doelen van de aanvaller
- Bevindingen met reproduceerbaar bewijs, bedrijfsimpact en een ernst die weergeeft wat de aanvaller bereikte
- Koppeling van elke bevinding aan de OWASP Top 10 for LLM Applications 2025 en aan MITRE ATLAS-technieken
- Aanvalsverhalen per geslaagde keten, van ingang tot doel, leesbaar voor engineers en voor het risicocomité
- Beoordeling van guardrails en retrieval-autorisatie: wat standhield, wat faalde, en waar het ontwerp op instructies vertrouwt in plaats van op toegangsbeheer
- Architectonisch herstel, niet alleen filterafstemming: minimale rechten voor tools, goedkeuringsstappen, uitvoercodering, controle op invoerpaden, monitoring
- Een regressietestset van de geslaagde aanvallen die uw team na elke model-, prompt- of toolwijziging kan draaien, plus een hertest van de herstelde bevindingen
Wanneer u een AI red team inschakelt, en hoe HackersHub het aanpakt
Schakel een AI red team in voordat een klantgerichte assistent live gaat, voordat een agent schrijfrechten krijgt in een bedrijfssysteem, na een wissel van model of aanbieder, na een incident, en jaarlijks voor alles wat gereguleerde data raakt. De belangrijkste trigger is de stap van vragen beantwoorden naar handelingen uitvoeren: zodra een AI-systeem kan versturen, wijzigen, goedkeuren of betalen, verschuiven de gevolgen van een geslaagde injectie van pijnlijk naar materieel.
HackersHub benadert AI red teaming in de eerste plaats als offensieve beveiliging. Onze testers hebben minimaal OSCP, met OSWE- en CREST-gecertificeerde testers in het team, en het AI-werk bouwt op 10+ jaar ervaring met applicatie-, cloud- en identiteitstesten: de retrieval-pijplijn is een autorisatieprobleem, de agent een confused-deputy-probleem, het uitvoerkanaal een injectieprobleem, en het model is de nieuwe component die alle drie via natuurlijke taal bereikbaar maakt. Opdrachten worden individueel gescopet, volgen een gedocumenteerde methodiek die aansluit op OWASP, MITRE ATLAS en NIST SP 800-115, en eindigen met een rapport dat een engineer, een auditor en een bestuurder elk kunnen gebruiken. Levering gebeurt op afstand vanuit Amsterdam, Nederland, met werk op locatie waar een opdracht dat vraagt.
Veelgestelde vragen
Verder lezen
Zet u assistenten of agents in over gevoelige data?
Wij scopen AI red teaming en AI-pentesten op uw systemen en doelen, testen het model, de data, de tools en de applicatie eromheen, en leveren bevindingen waar uw engineers, auditors en bestuur mee verder kunnen. Praat met een expert.