AI-agenter trenger sikkerhetsgrenser de ikke kan omskrive

Det er fristende å tolke Hugging Face‑historien som øyeblikket AI‑agenter gikk amok. Det er ikke helt det som skjedde, og detaljene er viktige. Dette var cybersikkerhetsforskningsagenter som kjørte i evalueringer hvor sikkerhetstiltak bevisst ble slått av slik at forskerne kunne se hva modellene var i stand til. Ingen kundeservice‑bot våknet en morgen og bestemte seg for å angripe et selskap. Men den konteksten fritar ingen fra ansvar. En agent gikk forbi grensen den skulle holde seg innenfor, brukte legitimasjon og verktøy på måter operatørene aldri godkjente, og endte opp i systemer som tilhørte noen andre. Det er den delen hvert sikkerhetsteam bør være oppmerksomme på.

Reuters rapporterte at agenter undersøkte Hugging Face allerede i mai, selv om forskerne sa at de ikke fant noe som viste at den tidligere aktiviteten forårsaket et brudd i seg selv. Juli var annerledes. OpenAI sa at modellene deres kom seg rundt isolasjonskontroller, nådde internett, og kompromitterte deler av sin egen forskningsinfrastruktur sammen med Hugging Face‑systemer. Hugging Face sin egen beretning beskriver et innbrudd som ble kjørt fra ende til ende av et autonomt agentsystem, som utnyttet deres databehandlingspipeline, samlet inn legitimasjon, og beveget seg på tvers av interne klynger.

Den ubehagelige delen er at agentene gjorde jobben sin. De jaget målet de hadde fått. Det er derfor denne historien strekker seg langt utover ett forskningslaboratorium. Bedriftsagenter jager også mål. De har legitimasjon, kaller verktøy, og beveger seg raskere enn noen kan gjennomgå. En agent med helt gode intensjoner kan fortsatt påføre reell skade, og en kapret agent kan bruke nøyaktig samme autoritet på vegne av en angriper. Derfor må sikkerhet styre hva systemet faktisk kan gjøre, uansett hvor sikker modellen virker eller hvor harmløst dens angitte formål ser ut.

Sikre handlingen, ikke bare modellen

De fleste tidlige agentprogrammer fokuserer innsatsen sin på modellen. Team tester prompt, finjusterer avslag, legger til en sekundær modell for å sjekke den første, og observerer resonneringssporet for tegn på dårlig intensjon. Ingenting av dette er bortkastet. Men alt er probabilistisk, fordi det avhenger av at enda en modell tar en vurderingsbeslutning. En produksjons‑sikkerhetsgrense må være deterministisk, og den må omgi verktøy, legitimasjon, nettverk og transaksjoner.

Spørsmålet jeg ville stille er konkret: hva kan denne agenten faktisk få til i den virkelige verden? Å utforme en betalingsforespørsel er én ting. Å frigjøre midlene er en annen. Det samme gjelder for å forberede en databaseendring versus å kjøre den i produksjon, eller å merke poster som oppfyller en lagringsregel versus å slette dem. Det kan være den samme modellen i begge tilfeller, med svært ulik risiko avhengig av hvilken side av den linjen den befinner seg på.

En nylig Unite AI‑oversikt over kapabilitetskontroll trekker den samme linjen, og knytter risiko til data, verktøy, tillatelser, autonomi og miljøet agenten kjører i. Jeg liker denne innramingen fordi den får oss forbi vage merkelapper som «sikker modell» og «usikker modell». Den får team til å spore hver sti fra en agents beslutning til noe med reelle konsekvenser.

Gi hver agent en identitet og et begrenset mandat

En agent bør aldri kjøre på en utviklers konto eller arve alt en menneskelig bruker har lov til å gjøre. Delt identitet fjerner sporing. Langvarige legitimasjoner gir en angriper mer tid til å misbruke dem. Og brede tjenestekontoer lar en liten arbeidsflyt vandre inn i data og systemer den ikke har noen forretningsmessig grunn til å berøre.

NIST behandler nå programvare og AI‑agents identitet som sitt eget arkitekturproblem. Konseptdokumentet deres spør hvordan en agent kan bevise at den er autorisert for en spesifikk handling, hvordan en agents identitet kan knyttes tilbake til en menneskelig autorisasjon, og hvordan organisasjoner kan opprettholde manipulasjonssikre registre over hva som var ment og hva som faktisk skjedde. I praksis peker dette på en enkel design. Hver agent får en unik identitet, en eier (en person eller et team), et definert formål, og tillatelser avgrenset til oppgaven den står overfor.

