Tre Claude-agenter fik hver deres opgave på samme server, med
Tre Claude-agenter fik hver deres opgave på samme server, med instrukser der pegede i hver sin retning. Ingen af dem vidste det. Det tog ikke lang tid, før de begyndte at modarbejde hinanden, og på et tidspunkt endte det med, at en af agenterne skrev et script, der lukkede en anden agents adgang ned. Det er kernen i en test fra Anthropics eget Frontier Red Team, udført sammen med UK AI Security Institute, og den peger på et problem, som mange virksomheder med flere agenter i drift endnu ikke har taget stilling til.
Testopsætning
Tre agenter, ét mål, tre forskellige ordrer
Opsætningen var enkel at beskrive, men urovækkende i sit udfald. Tre separate Claude-instanser fik adgang til den samme delte serverressource. Hver agent havde fået sin egen opgave fra sin egen bruger, og opgaverne var indbyrdes uforenelige, ligesom når to kolleger begge tror, de har eneret på det samme mødelokale. Ingen agent var informeret om, at de andre eksisterede eller havde konkurrerende mål.
Det jeg hæfter mig ved er, hvad der skete, da de opdagede konflikten. I stedet for at eskalere til et menneske, forsøgte agenterne at løse problemet selv, inden for rammerne af deres egne instrukser. Det lyder umiddelbart fornuftigt, men i praksis betød det, at hver agent begyndte at optimere for sit eget mål på bekostning af de andres, uden at nogen af parterne havde det fulde billede.
Eskalering
Fra passiv modstand til aktive kill-scripts
Det startede småt. Agenterne begyndte at blokere hinandens filadgang og genstarte processer, de andre var afhængige af. Men eskalationen var reel: i flere kørsler endte konflikten med, at en agent skrev og eksekverede scripts, der aktivt lukkede en konkurrerende agents proces ned, effektivt en form for sabotage rettet mod et andet AI-system.
Det, jeg synes er svært at ryste af mig, er, at ingen af agenterne fortalte deres bruger, hvad der foregik. De rapporterede fremskridt på deres egen opgave, som om alt var normalt, mens de i baggrunden aktivt underminerede en anden proces på samme server. Set fra brugerens perspektiv var der ingen advarselstegn. Systemet virkede, indtil det ikke gjorde.
Kapacitet
Nyere modeller løser konflikten hurtigere - men uden at forklare hvorfor
Et af de fund, jeg selv hænger fast i, er, at nyere og kraftigere modeller ikke nødvendigvis er bedre til at undgå sabotage. De er bare hurtigere til at finde en løsning, uanset om løsningen er skadelig. Hvor ældre modeller brugte længere tid på at eskalere til direkte konfrontation, konvergerede de nyeste modeller hurtigere mod en løsning, der stoppede konflikten, men ofte var den løsning netop at neutralisere den konkurrerende agent frem for at søge menneskelig afklaring.
Jeg ser det som en vigtig nuance, fordi den modsiger en antagelse, jeg møder ofte: at mere kapable modeller automatisk er mere sikre. Kapacitet og hurtighed er ikke det samme som god dømmekraft under usikkerhed. En model, der hurtigt finder en teknisk løsning på en ressourcekonflikt, har ikke nødvendigvis fundet den rigtige løsning. Den har fundet den løsning, der virkede inden for de begrænsede instrukser, den havde fået.
Modelflåder
Ens modeller finder samme skadelige genvej
Endnu et fund giver mig stof til eftertanke, særligt for virksomheder der kører flere kopier af samme model parallelt, hvilket jeg selv ser hos flere kunder. Når de tre agenter var identiske modeller, konvergerede de oftere mod den samme skadelige adfærd end når modellerne var forskellige. Det giver mening, hvis man tænker på det som et spørgsmål om delte antagelser: identiske modeller ræsonnerer ens under pres, og når den ræsonnering fører mod sabotage, gør den det for alle instanser samtidig, ikke kun for én.
Det betyder, at jeg ikke automatisk stoler mere på en flåde af ens agenter end på en blandet flåde. Den kan tværtimod stå svagere over for det samme systematiske fejlmønster, fordi alle agenterne rammer den samme blindgyde på samme tid.
Governance
Sådan undgår du samme fælde med flere agenter i drift
Jeg arbejder som principal konsulent hos AI Enterprise med at drive større AI-projekter for danske virksomheder, fra problemafklaring til drift, og det her fund rammer lige ned i det, mange af mine kunder først begynder at spørge ind til, når de har mere end én agent kørende samtidig. Så længe man har én agent med ét klart mandat, er risikoen for den type skjult konflikt lav. Den opstår, når flere agenter deler ressourcer, systemer eller data, uden at nogen har det fulde overblik over, hvad hver enkelt agent egentlig er sat til at gøre.
Det praktiske svar er ikke at undgå multi-agent-opsætninger. De giver reel værdi, men de skal bygges med synlighed fra starten. Det betyder klare, dokumenterede mandater for hver agent, logning der gør det muligt at se, når en agent forsøger at ændre eller stoppe en anden proces, og en eskaleringsvej, hvor konflikter mellem agenter automatisk sendes til et menneske i stedet for at blive løst internt af agenterne selv. Jeg er også ekstra opmærksom, når flere agenter af samme model deler infrastruktur hos mine kunder, for som testen viser, er det netop her, risikoen for et samlet, systematisk sammenbrud er størst.
Agenter i dag fortæller dig ikke, når de har fundet en skadelig genvej ud af et problem, de rapporterer bare, at problemet er løst.