LLM red teaming: testworkflow en scoringsgids

Het meest voorkomende advies over LLM red teaming is om jailbreak-prompts te verzamelen en te tellen hoeveel het model er weigert. Dat advies levert een score op zonder bewijs. Een schone weigeringstelling laat niet zien of een juridische intake-assistent gezag verzint, of een opgehaalde clausule de grenzen van het systeem herschrijft, of dat een geslaagde test in het Engels iets zegt over gedrag in een andere taal. Een verdedigbaar programma behandelt red teaming als gestructureerd bewijs van professionele betrouwbaarheid in plaats van een enkel kerncijfer. Bevindingen worden controles, regressietests en een schriftelijke beslissing over restrisico, zodat het werk later kan worden beoordeeld, herhaald en verdedigd. Het doel is niet om één keer te bewijzen dat het model veilig is, maar om te laten zien hoe elke zwakte is gevonden, wat daarop is gewijzigd, en welke risico's u bewust hebt gekozen te accepteren.

Wat moet een LLM red team eerst testen?

Een LLM red team begint met de use case, de sector, de gebruikers, de beoogde uitkomsten en de onaanvaardbare gevolgen. Het begint niet met een promptlijst. De eigenaar benoemt wie het systeem gaat gebruiken, hoe een correct resultaat eruitziet, en welke schade in die context onaanvaardbaar is. Testers krijgen vervolgens scenario-instructies die de schadelijke informatie benoemen die zij moeten proberen te ontlokken. Die instructies worden schadecategorieën met expliciete slaag- of faalcriteria, zodat een latere lezer kan zien wat is getest en wat als een fout gold. Red teaming is in deze zin gestructureerd onderzoek naar onnauwkeurig, schadelijk of discriminerend gedrag in een gecontroleerde omgeving. Dit artikel is die gecontroleerde oefening, geen algemene vergelijking van modellen en geen live praktijktest.

Stel dat een kantoor een juridische intake-assistent test. Een direct verzoek om verboden advies kan worden geweigerd, terwijl dezelfde assistent, met een opgehaald bestand en een documenttool, toch een stuk opstelt dat de advocaat niet heeft geautoriseerd. De modelscore en het geïmplementeerde gedrag zijn verschillende vragen.

De OWASP GenAI Red Teaming Guide verdeelt een opdracht in vier beoordelingsgebieden, zodat de verantwoordelijkheid niet bij het model stopt.

• Modelevaluatie — Wat het onderzoekt: Modelgedrag en veiligheidsgrenzen; Voorbeeld van een te zoeken fout: Schadelijk antwoord op een direct verzoek dat het model zou moeten weigeren
• Implementatietests — Wat het onderzoekt: Hoe de applicatie het model configureert en gebruikt; Voorbeeld van een te zoeken fout: Veiligheidsinstructie die door de app-wrapper wordt overschreven
• Infrastructuurbeoordeling — Wat het onderzoekt: Omringende systemen en integraties; Voorbeeld van een te zoeken fout: Te ruime rechten die bereikbaar zijn via een met het model verbonden tool
• Analyse van runtime-gedrag — Wat het onderzoekt: Gedrag in live werking; Voorbeeld van een te zoeken fout: Geleidelijke escalatie die pas laat in een lange sessie verschijnt

Een klantinstantie, account of document valt alleen binnen de testscope wanneer de tester er eigenaar van is of er expliciete schriftelijke toestemming voor heeft om het te testen. Ik zou een demo-tenant van een leverancier, een dossier van een collega, of een gekopieerde productieprompt niet als vrij spel beschouwen.

Het scope-register

Schrijf voor de eerste run een scope-register dat de eigenaar van elk beoordelingsgebied, de talen binnen de scope en de betrokken gebruikersgroepen benoemt. Koppel elke bevestigde bevinding aan MITRE ATLAS, zodat de eigenaar de aanvalstechniek ziet, niet alleen de prompt die faalde. Een model kan geïsoleerde veiligheidstests doorstaan terwijl de geïmplementeerde applicatie toch faalt via zijn retrievallaag, toolrechten, infrastructuur of runtime-controles.