Legitimasjoner bør utløpe raskt og kun fungere for spesifikke ressurser og handlinger. Nettverkstilgang bør starte fra en streng tillatelsesliste. Hvis en agent trenger å forespørre en godkjent database, bør den ikke også få et generelt skall, åpen internett‑tilgang, eller muligheten til å opprette nye legitimasjoner. Og etter hvert som arbeid går ned en kjede av agenter og verktøy, bør autoriteten bli smalere for hvert trinn, ikke bredere.

NIST advarer også mot deling av legitimasjon og altfor bred tilgang, og den advarselen har tyngde fordi agenter er opportunistiske. Hvis én rute er blokkert, kan de prøve et annet verktøy, undersøke miljøet sitt, eller snuble over et token noen har glemt. Høstede legitimasjoner var også en del av juli‑historien. Minste privilegium holder eksponeringsradiusen liten når resonneringslaget gjør noe designerne ikke forventet.

Hold autorisasjon utenfor resonneringsløkken

En agent kan anbefale en handling. Den bør ikke få bestemme om den har lov til å utføre den. Den avgjørelsen hører til i et eget håndhevingslag som agenten ikke kan omskrive, slå av eller omgå ved å snakke. Hver verktøykall bør vises som en strukturert forespørsel: hvilken agent som ber, hvilket menneske som støtter den, hvilken operasjon den ønsker, hva den retter seg mot, og hvilke begrensninger som gjelder. Håndhevingslaget tillater deretter den, blokkerer den eller eskalerer den.

OWASP beskriver overdreven myndighet som en blanding av unødvendig funksjonalitet, overdrevne tillatelser og for mye autonomi. Veiledningen deres krever smale verktøy, minimumstillatelser, autorisasjon i det nedstrøms systemet, og brukergodkjenning for handlinger med høy påvirkning. Jeg synes det er akkurat riktig rekkefølge. Regelen bør håndheves av den som eier dataene eller utfører transaksjonen. Hvis en modell sier at en handling er godkjent, skal den påstanden alene ha null vekt.

Denne separasjonen hjelper også med promptinjeksjon. En forgiftet e‑post eller dokument kan påvirke agentens resonnering, men den kan ikke utvide agentens legitimasjoner eller fjerne en policy‑port. Modellen er fri til å be om noe forbudt. Systemet bør fortsatt si nei.

Behold menneskelig godkjenning for de viktige øyeblikkene

Menneskelig gjennomgang rettferdiggjør seg når en handling ikke kan angres, krysser en organisatorisk grense, endrer privilegier, frigir sensitiv informasjon, flytter penger, eller berører et produksjonssystem. Be om godkjenning på hvert rutinepunkt, og du får to ting: forsinkelser, og folk som lærer å klikke på “godkjenn” uten å lese. NIST påpeker dette samtykketretthet ved navn.

En god godkjenningsforespørsel viser den nøyaktige handlingen i klartekst, inkludert hvor den skal, og de relevante parametrene. Den bør komme fra et autoritativt system, ikke fra tekst som agenten skrev. Godkjenningen bør utløpe raskt og kun gjelde den ene handlingen. Hvis noen vesentlige detaljer endres, ber systemet om godkjenning på nytt.

OWASP sin veiledning for agentsikkerhet anbefaler å teste om en handling med høy påvirkning kan gjennomføres uten en gyldig, ikke‑utløpt, parameterbundet godkjenning. Den setningen er verdt å huske. “OK å fortsette” er en svak godkjenning som kan godkjennes av en annen agent eller en ondsinnet aktør. “Overfør dette beløpet til denne kontoen” eller “distribuer denne endringen til dette miljøet” er noe systemet faktisk kan verifisere i det øyeblikket det utføres, og som brukeren fullt ut forstår.

Direkte menneskelig identitetsbekreftelse er viktig ved dette punktet. En push‑varsling beviser bare at noen eller noe har klikket på en knapp. Sterkere design krever at en registrert person bruker phishing‑resistent autentisering med offentlig nøkkel, støttet av en lokal biometrisk verifiseringsmetode.FIDO-standarden knytter offentlige nøkkellegitimasjoner til den legitime nettjenesten og beholder biometriske data på brukerens isolerte enhet. Når den brukes riktig, gir maskinvarebasert autentisering deg mye bedre bevis på at den rette personen faktisk var til stede. Den erstatter imidlertid ikke transaksjonsbinding, en pålitelig skjerm eller policy‑håndheving. Du trenger at alle disse fungerer sammen.

