AI‑assistenter og AI‑systemer i drift: en ny vej ind i red team‑øvelsen

Når medarbejderne får en AI-assistent, der kan læse deres mail, søge i delte dokumenter og handle i forretningssystemer, får organisationen samtidig en ny aktør med adgang til netop det, en modstander er ude efter. Spørgsmålet til en klassisk red team-øvelse er derfor ikke, om modellen svarer fornuftigt, men om forsvaret ville opdage, at assistentens adgang blev misbrugt som et led i et angreb. Svaret hviler på at behandle assistenten som det, den er i driften: en identitet med rettigheder, logs og ejere, som kan indgå i scenariet på linje med andre systemer.

Ikke det samme som AI red teaming

Ordet AI red teaming bruges om afprøvning af selve modellen: om den kan bringes til at give skadelige, forkerte eller fortrolige svar. Den disciplin har sine egne deltagere og resultater og er beskrevet for sig. → AI red teaming: samme ord om en anden disciplin

Her er genstanden en anden. Organisationen er målet, og AI-assistenten er en del af landskabet, som holdet bevæger sig igennem. Forskellen kan stilles op sådan:

Afprøvning af modellen · spørger, hvad systemet siger og gør, når det udsættes for bestemte input. Modtageren er dem, der udvikler eller indfører løsningen.
Assistenten i en klassisk øvelse · spørger, om overvågning, eskalering og beredskab reagerer, når en modstander bruger assistentens adgang. Modtageren er sikkerhedsfunktionen og blue team.

Resultaterne kan ikke erstatte hinanden. En model, der klarede sig godt i en afprøvning, kan stadig have rettigheder, ingen holder øje med.

Assistenten som identitet med rettigheder

En assistent, der handler på vegne af en bruger, kan arve brugerens adgang og nogle gange mere. Det afhænger af løsningen, og derfor er det første skridt i planlægningen at kortlægge, hvad assistenten faktisk kan nå:

Data · hvilke postkasser, mapper og systemer kan den søge i?
Handlinger · kan den sende mails, oprette sager, ændre data eller kalde andre systemer?
Forbindelser · hvilke tilkoblede tjenester og integrationer er godkendt, og af hvem?
Ejer · hvem i organisationen har ansvaret for opsætning og rettigheder?

OWASP’s liste over de største risici for applikationer bygget på store sprogmodeller nævner blandt andet for vidtgående handlefrihed, hvor systemet har fået flere muligheder, end formålet kræver. For CISO’en er pointen den samme som ved andre identiteter: jo bredere adgang, jo mere interessant for en modstander, og jo vigtigere at nogen ser, hvordan den bliver brugt. → Scope i red teaming

Hvad scenariet kan belyse

Assistenten kan indgå i et scenarie på flere måder, uden at øvelsen bliver en test af modellen:

Udgangspunktet · et assumed breach-scenarie, hvor holdet starter med en almindelig brugers konto, og hvor assistenten er en af de muligheder, kontoen giver. → Assumed breach som scenarie
Rækkevidden · om assistentens adgang gør det lettere at finde de oplysninger, der fører videre mod målet.
Synligheden · om forsvaret kan se, hvad assistenten har søgt i og gjort, og skelne det fra brugerens egne handlinger.
Reaktionen · om nogen ved, hvordan assistentens adgang spærres, og hvem der skal kontaktes hos leverandøren.

Det sidste punkt fortjener opmærksomhed. Når assistenten er en tjeneste fra en leverandør, ligger en del af de spor, forsvaret har brug for, hos leverandøren og ikke i jeres egen logning. Overvej derfor før øvelsen, om de relevante logs overhovedet når frem til den overvågning, der skal måles, og hvor længe de gemmes. Hvis svaret er nej, er det et fund i sig selv, og det kan være mere værd at få det afklaret i planlægningen end at lade holdet bevise det. Aktivitet gennem en assistent kan ligne almindelig brug, og en hændelse kan derfor være svær at skelne fra en travl medarbejders arbejdsdag. → Angreb, der ligner normal brug

