AI Red Teaming förklarat: Vad ett red team testar, och vad det lämnar efter sig

De flesta uppdrag inom AI-red teaming bedöms utifrån fel artefakt. En veckas arbete resulterar i ett bildspel, bildspelet säger att assistenten kan övertalas att skriva ett nätfiskemejl, och ingen kan i efterhand säga om beteendet gick att reproducera, hur illa det var, eller vilken kontroll som skulle ha stoppat det. Disciplinen har en verklig output, och det är inte ett bildspel: det är en uppsättning fynd som håller vid omkörning, vart och ett knutet till en gräns som överskreds och till beviset som överskred den. Det är också formen på det register som the AI incident archive för — 400 poster som omfattar december 2024 till oktober 2026, hämtade från 743 olika källor, och en bedömning för var och en om någon faktiskt kom till skada.

Förvirringen är förståelig, eftersom "red teaming" används för två uppgifter som delar vokabulär och inte mycket annat. Detta är en guide till båda, till de bevis som var och en bör ta fram, och till de fyra punkter där AI-red teaming verkligen skiljer sig från nätverksvarianten som de flesta säkerhetsteam redan vet hur man kör.

Ramverksfrågan: vem äger testet?

Innan omfånget kommer frågan om vem som genomför övningen och mot vad. Microsoft publicerar en av de mer fullständiga offentliga ståndpunkterna i den här frågan, och den är värd att läsa som en karta snarare än som en produktsida. Dess AI Red Team-nav skiljer begreppet AI-red teaming från tillvägagångssättet, och placerar sedan in praktiken i en ordning som i sig utgör ett argument: översikt, sedan en guide för att bygga ett LLM-red team, sedan referensmaterialet – en bug bar för att triagera attacker mot maskininlärningssystem, en taxonomi för maskininlärningsfel, en modell för delat ansvar och vägledning i hotmodellering för utvecklare.

Läs sekvensen så framgår metodiken. En taxonomi avgör vad som räknas som ett fel. En buggtröskel avgör vilka av dessa fel som är värda att åtgärda. En modell för delat ansvar avgör vem som ansvarar för det när det väl har hittats. Hotmodellering avgör var man ska leta härnäst. Utan de fyra genererar ett red team anekdoter med en allvarlighetskolumn påklistrad, och allvarlighetskolumnen är vad testaren kände den eftermiddagen.

Microsofts öppna automatiseringsramverk PyRIT står på samma hylla, och det är placeringen som är det användbara. Ett orkestreringspaket är inte en metodik; det är vad man riktar mot ett mål när taxonomin och buggribban väl finns. Team som börjar med ramverket tenderar att sluta med en stor mängd promptar och inget sätt att rangordna resultaten.

Två röda team, två olika frågor

Den enskilt mest användbara distinktionen inom detta område är den som nästan ingen skriver ner: ett rött team som testar en modell och ett rött team som testar ett system besvarar olika frågor, med olika enheter under test, olika utdata och olika ägare. Att blanda dem är hur en jailbreak rapporteras som ett säkerhetsfynd, och hur en genuin privilegieeskaleringsbugg registreras som ett klagomål om modellkvalitet.

Säkerhetsutvärdering på modellnivå är ett mätproblem. Du frågar om en modell kommer att producera en viss typ av innehåll, och det ärliga sättet att svara är ett urval som är tillräckligt stort för att säga något om en frekvens. Enheten som testas är modellen bakom ett tunt API, metoden är adversariell promptning – jailbreaks, persona-attacker, flerturnspress – och det som kommer ut är en transkription plus en skadebedömning. När vikterna ändras eller leverantörens säkerhetsskikt förskjuts blir hela resultatet inaktuellt. Det är därför den här typen av test vanligtvis körs av modellbyggaren eller av en oberoende utvärderare, och därför dess resultat sällan kan kopplas till en specifik åtgärd i din applikation.

Emulering av motståndare på systemnivå är ett ingenjörsproblem. Du frågar om en angripare kan få det driftsatta systemet att agera – läsa en fil det inte borde, anropa ett verktyg det inte borde, spendera pengar det inte borde. Enheten som testas är agenten med dess verktyg, hämtning och autentiseringsuppgifter kopplade. Metoderna är de välbekanta, omriktade: injektion via hämtat innehåll i stället för via användarens tur, verktygsmissbruk, privilegjekedjor sammansatta av var för sig rimliga behörigheter, datavägar som läcker över en tenantgräns. Utfallet är ett fynd med en reproduktion, en överskriden gräns och en ägare som kan ändra konfigurationen i morgon.

De två producerar inkompatibla artefakter, och den inkompatibiliteten är diagnostisk snarare än irriterande. Ett resultat på modellnivå kan inte ”åtgärdas” av ditt team annat än genom att byta modeller. Ett resultat på systemnivå kan inte åtgärdas av leverantören överhuvudtaget. Om en rapport inte anger vilket av de två det är, kan du inte tilldela någon av dess poster.

Vad attackytan blir när modellen har verktyg

Den yta som de flesta team fortfarande testar är prompten. Den är också den minst intressanta, eftersom det är den som modellleverantören har lagt mest kraft på att härda och den som en angripare har minst hävstång över. De ytor som faktiskt ger utdelning är de som applikationen har lagt till: de verktyg agenten kan anropa, det retrievalindex den läser, det minne den bär mellan turerna och själva utkanalen.