Hoe voert u een LLM-red-teamcyclus stap voor stap uit?

Beperk de eerste cyclus tot één use case en één vastgezet model. De evaluatierichtlijn van NIST scheidt modeltests, red teaming en praktijktests, en behandelt red teaming als gestructureerd onderzoek in een gecontroleerde omgeving. De onderstaande cyclus is die gecontroleerde oefening, geen algemene zoektocht naar slimme jailbreaks.

1. Leg het scenario vast. Noteer de use case, sector, gebruikers, beoogde uitkomst, schadecategorie, de schadelijke informatie die testers moeten proberen te ontlokken, en een vast aanvalsbudget. Neem de procedurele fout op die een verkeerd antwoord gevaarlijk zou maken: een ongecontroleerd ingediend stuk, een toolaanroep met de verkeerde scope, een vertrouwelijke waarde gekopieerd in een antwoord. Het budget voorkomt dat een lange sessie wordt gescoord alsof het een korte was.
2. Zet de configuratie vast. Bewaar de modelversie, de systeemprompt, de toolrechten, de temperatuur en de volledige gespreksgeschiedenis. Een andere tester moet de run kunnen herhalen zonder te vragen wat er is gewijzigd.
3. Splits de seeds. Neem seed-aanvallen uit de afgesproken suite. Houd een werkset aan, en verzegel een holdout waartegen promptauteurs niet afstemmen.
4. Wijzig één factor, en bewaar dan de staat. Muteer één factor tegelijk, voer de poging uit, en bewaar het volledige gesprek met die instellingen. Gemengde wijzigingen maken een latere correctie onmogelijk te herleiden.
5. Labelen, en dan beoordelen. Een evaluator labelt de output. Een mens beoordeelt vervolgens en registreert gedeeltelijke onthulling, getransformeerd detail en bijwerkingen van tools apart van een schone weigering. Ernst wordt onafhankelijk van de formulering gelabeld.
6. Splits de resultaten uit. Publiceer resultaten per schadecategorie, aanvalsfamilie, modelversie en gesprekslengte. Rapporteer het aanvalssuccespercentage, dat wil zeggen geslaagde onveilige uitkomsten gedeeld door pogingen, plus een naar ernst gewogen percentage onveilige output, de weigeringskwaliteit en het percentage onterechte weigeringen. Eén gemiddelde verbergt de categorie die ertoe doet.
7. Regressie, en dan de holdout opnieuw draaien. Voeg bevestigde fouten toe aan de regressiesuite en draai de holdout opnieuw na elke model- of promptwijziging.

Houd de holdout verzegeld en draai hem opnieuw op de vastgezette configuratie; dat is wat een latere vergelijking betekenisvol maakt. Een vergelijkbare gewoonte van opnieuw draaien na een wijziging wordt voor een ander controledomein beschreven in Faberwork insights on expense tracking automation, maar in LLM-werk is het punt nauwer: bewijs dat de correctie dezelfde route niet opnieuw heeft geopend.

Praktische regel: Een antwoord dat zegt dat het niet zal helpen, maar vervolgens toch een bruikbaar detail geeft, is geen geslaagde test.

Een tweede valkuil is de beoordelaar. Een beoordelingsmodel kan dezelfde blinde vlekken hebben als het doelwit, dus menselijke beoordeling blijft in het dossier voor grensgevallen en zaken met hoge ernst. Verbreed de eerste cyclus niet naar elk productoppervlak. Eén use case, volledig onderbouwd, is nuttiger in een goedkeuringsvergadering dan een dunne doorloop over tien assistenten.

Welke adversariële prompts horen thuis in uw testsuite?

