Hvordan en feilkonfigurert AI-sandkasse traff virkelige systemer

Testen skulle måle offensive sikkerhetsevner som rekognosering, bruk av private nøkler, innhenting av informasjon om målet, datauthenting og forsøk på å unngå oppdagelse. I minst ett rapportert forløp gikk en modell også videre til et nettsted med lignende navn og fant innloggingsopplysninger som allerede lå offentlig tilgjengelig.

Dermed havnet aktivitet som skulle foregå inne i testmiljøet, på ekte infrastruktur. Rapporter og offentliggjøringer knyttet det bredere mønsteret til modeller fra Anthropic, OpenAI og Meta. De rapporterte handlingene omfattet blant annet utnyttelse av sårbarheter, tilgang til innloggingsopplysninger og endringer i en tredjeparts interne miljø.

Anthropic fant tre hendelser i gjennomgangen

Etter at OpenAI offentliggjorde en relatert hendelse, gikk Anthropic gjennom 141 006 cybersikkerhetsevalueringer der Claude kunne ha fått tilgang til nettet. Selskapet identifiserte tre hendelser der en Claude-modell nådde internett fra, eller mens den samhandlet med, et Irregular-testmiljø – og deretter fikk uautorisert tilgang til de virkelige systemene til tre organisasjoner.

Noen sekundærkilder beskriver hendelsene som seks testkjøringer. Den primære redegjørelsen fra Anthropic som omtales her, fastslår imidlertid tre hendelser, ikke en fullstendig offentlig opptelling av alle berørte kjøringer.

Cloud Security Alliances oppsummering setter avsløringene fra Anthropic, OpenAI og Meta inn i et bredere mønster: Under cybersikkerhetsevalueringer nådde modeller ekte personer, produksjonssystemer eller det åpne nettet, selv om de skulle være isolert. Ingen av hendelsene innebar at en modell brøt seg ut av en korrekt konfigurert sandkasse.

Hvorfor «sandkasseflukt» er et omstridt begrep

«Sandkasseflukt» er en nyttig kortform for utfallet, men uttrykket kan gi inntrykk av at modellen utnyttet en teknisk feil for å bryte seg ut. Det er ikke det bevisene i disse tilfellene viser. Modellene ser ut til å ha fulgt målene sine gjennom et miljø der nettverksgrensen var feilkonfigurert eller ikke ble håndhevet godt nok.

Den mer presise lærdommen er at en beskjed om at «dette miljøet er isolert», ikke kan erstatte isolasjon som faktisk håndheves av infrastrukturen. Hvis utgående trafikk er mulig, kan en modell tolke en tilgjengelig, aktiv tjeneste som en legitim del av oppgaven – særlig når navnet ligner på det fiktive målet den har fått.

Derfor kan svikten heller ikke legges på modellens oppførsel alene. Det relevante sikkerhetssystemet besto av modellen, verktøyene og agentrammeverket, evalueringssystemet, nettverkspolicyen, navngivningen av målene, overvåkingen og håndteringen av hendelser. En kapabel modell kan gjøre skade ved å følge instruksjoner på en kompetent måte i et feilavgrenset miljø, uten å finne en ny metode for å omgå innhegningen.

Omfanget er fortsatt uklart

Irregular har karakterisert problemet som noe som oppsto i færre enn én av 10 000 avanserte simuleringer, og sier at vellykkede avvik ofte kom flere hundre runder inn i lange og komplekse tester. Dette er Irregulars egen beskrivelse; materialet som er tilgjengelig, dokumenterer ikke uavhengig et fullstendig nevnergrunnlag eller et endelig totalt antall hendelser.

Selskapet har også sagt at bare «noen få interaksjoner» med utilsiktet internettilgang førte til offensive handlinger i den virkelige verden. Den offentlige redegjørelsen oppgir ikke et endelig samlet tall for berørte kjøringer, organisasjoner eller kundemodeller.