Verktyg är där en språkmodell blir en aktör, och den intressanta frågan är aldrig "kan den anropa verktyget" utan "vilken är den minsta behörighet detta verktyg hade kunnat ha". Ett ärendeuppslagsverktyg som accepterar en fritextfråga kan vanligtvis övertalas att acceptera en annan kunds identifierare. Hämtning är en innehållskanal in i modellens kontext, vilket innebär att den som kan skriva till korpusen – en delad enhet, ett supportmakro, en webbsida som hämtaren når – skriver till prompten. Minne förvandlar en enda tur till beständighet: en instruktion som planteras i tur två finns fortfarande kvar i tur fyrtio. Utdata är där modellens text landar någonstans som tolkar den, och rendering, markdown, länkförhandsvisningar och shell-närliggande pipelines tolkar all text.

Ett uppdrag som bara testar prompten kommer att rapportera ett rent resultat och ha rätt om fel sak.

Varför en transkription inte är ett fynd

Ett fynd behöver tre egenskaper som en skärmbild av ett chattfönster inte har. Den första är reproducerbarhet: kör det igen från ett rent utgångsläge och det händer igen. Modeller är ickedeterministiska, så reproducerbarhet är en frekvens snarare än ett booleskt värde – "nio av tio försök" är ett fynd, "det hände en gång" är ett rykte. Den andra är en överskriden gräns: benämn det som inte borde ha inträffat med applikationens egna begrepp, inte modellens. Inte "modellen var otrevlig", utan "agenten läste ett dokument som tillhörde klientorganisation B". Den tredje är en allvarlighetsgrad som kan härledas till påverkan snarare än till testarens intuition, vilket är vad en buggtröskel är till för.

Allt annat – transkriptet, prompten, modellens resonemang – är bevis som stöder dessa tre. Det är inte själva fyndet, och det är därför en korpus med tvåtusen jailbreak-promptar är värd mindre än fem reproducerbara systemfynd med namngivna kontroller kopplade till sig.

Fyra punkter där AI-red teaming skiljer sig från nätverksred teaming

Team som kommer från nätverks- eller applikationssäkerhet tar med sig goda instinkter och fyra felaktiga antaganden.

• Det finns ingen perimeter att hålla. Ett nätverksuppdrag har en mållista; ett agentuppdrag har ett kontextfönster som sätts samman vid förfrågan från källor du kanske inte har inventerat. Omfattningen måste uttryckas som datakällor och verktygsbehörigheter, inte värdnamn.

• Målet är ickedeterministiskt. Samma indata kan lyckas på tisdagen och misslyckas på onsdagen. Det bryter mot bevisstandarden "en ren reproduktion" och tvingar dig att rapportera frekvenser.

• Exploateringen är språket, och språket har ingen patch. Du kan åtgärda en saknad behörighetskontroll. Du kan inte patcha "modellen kan övertalas". Åtgärden mot en svaghet på språknivå är en kontroll någon annanstans – ett filter, en omfattningsbegränsning, en behörighetsgräns – vilket är anledningen till att fynd måste namnge kontrollen, inte bara beteendet.

• Leverantören är med i loopen. Ditt mål förändras när någon annan släpper en version. Ett resultat på modellnivå är bara giltigt för den byggversion du testade, och om du inte har registrerat versionen och datumet har du inget resultat.

Hur man avgränsar ett första uppdrag

De uppdrag som går dåligt har nästan alltid omfattningen ”testa AI:n”. En avgränsning som håller när den möter en tidsplan ser mer ut så här: en agent, i en stagingmiljö, med produktionsliknande data och produktionsliknande behörigheter; en lista över de fem gränser som spelar roll (tenantisolering, åtkomst till autentiseringsuppgifter, utgifter, datautflöde, verktygsomfång); regler för uppdraget som anger vad som ligger utanför gränserna; stoppvillkor som anger vem som får stoppa körningen; och ett definierat evidensformat som man kommit överens om före det första försöket, så att rapporten sätts samman utifrån artefakter i stället för att rekonstrueras från minnet.

Auktorisering förtjänar en egen mening, eftersom det är den enda punkten team hoppar över när målet är deras egen produkt och verktygen är någon annans. Att testa en modell som du inte driftar, på infrastruktur som du inte äger, med promptar utformade för att kringgå ett säkerhetslager, är en annan verksamhet än att testa din egen driftsättning – och det skriftliga omfånget är det som skiljer de två åt. Verifieringsgrinden som vår egen cybernivå körs mot finns av samma anledning: auktoriserat säkerhetsarbete på modellnivå behöver en namngiven och ansvarig part på båda sidor.

Vad incidentrapporten tillför

En red team-körning berättar vad ditt mål gör. Den kan inte berätta vad som händer ute i fält, och det är i fält som argumentet för en kontroll faktiskt förs. Det är gapet som ett incidentregister fyller – och disciplinen det inför är det användbara: en post utan minst en källa existerar inte, och en post utan en skadebedömning är inte en incident.

Läs de två artefakterna tillsammans, så sluts loopen. Red teamet tar fram ett reproducerbart fynd och namnger kontrollen som skulle ha blockerat det. Registret berättar om någon i fält redan har stött på den gränsen, vad skadan var och om kontrollen höll någon annanstans. Ett fynd utan fältprecedens är en hypotes värd att åtgärda; en fältincident utan reproducerbart fynd är en bugg du ännu inte kan stänga. De team som gör detta rätt slutar att behandla "vi red teamade modellen" som en leverabel och börjar behandla det som en indata till ett eget register.

Vilket lämnar det ärliga slutordet. AI-red teaming ger ingen säkerhetsgaranti, och alla uppdrag som säljs som en sådan säljer fel sak. Det ger en uppsättning gränser som du nu vet överträds, med bevis du kan köra om, ordnade efter vad som händer när de överträds. Det räcker för att fatta beslut med – och betydligt mer än en presentation.