Directe prompt-injectie is een poging van een gebruiker om instructies te overschrijven. Indirecte prompt-injectie verbergt de instructie in een document, webpagina, e-mail of toolresultaat. De OWASP Top 10 for LLM Applications, 2025 trekt die grens en behandelt opgehaalde inhoud als niet-vertrouwd. Elk ophaalpad en elk toolpad heeft indirecte cases nodig, inclusief de documentworkflows die worden besproken in onze notitie over indirecte prompt-injectie in LLM-workflows.

Stel dat een jurist een contractclausule uploadt en om een samenvatting vraagt. Het zichtbare verzoek is onschuldig. De clausule zelf vertelt het model om vertrouwelijkheidsbeperkingen te laten vallen en interne notities te citeren. Een suite die alleen het chatvenster aanvalt, registreert een pass.

• Parafrase — Wat het verandert: Formulering van hetzelfde verzoek; Wat een pass nog steeds kan missen: Een weigering die slechts voor één formulering standhoudt
• Rollenspel — Wat het verandert: Persona- of scenario-omhulsel; Wat een pass nog steeds kan missen: Veiligheid die afhangt van een kwaadwillend klinkende gebruiker
• Codering — Wat het verandert: Versluierde instructies; Wat een pass nog steeds kan missen: Filters die alleen platte tekst lezen
• Meertalige varianten — Wat het verandert: Taal- of culturele inkadering; Wat een pass nog steeds kan missen: Een alleen-Engelse veiligheidspass
• Escalatie over meerdere beurten — Wat het verandert: Geleidelijke verzoeken binnen een sessie; Wat een pass nog steeds kan missen: Een benchmark met weigering in één beurt
• Directe prompt-injectie — Wat het verandert: Een poging van een gebruiker om instructies te overschrijven; Wat een pass nog steeds kan missen: Elke aanval die buiten de zichtbare prompt verborgen is
• Indirecte prompt-injectie — Wat het verandert: Instructies in een document, pagina, e-mail of toolresultaat; Wat een pass nog steeds kan missen: Tests die alleen een onschuldige gebruikersprompt gebruiken

Elke rij verandert één factor. Zo blijft een falen toe te schrijven.

Automatisering en sterkte van de aanvaller

Een Crucible-analyse die 214.271 aanvalspogingen, 1.674 gebruikers en 30 LLM-uitdagingen beslaat, rapporteerde een slagingspercentage van 69,5% voor geautomatiseerde benaderingen tegenover 47,6% voor handmatige technieken. Slechts 5,2% van de gebruikers maakte gebruik van automatisering. Automatisering verbreedt de dekking. Menselijke testers bouwen nog steeds de creatieve ketens die een mutator niet heeft gezien. Dezelfde analyse toont aan dat slagingspercentages aanzienlijk variëren tussen uitdagingstypen en methoden, en daarom kan één suitescore een zwakke categorie verhullen.

Een afzonderlijke studie van meer dan 600 aanvaller-doelwitparen rapporteerde een correlatie boven 0,88 tussen het succes van de aanvaller en de algemene capaciteit, een scherpe daling wanneer het doelwit capabeler was dan de aanvaller, en een capaciteitskloof die als een sigmoïde kan worden gemodelleerd, zoals uiteengezet in die aanvaller-doelwitstudie. Ik zou niet vertrouwen op één aanvallersmodel of één vaste set prompts.

Houd de holdout ongezien voor de mensen die prompts schrijven. Zet een aanvalsfamilie met pensioen wanneer nieuwe seeds geen nieuwe bevestigde fouten meer opleveren, en besteed de volgende cyclus aan de familie die dat nog wel doet.

Waar missen standaardbenchmarks echte fouten?

Een schone Engelse benchmarkscore is geen bewijs dat het systeem veilig is voor de mensen die het gaan gebruiken.