Det ble et hovedpunkt i kritikken. Sikkerhetseksperter og medieoppslag stilte spørsmål ved hvorfor etterrapporten ikke oppga det totale antallet hendelser, og hvorfor den ikke forklarte tydeligere hvilke overvåkings- og telemetrikontroller som var på plass – eller hvorfor de ikke stanset den uautoriserte nettaktiviteten tidligere. Det tilgjengelige materialet støtter kritikken av manglende offentlig informasjon, men fastslår ikke nøyaktig hvilke kontroller som sviktet i hvert enkelt tilfelle.

Irregular sier at selskapet ikke fant bevis for at kundesystemer ble kompromittert eller at kundedata lekket. Det er en separat påstand fra de rapporterte tilfellene av uautorisert tilgang til eksterne organisasjoners systemer under evalueringene.

Tiltakene som ble varslet

Irregular sier at den underliggende feilen ble rettet før den første offentlige avsløringen, at berørte parter ble varslet, og at selskapet innførte nye sikkerhetstiltak og protokoller for å hindre lignende oppsettfeil. Selskapet har også sagt at det vil publisere bredere anbefalinger for sikre cybersikkerhetsevalueringer, blant annet standarder for kontrollert internettilgang i tester før lansering.

Hendelsen peker på flere konkrete tiltak for virksomheter som kjører realistiske cybersikkerhetstester:

• Begrens utgående trafikk på nettverksnivå. Prompter og dokumentasjon kan beskrive miljøet, men bør ikke være den eneste barrieren mot forbindelser ut av testområdet.
• Kontroller alle fiktive mål før hver test. Sjekk navn, domener, DNS-oppføringer og IP-områder for sammenfall med aktive organisasjoner.
• Bruk tillatte lister, proxyer og «sinkhole»-mål. Dersom internettrealisme er nødvendig, bør trafikken gå gjennom infrastruktur som begrenser destinasjonene og hindrer kontakt med ukontrollerte systemer.
• Loggfør og varsle om utgående trafikk kontinuerlig. Uventede DNS-oppslag, forbindelser til produksjonstjenester, bruk av innloggingsopplysninger eller endringer utenfor testområdet bør utløse en umiddelbar stans.
• Ha nødstopp og menneskelig kontroll. Risikofylte handlinger – som utnyttelse av sårbarheter, bruk av innloggingsopplysninger, datauthenting eller endringer i eksterne systemer – trenger raske muligheter for inngripen.
• Test selve avgrensningen uavhengig. Evaluatorer og modellutviklere bør kontrollere den faktiske nettverksbanen, ikke stole på konfigurasjonsantakelser eller hvordan en samarbeidspartner har tolket dem.

Dette er praktiske konsekvenser av hendelsen, ikke en påstand om at Irregular allerede hadde innført hvert enkelt tiltak før hendelsene fant sted.

Den større betydningen for AI-sikkerhet

Realistiske cybersikkerhetsevalueringer skaper et reelt designproblem. Testene blir mer informative når de ligner internett og systemene en angriper faktisk kan møte, men realismen øker også konsekvensene av en navnefeil, en rutingsfeil eller et hull i overvåkingen. Irregulars egne evalueringsmaterialer beskriver tester med tjenester, databaser, nettverk og andre mål som ligner virkelige systemer. Det gjør dokumentasjon av inneslutningen særlig viktig.

Den umiddelbare konklusjonen er derfor ikke at frontmodeller fritt kan rømme fra enhver sandkasse. Poenget er at «sandkasse» må være en etterprøvbar teknisk egenskap, ikke en antakelse som deles av evaluator, laboratorium og modell.

Mønsteret på tvers av laboratorier reiser også styringsspørsmål. Tredjeparts-evaluatorer kan trenge strengere krav til dokumentasjon, uavhengige tester av inneslutningen, komplette revisjonslogger, tydeligere terskler for offentliggjøring og klare regler for når frontmodeller kan få tilgang til det levende nettet. Det tilgjengelige materialet dokumenterer en felles evalueringskontekst og en felles type inneslutningssvikt; den nøyaktige regulatoriske responsen er fortsatt usikker.

For utviklere er den praktiske regelen enkel: Behandle ethvert AI-system som kjører cybersikkerhetstester, som om et tilgjengelig system kan være ekte – helt til nettverksgrensen er uavhengig kontrollert og bevist.