Flag og grænser

Flaget bør vise adgang uden at hente rigtige følsomme data ud. Et aftalt dokument, som white team placerer et sted, assistenten kan nå, er en mulighed. Holdet dokumenterer så, at dokumentet kunne findes eller bruges, uden at rigtige kundeoplysninger flytter sig. Aftal også, hvem der ejer fundet, hvis assistentens rettigheder viser sig at være bredere end forventet: sikkerhedsfunktionen, systemejeren eller den forretningsenhed, der bestilte løsningen.

Hvis assistenten er en tjeneste fra en leverandør, gælder leverandørens vilkår for test ved siden af jeres egen tilladelse. Rules of engagement bør sige, at holdet holder sig til jeres egen tenant og ikke forsøger at påvirke den fælles model eller andre kunders brug af den. Den del er ikke jeres at afprøve. → Driftsleverandører og cloududbydere i øvelsen

Et fælles sprog i rapporten

MITRE ATT&CK bruges til at beskrive de skridt, en modstander tager i et klassisk forløb. MITRE ATLAS er en offentlig vidensbase over modstanderes taktikker og teknikker rettet mod AI-systemer. Når en del af angrebsvejen går gennem en AI-løsning, kan det være nyttigt at aftale med holdet, hvilken ramme rapporten bruger til den del, så blue team kan koble fundet til sin egen detektionsdækning. → MITRE ATT&CK i red teaming

Regler, der kan spille ind

Efter artikel 3, nr. 4, i forordning (EU) 2024/1689 om kunstig intelligens er en idriftsætter den, der anvender et AI-system under sin myndighed. En organisation, der har indført en AI-assistent, kan derfor have forpligtelser som idriftsætter, og hvilke der gælder, afhænger af systemet og brugen. En øvelse dokumenterer ikke, at forpligtelserne er overholdt. Hvis assistenten giver adgang til personoplysninger, gælder de samme hensyn til dataminimering som i resten af øvelsen. Teksten er ikke juridisk rådgivning. → Persondata i øvelsen

Det skal I lade være med

At bestille en afprøvning af modellen og forvente svar om forsvaret · det er to forskellige opgaver.
At holde assistenten ude af scope, fordi den er ny · en modstander tager ikke det hensyn.
At lade rettighederne være ukendte før start · kortlægningen er en del af planlægningen.
At lade holdet påvirke den fælles model eller andre kunder · hold jer til egen tenant.
At hente rigtige følsomme data gennem assistenten · brug et aftalt flag.

Hvad kan og ikke kan konkluderes

Et scenarie, hvor AI-assistenten indgår, kan vise, om forsvaret ser og reagerer på misbrug af dens adgang, og om dens rettigheder står mål med formålet. Det kan ikke vise, om modellen er robust over for manipulation, og det dokumenterer ikke overholdelse af regler om AI. Et scenarie, hvor assistenten ikke blev brugt, siger intet om den.

Tjekliste før scenariet

☐ Er det aftalt, at genstanden er forsvaret og ikke modellen?
☐ Er assistentens data, handlinger og forbindelser kortlagt?
☐ Er der en navngiven ejer af opsætningen?
☐ Er leverandørens vilkår for test afklaret?
☐ Er flaget placeret, så ingen rigtige følsomme data skal hentes?
☐ Ved blue team, hvor aktivitet fra assistenten kan ses?

Kilder

OWASP Top 10 for LLM Applications: listen over risici for applikationer bygget på store sprogmodeller, herunder for vidtgående handlefrihed (Excessive Agency).
MITRE ATLAS: offentlig vidensbase over modstanderes taktikker og teknikker rettet mod AI-systemer.
Forordning (EU) 2024/1689 (AI-forordningen): artikel 3, nr. 4, definitionen af idriftsætter.

Senest gennemgået: oktober 2026.