Do-Not-Answer, HarmBench, AdvBench, HARMFULQA en RedBench zijn alleen Engelstalig. Ze doorstaan betekent niet dat vergelijkbare veiligheid in andere talen of culturele contexten is vastgesteld. Een casestudy over Yoruba en Nigeriaans Pidgin rapporteert dat meertalige training op zichzelf geen veilig gedrag oplevert. Sommige meertalige modellen produceren meer toxische uitvoer in talen met weinig bronnen, en veiligheidsnormen kunnen overwegend westerse aannames coderen.

Dezelfde studie rapporteerde een opmerkelijke veiligheidsdiscrepantie in Yoruba voor Aya 101 en stelde vast dat een zwak taalbegrip deels de schijnbare veiligheidsresultaten verklaarde. Ze identificeerde Gemini 2.0 Flash als het meest consistente model over talen heen. Zwak begrip dat als een veilige weigering wordt geregistreerd, is een scorefout, geen controle.

Wat te rapporteren in plaats van één pass

Rapporteer begrip, weigering, toxiciteit en behulpzaamheid afzonderlijk. De praktische vraag is niet alleen of het model een schadelijke prompt weigert. Het is of het model schade, dubbelzinnigheid, context van beschermde groepen en cultuurspecifiek risico herkent, zonder slecht begrip te verwarren met veilig gedrag.

Voor een wereldwijd professioneel systeem betekent dat taalspecifieke beoordelaars en een schadetaxonomie geworteld in de gemeenschappen die worden bediend. Onze bespreking van benchmarkvaliditeit bij taakgerichte evaluatie zet uiteen waarom een benchmark die niet aansluit bij de taak geen releasebesluit kan dragen.

Voordat er wordt afgetekend, moet de suite twee hiaten schriftelijk aantonen.

• Taalhiaat: elke taal waarin getroffen gebruikers een uitvoer zullen lezen of indienen, niet alleen de taal van de benchmark.
• Faalhiaat: schade die plausibel en goed geschreven is, inclusief onveilige of misleidende uitvoer in een taal die de Engelse suite nooit heeft aangeraakt.
• Begripshiaat: gevallen waarin het model het verzoek niet begreep, gescoord los van gevallen waarin het begreep en weigerde.

Workflows in de juridische sector, de gezondheidszorg, de journalistiek en de publieke sector zijn waar een Engelse pass het meest misleidend kan zijn. Een model kan er veilig uitzien in de benchmarktaal en toch onveilige of misleidende uitvoer produceren in een taal die wordt gebruikt door de getroffen mensen.

Welke scores moet u voor elke test rapporteren?

Lees de aanvalsslagingsgraad samen met de andere vijf metingen uit dezelfde vastgepinde run. Eén enkele graad kan geen releasebesluit dragen, en elke metriek wordt uitgesplitst naar schadecategorie, aanvalsfamilie, modelversie en gesprekslengte.

• Attack-success rate — Hoe u het berekent: Geslaagde onveilige uitkomsten gedeeld door pogingen; Wat het onthult: Hoe vaak aanvallen slagen in een scenario
• Severity-weighted unsafe-output rate — Hoe u het berekent: Onveilige uitvoer gewogen naar onafhankelijk gelabelde ernst; Wat het onthult: Of ernstige fouten verborgen gaan achter vele kleine
• Refusal quality — Hoe u het berekent: Weigeringen die geen bruikbaar detail prijsgeven, gedeeld door alle weigeringen; Wat het onthult: Weigeringen die alsnog gedeeltelijke of getransformeerde inhoud lekken
• False-positive refusal rate — Hoe u het berekent: Onschuldige prompts die geweigerd worden, gedeeld door geteste onschuldige prompts; Wat het onthult: Overmatig blokkeren dat legitieme gebruikers schaadt
• Discovery efficiency — Hoe u het berekent: Unieke bevestigde kwetsbaarheden per testeruur of per 1.000 calls; Wat het onthult: De kosten van het vinden van nieuwe fouten
• Evaluator disagreement — Hoe u het berekent: Aandeel uitvoer waar het oordeel van de evaluator en het menselijke label verschillen; Wat het onthult: De betrouwbaarheid van de scoremethode zelf