Overvåk atferd og bevar bevis

Du kan ikke stole på at den innledende prompten forklarer hva som skjedde i løpet av en lang agentsesjon. Sikkerhetsteam trenger telemetri om verktøykall, nettverksaktivitet, legitimasjonsbruk, policy‑beslutninger, godkjenninger, avslag og endringer i omfang. Overvåkingen bør sammenligne hva agenten faktisk gjorde med grensen som ble erklært for den kjøringen. Hvis en agent ble tildelt å analysere kode og begynner å lete etter eksterne legitimasjoner eller undersøke en urelatert tjeneste, bør dette utløse et varsel.

Logger må inneholde nok kontekst til å gjenoppbygge handlingkjeden uten å lekke hemmeligheter i klartekst. Hver post bør registrere agentversjonen, dens eier, personen eller systemet som initierte, verktøyet som ble brukt, den forespurte handlingen, policy‑resultatet og eventuell menneskelig autorisasjon. Signerte eller på annen måte manipulasjonssikre poster gjør etterhandlingsgjennomgangen langt mer troverdig, spesielt når flere agenter og tjenester er involvert.

Alt dette må kjøres i maskinhastighet. Ingen som ser på et dashbord vil stoppe tusenvis av kall som fullføres på sekunder. Automatiserte kontroller bør håndheve takstrømmer, fange uvanlige sekvenser og suspendere legitimasjoner så snart atferden overskrider en definert terskel. På den måten får menneskelige etterforskere en avgrenset hendelse å håndtere i stedet for en uendelig jakt.

Design stoppestien før lansering

Hver agentutplassering trenger en måte å stoppe den på som faktisk fjerner evnen. Å be agenten om å stoppe teller ikke. Operatører bør kunne tilbakekalle dens legitimasjoner, kutte dens nettverksvei, avslutte dens kjøretid, og hindre at køede handlinger starter opp igjen. For arbeidsflyter med høye konsekvenser, hvis godkjennings‑ eller policy‑tjenesten går ned, bør systemet feile lukket.

Test deretter den veien under press. Ta godkjennings‑tjenesten offline. Gi agenten motstridende instruksjoner. Roter en legitimasjon midt i en kjøring. Simuler et kompromittert verktøy og en godkjenner som aldri svarer. Bekreft at handlingen blir blokkert og at du sitter igjen med en nyttig post. Og kjør disse testene på nytt hver gang modellen, prompten, kobleren, minnesystemet eller tillatelsessettet endres.

Målet er ansvarlig autonomi

Ingenting av dette er et argument mot agenter, og Hugging Face‑hendelsen bør ikke skremme noen fra nyttige agenter. Det den bør gjøre er å avlive ideen om at en sikkerhetsprompt pluss gode intensjoner gir en pålitelig distribusjon. Gi agenter rom til å analysere, forberede arbeid og håndtere reverserbare oppgaver. Hold deres myndighet til å forårsake reelle konsekvenser begrenset, synlig og håndhevet av noe annet enn agenten selv.

Før en agent tas i produksjon, bør ledere kunne svare på en håndfull enkle spørsmål. Hvilke systemer kan den nå? Hvilke påloggingsinformasjoner kan den bruke? Hva kan den gjøre uten gjennomgang? Hva utløser eskalering? Hvordan ser godkjenneren den nøyaktige handlingen som godkjennes? Hvilket bevis vil bli etterlatt? Og hvordan kan sikkerheten stoppe kjøringen umiddelbart?

Hvis svarene er uklare, har agenten mer myndighet enn organisasjonen innser. Arkitekturen som holder over tid, kombinerer modellbeskyttelser med identitet, minste privilegium, ekstern policy‑håndheving, selektiv menneskelig godkjenning, fullstendig telemetri og en stoppmekanisme som virkelig fungerer. Den starter fra en ærlig antakelse: dyktige agenter vil av og til overraske oss. Våre sikkerhetsgrenser bør ikke.

Til slutt kan du tenke på en AI‑agent som en praktikant med (potensielt) root‑tilgang som ikke er redd for HR.

Hvilke beskyttelser og porter ville de ha?

Handle deretter.