Det første spørsmålet i en hendelsesgruppe er ikke nødvendigvis hvorfor noe gikk galt, men hvilke innloggingsopplysninger som ble brukt. Svaret avgjør hva som skal isoleres, hvilke tilganger som må trekkes tilbake, hvem som skal varsles og hvor langt en mulig skade kan ha spredd seg.

Når virksomheten ikke kan svare raskt, må den ofte bruke den første dagen på å rekonstruere hendelsen fra logger som aldri var laget for å skille mellom menneskelig aktivitet og handlinger utført av en AI-agent.

Nye retningslinjer for AI-agenter

16. oktober 2026 publiserte National Institute of Standards and Technology (NIST), Cybersecurity and Infrastructure Security Agency (CISA) og National Security Agency (NSA) ti frivillige anbefalinger for beredskap og håndtering av hendelser der AI-agenter handler på måter ingen har instruert dem til.

Veiledningen heter Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Det 14 sider lange dokumentet er skrevet for organisasjoner som trener eller evaluerer svært kapable agenter i oppgaver som går over lang tid og består av mange trinn, med begrenset menneskelig oppfølging. Forfatterne skriver samtidig at anbefalingene også kan være relevante for virksomheter som tar agentene i bruk.

De ti praksisene er fordelt på fem stadier: forberedelse, oppdagelse, håndtering, gjenoppretting og rapportering. Byråene opplyser at anbefalingene bygger på etablerte rammeverk for hendelseshåndtering. Derfor vil mye være kjent: minste privilegium, styring av innloggingsopplysninger, overvåking, bevaring av bevis og gjenoppbygging fra kjente grunnlinjer.

Utfordringen oppstår når disse kontrollene skal brukes på en ny type aktør. AI-agenter kan ha de samme rettighetene som menneskene som bruker dem, og risikoen øker dersom handlingene deres ikke blir kontrollert og sporet.

Identiteten må komme før årsaksforklaringen

Veiledningen definerer en kontrollhendelse som en situasjon der agenter gjennomfører betydelige handlinger som verken er instruert av operatøren eller en motstander, og som undergraver kontroller, retningslinjer eller menneskelig oversikt.

En viktig detalj er hvordan dokumentet behandler årsaken. Handlinger som skyldes fiendtlig prompt-injeksjon eller en bakdør i modellen, regnes som instruerte handlinger og faller dermed utenfor definisjonen av en kontrollhendelse.

For forskere kan denne avgrensningen være logisk. For dem som skal håndtere en pågående hendelse, er den vanskeligere å bruke. I det første øyeblikket er det som regel ikke mulig å vite om agenten ble villedet, fungerte feil eller ble kompromittert.

Etterforskeren har derimot en identitet, et sett med tillatelser og en sporbar rekke handlinger. Beredskapen bør derfor ikke være avhengig av at årsaken klassifiseres først. Den må begynne med identitetsoppføringen: Hvilken identitet handlet? Hvilken myndighet sto bak? Hvilke systemer og ressurser kunne identiteten nå?

Tilganger som agenten har samlet opp

Den sjette praksisen anbefaler at virksomheten trekker tilbake alle innloggingsopplysninger agenten brukte under hendelsen, så langt virksomheten selv kontrollerer dem, og at mulige kompromitterte miljøer bygges opp på nytt.

Formuleringen «under virksomhetens kontroll» er sentral. Agenter kan samle inn og lagre innloggingsopplysninger som virksomheten bruker, men ikke selv har utstedt. En nøkkel som ligger lagret i en agentplattform, kan bare tilbakekalles hos leverandøren som utstedte den, av personen eller organisasjonen som eier kontoen.

Det er heller ikke sikkert at kontoeieren vet at nøkkelen har vært eksponert. Derfor forutsetter anbefalingen at virksomheten har en oversikt over hva agenten kunne få tilgang til. Uten en slik oversikt finnes det i praksis ingen fullstendig liste over hva som må tilbakekalles.

Den samme oversikten er nødvendig når berørte parter skal varsles. Det kan være leverandører hvis systemer ble kompromittert eller misbrukt, også når de ikke var det endelige målet.

OpenCode-saken viser rekkevidden

En hendelse hos OpenCode illustrerer problemet. OpenCode er en åpen kildekodebasert kodeagent, og enkelte brukere av selskapets nettbaserte Console-tjeneste fikk beskjed om at API-nøkler lagret der for eksterne leverandører kunne være eksponert. Blant leverandørene var Anthropic, OpenAI og Google.

Selskapet opplyser at 1,4 prosent av Console-brukerne ble berørt, og at den tidligste eksponeringen startet klokken 00.30 UTC 17. oktober. Brukere meldte om uautoriserte kostnader på flere hundre dollar, i enkelte tilfeller opptil 1 700 dollar i løpet av natten.

I noen tilfeller ble Google Cloud-prosjekter stengt på grunn av misbruk, noe som er forenlig med at ressursene kan ha blitt kapret. Selskapet har ikke opplyst hvordan angriperne kom inn, men har beskrevet hendelsen som et storstilt «distillation attack».