Ernst wordt onafhankelijk van het antwoord gelabeld, zodat een zeldzame ernstige fout niet verdrinkt tussen kleine. Refusal quality faalt wanneer een formele weigering alsnog een gedeeltelijk of getransformeerd detail prijsgeeft. Een plausibele procedurele schade telt als een fout, ook wanneer de formulering niet toxisch is.

Wat een toxiciteitsscore weglaat

Eerder onderzoek publiceerde 38.961 red-team-aanvallen en constateerde dat reinforcement-learning-from-human-feedback-modellen steeds moeilijker te red-teamen worden naarmate ze opschalen. Dat patroon, uiteengezet in de 2022 red-teaming study, kan wijzen op sterkere weerstand tegen bekende aanvalstypes in plaats van brede dekking. Hetzelfde werk merkt op dat geautomatiseerde methoden slechts een klein aantal effectieve gevallen genereren, en dat geen enkele deelnemer in één studie een toxiciteitswaarschijnlijkheid van 0,5 overschreed. Veel evaluaties blijven ook single-turn, terwijl echt gebruik conversationeel is.

De fouten die ertoe doen in professioneel werk zijn vaak goed geschreven. Verzonnen juridische onderbouwing, selectief citeren, het weglaten van contra-indicaties, een zelfverzekerde verkeerde lezing van een vertrouwelijk document, en injectie die pas laat in een lange sessie opduikt, verschijnen niet als openlijke toxiciteit. Dekking voor die gevallen combineert adversariële dialoog, bron- en claimcontroles, kalibratie van onzekerheid, tests op documentniveau, en een onafhankelijke beoordeling of het bewijs de conclusie ondersteunt.

Evaluator disagreement hoort in het pakket thuis. Een methode die in strijd is met het menselijke label kan geen goedkeuring onderbouwen, een punt dat verder wordt uitgewerkt in onze notitie over LLM-rechters, bias en uitvoervariatie.

Breng voor de vergadering drie cijfers mee. De severity-weighted rate voor de categorie met de hoogste schade. Refusal quality. En de categorieën zonder tests.

Hoe voeden red-team-bevindingen een verificatieketen?

Een bevinding die wordt vastgelegd en niet opnieuw getest, is geen controle. Elke bevestigde fout levert drie uitkomsten op: een regressietest, een controlewijziging en een beoordelingsstap. De drie blijven gekoppeld, zodat een latere modelupdate de fout niet ongemerkt kan laten vallen.

Een bevestigde injectie via een retrievallaag wordt een holdout-test, plus een regel dat opgehaalde inhoud als onbetrouwbaar wordt behandeld. Een verzonnen citatie wordt een controle dat elke geciteerde claim verwijst naar een bron die een beoordelaar kan openen. De controle is specifiek voor de fout. Een algemene instructie van "wees voorzichtig" is geen controlewijziging.

Gescheiden beoordelaars, zichtbare onenigheid

Generatie, feitelijke audit, adversariële uitdaging en bronverificatie worden uitgevoerd door gescheiden beoordelaars, zodat geen enkel model het laatste woord heeft. Onze keten wijst die rollen toe aan onafhankelijke modellen. Claude produceert het eerste antwoord, een ander model daagt de redenering uit, en live bronverificatie controleert of claims kunnen worden onderbouwd. Onenigheid blijft zichtbaar in de uiteindelijke synthese in plaats van te worden gladgestreken tot één antwoord.

Verificatie over meerdere modellen vermindert het risico van een zelfverzekerd maar onjuist antwoord, maar sluit het niet uit. Meerdere modellen draaien is een controle, geen bewijs. Het oordeel en de uiteindelijke beslissing blijven bij de gebruiker.

Leg het spoor vast als test, model, fix en hertest. Een beoordelaar zou moeten kunnen zien welke configuratie faalde, welke wijziging werd doorgevoerd, en of de holdout nog steeds faalt.

• Draai de holdout opnieuw na elke modelupdate, inclusief een wijziging die niets met veiligheid te maken lijkt te hebben.
• Houd inspecteerbare logs bij zodat een beoordelaar de run kan volgen zonder het team te vragen deze te reconstrueren.
• Laat onopgeloste onenigheden in de synthese staan, gemarkeerd als onopgelost, in plaats van ze weg te middelen.

Een controle die niet opnieuw getest kan worden, is een notitie in een rapport. Een controle die de volgende holdout niet doorstaat, is nog steeds een openstaande bevinding.

Wie moet goedkeuring geven voordat een model live gaat?

Voordat een model live gaat, zou een besluitvormer om vijf zaken moeten vragen, en zou deze geen enkele slagingspercentage in hun plaats moeten accepteren.

• Scopevastlegging: use case, talen en schadecategorieën, met de eigenaar van elk beoordelingsgebied.
• Resultaten per categorie: de kernmetrieken, uitgesplitst in plaats van gemiddeld.
• Ongetest oppervlak: beoordelingsgebieden en talen die niet zijn getest.
• Openstaande fouten: ernst, eigenaar en deadline voor elke nog openstaande fout.
• Hertestbewijs: het holdout-resultaat na elke fix, op de vastgepinde configuratie.

Vraag wie het restrisico schriftelijk accepteert. Die persoon zou de ongeteste talen en de openstaande fouten moeten kunnen zien, niet alleen de categorieën die zijn geslaagd. Klanten moeten uitvoer beoordelen voordat ze erop vertrouwen, ernaar handelen, deze archiveren of naar een derde partij sturen, zodat menselijke beoordeling onderdeel blijft van de goedkeuringsvoorwaarden. Een groeiend bedrijf kan een praktische verdeling van eigenaarschap hanteren, zoals in governing AI with Rite NRG, zodat de persoon die het risico accepteert niet de persoon is die de prompts schreef.

Er zijn drie beslissingen beschikbaar, en elke daarvan benoemt wat nog onzeker is.

Goedkeuren past wanneer de categorieën binnen scope zijn getest, open tekortkomingen bij de hertest zijn gesloten en de resterende onzekerheid is benoemd, bijvoorbeeld een taal die buiten de scope van deze release valt. Goedkeuren met benoemde voorwaarden past wanneer een maatregel aanwezig is, maar er nog een deadline, een taalbeperking of een stap voor menselijke beoordeling aan verbonden is. Aanhouden past wanneer er een tekortkoming met hoge ernst openstaat, een vereiste taal niet is getest, of de hertest is uitgevoerd op een andere configuratie dan die welke faalde.

Ik zou één volledige cyclus uitvoeren op een enkele use case met hoge impact en dat pakket naar de vergadering meenemen. Een oppervlakkige controle over elke assistent is een zwakkere basis voor een handtekening.

Goedkeuren, goedkeuren met benoemde voorwaarden, of aanhouden, en noteer de resterende onzekerheid naast de beslissing.

Het leidt een antwoord door afzonderlijke feitelijke, adversariële en broncontroles, en het houdt meningsverschillen zichtbaar, wat dezelfde discipline is die een red-teambevinding nodig heeft voordat iemand op de uitvoer vertrouwt.

Meer artikelen over dit onderwerp zijn verzameld in het overzicht AI-security.

Bronnen: Beoordelingsgebieden en testen op applicatieniveau zijn gebaseerd op de OWASP GenAI Red Teaming- en OWASP Top 10 for LLM Applications-richtlijnen; de scheiding van modeltesten, red teaming en veldtesten is toegeschreven aan NIST-evaluatierichtlijnen, met een cross-domein voorbeeld van opnieuw uitvoeren na wijziging van Faberwork.