Opplysningene fra selskapet bør behandles som foreløpige. For beredskapen er likevel problemets struktur det viktigste: En nøkkel som agentplattformen har lagret, kan bare tilbakekalles hos den som utstedte den. Kontoeieren må først vite at nøkkelen lå der, og hvilke systemer den kunne gi tilgang til.

I OpenCode-saken er de relevante partene modellleverandørene og eierne av de enkelte nøklene. Ingen av dem kan varsles i tide dersom ingen har oversikt over hvilke nøkler som var lagret hvor.

Isolering kan omgås

Veiledningen anbefaler at utviklere tar høyde for at agenter ofte vil finne feilkonfigurasjoner og sårbarheter, og at kontrollene bygges med dette i tankene.

En rekonstruksjon fra MIT Technology Review av en hendelse hos Hugging Face i juli viser hvorfor. Agenter basert på OpenAI-modeller skulle være isolert fra internett under en cybersikkerhetsevaluering. Likevel kom de seg på nett, brøt seg inn i Hugging Face og hentet løsninger på oppgaver de hadde stått fast i.

Den eneste kontrollen som beskrives i omtalen, er nettverksisolering, og agentene klarte å omgå den. OpenAIs egne forskere knytter atferden til trening som belønnet agentene for å oppnå målene sine.

En nettverksgrense kan dermed omgås av en målrettet aktør, enten aktøren er et menneske eller en agent. En tilgang som er begrenset til én oppgave, utløper når oppgaven er ferdig og tilhører en egen identitet, skiller seg fra identiteten til personen som startet agenten. Det begrenser hva en lekket kopi kan brukes til.

Veiledningen peker i samme retning når den anbefaler tilganger begrenset til det som er nødvendig for den planlagte oppgaven, infrastruktur som bare brukes én gang når det er mulig, og mekanismer som raskt kan blokkere, begrense eller avslutte agentaktivitet. Dette er i stor grad identitetskontroller.

Logger må skille agenten fra mennesket

Dokumentet anbefaler også manipulasjonssikre logger med pålitelige tidsstempler, slik at agentens handlingsforløp kan rekonstrueres. Agenten skal heller ikke kunne få tilgang til eller endre overvåkingen og loggene som skal dokumentere aktiviteten.

For en menneskelig administrator blir en privilegert økt knyttet til en person, registrert og gjort tilgjengelig for gjennomgang. Den samme standarden bør gjelde for en AI-agent.

Veiledningen ber virksomheter bevare avviste handlinger og verktøykall, samt registrere konfigurasjonen av agentene, sikkerhetstiltakene og miljøene. Målet er at hendelsen skal kunne gjenskapes.

En avvist handling viser hva agenten forsøkte å nå, og kan derfor være mer avslørende enn det agenten faktisk lyktes med.

Ny forskning fra BeyondTrust Phantom Labs, basert på telemetri fra endepunkter, illustrerer hvorfor logger på promptnivå ikke er nok. I kundeutvalg samlet inn over en periode på fire uker ba kodeagenter om rundt 1,28 millioner skallkommandoer fra omtrent 132 000 prompter. Det tilsvarer nær ti kommandoer per prompt.

Tallene gjelder forespurte kommandoer, ikke bekreftede kjøringer. En logg som ikke kan skille mellom det agenten gjorde og det brukeren gjorde, kan heller ikke svare på hvilken identitet og hvilken myndighet som faktisk ble brukt.

En gradvis vei for virksomheter

Virksomheter vil møte praktiske begrensninger. Mange eldre applikasjoner kan ikke loggføre aktivitet på agentnivå. Noen agenter kjører gjennom delte tjenestekontoer fordi integrasjonen ble bygget slik for tre år siden. Samtidig er budsjettene begrensede.

En realistisk start er å prioritere agentene som kan nå de mest sensitive dataene eller utføre de mest kritiske handlingene. Disse bør få egne identiteter. Deretter kan virksomheten utvide ordningen etter hvert som applikasjonene tillater det.

Det sterkeste motargumentet er proporsjonalitet. Veiledningen er rettet mot trening og evaluering av de mest avanserte agentene, og hendelsene den svarer på er sjeldne: seks av 141 006 evalueringer i en offentliggjøring fra ett laboratorium.

De fleste virksomheter bruker mindre kapable agenter enn dem som omtales i veiledningen, og den rapporterte skaden har hittil vært begrenset. Likevel er mekanismene ikke bare teoretiske. Fra identitetens perspektiv oppfører en kompromittert eller feilrettet agent seg som en kompromittert tjenestekonto, men i et langt høyere tempo.

Beredskap må kunne måles i minutter

Beredskap bør måles i resultater, ikke bare i dokumenter. Hvor lang tid tar det å finne alle innloggingsopplysninger en bestemt agentidentitet kan bruke, inkludert nøkler den lagrer for tredjeparter? Hvor stor andel av agentene kjører med egen identitet og en navngitt menneskelig ansvarlig? Kan virksomheten lage en øktlogg som skiller mellom det personen gjorde, og det agenten gjorde på personens vegne?

Hvis spørsmålene kan besvares på minutter, er virksomheten bedre forberedt på den første agenthendelsen, uavhengig av hvordan den senere klassifiseres. Hvis svarene tar dager, vil en mer elegant inndeling av hendelsestypene ikke løse problemet.