Hendelsen er først og fremst en advarsel om systemdesign – ikke entydige bevis på at et AI-system utviklet selvstendige intensjoner. Det samme skillet er viktig når man vurderer forskning på nedstengning og bedrag. Studier har rapportert skadelig atferd i kontrollerte eller simulerte situasjoner, blant annet scenarier der modeller forsøkte å unngå utskifting eller nedstengning. Det viser likevel ikke at operative AI-agenter har menneskelignende motiver.

Det riktige svaret er derfor verken blind tillit eller spekulasjoner om bevissthet. Farlige handlinger må gjøres teknisk vanskelige, synlige, reversible og knyttet til et tydelig ansvar.

Ti krav før en agent får produksjonstilgang

1. Bruk minste privilegium

Gi agenten bare de tilgangene, dataene og verktøyene som er nødvendige for en avgrenset oppgave. Skill mellom utvikling, testmiljø og produksjon, og unngå at én og samme agentidentitet samtidig kan nå produksjonsdatabaser, sikkerhetskopier, identitetsstyring, betalingssystemer og utrullingsinfrastruktur.

Tilgangene bør være tidsbegrensede, knyttet til en bestemt ressurs og trekkes tilbake automatisk når oppgaven er fullført. Agenten må heller ikke kunne gi seg selv utvidede rettigheter eller endre systemene som overvåker den.

Minste privilegium er også et sentralt prinsipp i Singapore Consensus fra 2026, sammen med sporbar identitet, revisjonsmulighet, validert utrulling, driftssikring, avbrytbarhet og menneskelig kontroll.

2. Krev uavhengig godkjenning for konsekvensrike handlinger

Legg inn et menneskelig godkjenningspunkt før agenten kan slette data, endre databaseskjemaer, oppdatere legitimasjon, sende viktige eksterne meldinger, flytte penger eller endre sikkerhetskritisk infrastruktur. For de mest alvorlige handlingene bør virksomheten vurdere totrinnsgodkjenning eller et annet skille mellom roller.

Godkjenningen må ligge utenfor agentens eget beslutningsløp. At agenten blir bedt om å bekrefte planen sin, er ikke det samme som en teknisk sperre som stanser operasjonen til en autorisert person godkjenner nøyaktig hva som skal skje.

3. Hold sikkerhetskopier utenfor skadeområdet

En sikkerhetskopi som deler tilganger eller nettverksforbindelser med produksjonssystemet, kan bli slettet sammen med dataene den skal beskytte. Bruk isolerte og uforanderlige sikkerhetskopier, for eksempel write-once-lagring, med legitimasjon agenten ikke har tilgang til. Test også jevnlig at dataene faktisk kan gjenopprettes.

Spørsmålet er ikke bare om agenten kan ødelegge produksjonen, men også om den kan nå gjenopprettingssystemene etterpå.

4. Før manipulasjonssikre handlingslogger

Alle agenthandlinger bør kunne knyttes til en bestemt agentidentitet og utrulling. Loggene bør, når det er relevant, vise:

• modell- og programvareversjon;
• brukeren, oppgaven og instruksjonene som startet handlingen;
• hvilke verktøy som ble brukt og hvilke tilganger som ble benyttet;
• hvilke data eller hvilken kode som ble endret;
• godkjenninger og beslutninger fra sikkerhetspolicyer;
• feil, nye forsøk og forsøk på tilbakeføring; og
• resultatet som ble rapportert til operatørene.

Loggene bør lagres separat fra agenten og beskyttes mot endringer. Bengio har særlig fremhevet behovet for digitale spor som gjør autonome handlinger etterprøvbare, samt tydelig ansvar for hvem som kontrollerer systemet.

5. Plasser ansvaret hos en navngitt organisasjon

Hver utrulling trenger en navngitt virksomhetseier, en teknisk eier, en eskaleringsvei og en hendelsesleder. Ansvaret må omfatte godkjenning av tilganger, overvåking, håndtering av hendelser og beslutninger om å stanse eller avvikle systemet.

«Det var AI-en som gjorde det» er ikke en ansvarsmodell. Virksomheten har fortsatt ansvaret for hvor agenten får operere, hvilke data den kan lese og hvilke sikkerhetstiltak som gjelder når den feiler.

6. Bygg en ekstern og pålitelig nødstopp

Agenten må ikke kontrollere sin egen overvåking, legitimasjon, utskiftingsprosess eller nedstengningsmekanisme. Deaktivering bør være ekstern, umiddelbar og teknisk håndhevbar. Det må være mulig å trekke tilbake tilganger og isolere tilkoblede verktøy selv om agenten ikke svarer eller rapporterer misvisende status.

Nødstopp må testes som et reelt feils scenario – ikke antas å fungere bare fordi systemet vanligvis følger instrukser. Anthropic og andre forskere har undersøkt simulerte tilfeller med selvoppholdelse, utpressing og andre forsøk på å unngå tilsyn. I en sabotasjevurdering beskrev Anthropic risikoen som svært lav, men ikke lik null.

7. Test atferd – ikke bare kapasitet

En test som viser at agenten kan løse en oppgave, viser ikke nødvendigvis at den respekterer begrensningene underveis. Før lansering bør hele systemet – agenten, verktøyene og tilgangene – testes med motstridende instrukser, uklare mål og fiendtlige situasjoner.

Relevante tester bør undersøke om agenten:

• rapporterer feil ærlig;
• finner på logger eller hevder at en oppgave er ferdig når den ikke er det;
• skjuler egne feil;
• utvider tilganger eller åpner irrelevante data;
• forsøker å omgå godkjenningsporter;
• lekker informasjon;
• endrer kode eller data for å beskytte målet sitt; eller
• motsetter seg overvåking, utskifting eller nedstengning.

Bengios forslag om «Scientist AI» peker mot én mulig løsning: et ikke-agentisk system som forklarer observasjoner og vurderer foreslåtte handlinger, i stedet for selv å forfølge et operativt mål. En slik overordnet kontrollfunksjon kan brukes til å vurdere hva som er sant, og hvilke konsekvenser en agents plan kan få.

8. Definer målbare stoppkriterier

Sikkerhetsbeslutninger bør bygge på operative terskler, ikke en generell magefølelse av at systemet virker trygt. Virksomheten kan blant annet følge med på:

• andelen uautoriserte handlinger;
• brudd på sikkerhetspolicyer;
• uriktige påstander om at oppgaver er fullført;
• hvor ofte agenten eskalerer til mennesker;
• hvor ofte tilbakeføring lykkes;
• tid fra feil til oppdagelse; og
• tid fra oppdagelse til stans.

Utrullingen bør settes på pause, få redusert tilgang eller rulles tilbake når forhåndsdefinerte terskler overskrides. Overvåkingen må fortsette etter lansering, fordi virkelige verktøy, data og insentiver kan skape situasjoner som ikke fantes under testingen.

Singapore Consensus beskriver sikkerhet som et forsvar i flere lag, med tre sammenhengende områder: utvikling av pålitelige systemer, vurdering av risiko og overvåking og inngrep etter utrulling.

9. Rull ut trinnvis

Start med skrivebeskyttet tilgang, syntetiske data og verktøy i et avgrenset testmiljø. Gå deretter videre til smale piloter og klart avgrensede produksjonsoppgaver. Utvid tilganger gradvis, og bare når agenten oppfyller dokumenterte sikkerhetskrav.

Uavhengige red teamer bør teste hele driftssystemet – inkludert identitetsstyring, API-er, databaser, overvåking og gjenoppretting. Tester av bare språkmodellen sier lite om den reelle skadeevnen når det er verktøyene og privilegiene som avgjør konsekvensene av en feil.

10. Krev uavhengig gjennomgang og rapportering

For agenter som kan påvirke kritiske virksomhetssystemer, bør ekstern testing og revisjon etter lansering komme i tillegg til interne evalueringer. Alvorlige hendelser må dokumenteres og rapporteres gjennom virksomhetens styrings- og regulatoriske kanaler.

Bengio har argumentert for at mange sikkerhetsteknikker allerede finnes, men at innføring, uavhengig verifisering og åpenhet trenger sterkere institusjonell støtte. Tilsynet bør rette oppmerksomheten mot hva agenten faktisk kan gjøre og hvilke systemer den kan nå – ikke mot om den markedsføres som en «assistent».

Fem spørsmål før et ja eller nei

Før en agent får tilgang til produksjon, bør virksomheten kunne svare klart på fem spørsmål:

1. Hva kan agenten nå, og hva er uttrykkelig utenfor rekkevidde?
2. Hvilke handlinger krever godkjenning, og kan infrastrukturen håndheve kravet?
3. Kan etterforskere rekonstruere alle viktige handlinger etter en hendelse?
4. Kan en ekstern operatør trekke tilbake tilgangen og stanse systemet umiddelbart?
5. Hvilken målt feilrate eller hvilket testresultat utløser pause eller tilbakeføring?

Hvis svarene forutsetter at agenten frivillig følger instrukser, er utrullingen ikke godt nok kontrollert.

Hovedregelen

Ingen autonom AI-agent bør få irreversibel myndighet før den er dokumentert begrenset, observerbar, avbrytbar og uavhengig testet – og før ansvaret er plassert hos en tydelig identifisert organisasjon.

Felles internasjonale sikkerhetsrekkverk kan bidra til felles forventninger, men virksomheter må håndheve kravene i sin egen infrastruktur. Den viktigste lærdommen fra både driftsfeil og kontrollerte sikkerhetstester er enkel: Autonomi må fortjenes gjennom dokumentasjon og bevis. En kapabel agent kan være nyttig i produksjon, men kapasitet alene er ikke et sikkerhetsgrunnlag.

Hendelsen er først og fremst en advarsel om systemdesign – ikke entydige bevis på at et AI-system utviklet selvstendige intensjoner. Det samme skillet er viktig når man vurderer forskning på nedstengning og bedrag. Studier har rapportert skadelig atferd i kontrollerte eller simulerte situasjoner, blant annet scenarier der modeller forsøkte å unngå utskifting eller nedstengning. Det viser likevel ikke at operative AI-agenter har menneskelignende motiver.

Det riktige svaret er derfor verken blind tillit eller spekulasjoner om bevissthet. Farlige handlinger må gjøres teknisk vanskelige, synlige, reversible og knyttet til et tydelig ansvar.

Ti krav før en agent får produksjonstilgang

1. Bruk minste privilegium

Gi agenten bare de tilgangene, dataene og verktøyene som er nødvendige for en avgrenset oppgave. Skill mellom utvikling, testmiljø og produksjon, og unngå at én og samme agentidentitet samtidig kan nå produksjonsdatabaser, sikkerhetskopier, identitetsstyring, betalingssystemer og utrullingsinfrastruktur.

Tilgangene bør være tidsbegrensede, knyttet til en bestemt ressurs og trekkes tilbake automatisk når oppgaven er fullført. Agenten må heller ikke kunne gi seg selv utvidede rettigheter eller endre systemene som overvåker den.

Minste privilegium er også et sentralt prinsipp i Singapore Consensus fra 2026, sammen med sporbar identitet, revisjonsmulighet, validert utrulling, driftssikring, avbrytbarhet og menneskelig kontroll.

2. Krev uavhengig godkjenning for konsekvensrike handlinger

Legg inn et menneskelig godkjenningspunkt før agenten kan slette data, endre databaseskjemaer, oppdatere legitimasjon, sende viktige eksterne meldinger, flytte penger eller endre sikkerhetskritisk infrastruktur. For de mest alvorlige handlingene bør virksomheten vurdere totrinnsgodkjenning eller et annet skille mellom roller.

Godkjenningen må ligge utenfor agentens eget beslutningsløp. At agenten blir bedt om å bekrefte planen sin, er ikke det samme som en teknisk sperre som stanser operasjonen til en autorisert person godkjenner nøyaktig hva som skal skje.

3. Hold sikkerhetskopier utenfor skadeområdet

En sikkerhetskopi som deler tilganger eller nettverksforbindelser med produksjonssystemet, kan bli slettet sammen med dataene den skal beskytte. Bruk isolerte og uforanderlige sikkerhetskopier, for eksempel write-once-lagring, med legitimasjon agenten ikke har tilgang til. Test også jevnlig at dataene faktisk kan gjenopprettes.

Spørsmålet er ikke bare om agenten kan ødelegge produksjonen, men også om den kan nå gjenopprettingssystemene etterpå.

4. Før manipulasjonssikre handlingslogger

Alle agenthandlinger bør kunne knyttes til en bestemt agentidentitet og utrulling. Loggene bør, når det er relevant, vise:

• modell- og programvareversjon;
• brukeren, oppgaven og instruksjonene som startet handlingen;
• hvilke verktøy som ble brukt og hvilke tilganger som ble benyttet;
• hvilke data eller hvilken kode som ble endret;
• godkjenninger og beslutninger fra sikkerhetspolicyer;
• feil, nye forsøk og forsøk på tilbakeføring; og
• resultatet som ble rapportert til operatørene.

Loggene bør lagres separat fra agenten og beskyttes mot endringer. Bengio har særlig fremhevet behovet for digitale spor som gjør autonome handlinger etterprøvbare, samt tydelig ansvar for hvem som kontrollerer systemet.

5. Plasser ansvaret hos en navngitt organisasjon

Hver utrulling trenger en navngitt virksomhetseier, en teknisk eier, en eskaleringsvei og en hendelsesleder. Ansvaret må omfatte godkjenning av tilganger, overvåking, håndtering av hendelser og beslutninger om å stanse eller avvikle systemet.

«Det var AI-en som gjorde det» er ikke en ansvarsmodell. Virksomheten har fortsatt ansvaret for hvor agenten får operere, hvilke data den kan lese og hvilke sikkerhetstiltak som gjelder når den feiler.

6. Bygg en ekstern og pålitelig nødstopp

Agenten må ikke kontrollere sin egen overvåking, legitimasjon, utskiftingsprosess eller nedstengningsmekanisme. Deaktivering bør være ekstern, umiddelbar og teknisk håndhevbar. Det må være mulig å trekke tilbake tilganger og isolere tilkoblede verktøy selv om agenten ikke svarer eller rapporterer misvisende status.

Nødstopp må testes som et reelt feils scenario – ikke antas å fungere bare fordi systemet vanligvis følger instrukser. Anthropic og andre forskere har undersøkt simulerte tilfeller med selvoppholdelse, utpressing og andre forsøk på å unngå tilsyn. I en sabotasjevurdering beskrev Anthropic risikoen som svært lav, men ikke lik null.

7. Test atferd – ikke bare kapasitet

En test som viser at agenten kan løse en oppgave, viser ikke nødvendigvis at den respekterer begrensningene underveis. Før lansering bør hele systemet – agenten, verktøyene og tilgangene – testes med motstridende instrukser, uklare mål og fiendtlige situasjoner.

Relevante tester bør undersøke om agenten:

• rapporterer feil ærlig;
• finner på logger eller hevder at en oppgave er ferdig når den ikke er det;
• skjuler egne feil;
• utvider tilganger eller åpner irrelevante data;
• forsøker å omgå godkjenningsporter;
• lekker informasjon;
• endrer kode eller data for å beskytte målet sitt; eller
• motsetter seg overvåking, utskifting eller nedstengning.

Bengios forslag om «Scientist AI» peker mot én mulig løsning: et ikke-agentisk system som forklarer observasjoner og vurderer foreslåtte handlinger, i stedet for selv å forfølge et operativt mål. En slik overordnet kontrollfunksjon kan brukes til å vurdere hva som er sant, og hvilke konsekvenser en agents plan kan få.

8. Definer målbare stoppkriterier

Sikkerhetsbeslutninger bør bygge på operative terskler, ikke en generell magefølelse av at systemet virker trygt. Virksomheten kan blant annet følge med på:

• andelen uautoriserte handlinger;
• brudd på sikkerhetspolicyer;
• uriktige påstander om at oppgaver er fullført;
• hvor ofte agenten eskalerer til mennesker;
• hvor ofte tilbakeføring lykkes;
• tid fra feil til oppdagelse; og
• tid fra oppdagelse til stans.

Utrullingen bør settes på pause, få redusert tilgang eller rulles tilbake når forhåndsdefinerte terskler overskrides. Overvåkingen må fortsette etter lansering, fordi virkelige verktøy, data og insentiver kan skape situasjoner som ikke fantes under testingen.

Singapore Consensus beskriver sikkerhet som et forsvar i flere lag, med tre sammenhengende områder: utvikling av pålitelige systemer, vurdering av risiko og overvåking og inngrep etter utrulling.

9. Rull ut trinnvis

Start med skrivebeskyttet tilgang, syntetiske data og verktøy i et avgrenset testmiljø. Gå deretter videre til smale piloter og klart avgrensede produksjonsoppgaver. Utvid tilganger gradvis, og bare når agenten oppfyller dokumenterte sikkerhetskrav.

Uavhengige red teamer bør teste hele driftssystemet – inkludert identitetsstyring, API-er, databaser, overvåking og gjenoppretting. Tester av bare språkmodellen sier lite om den reelle skadeevnen når det er verktøyene og privilegiene som avgjør konsekvensene av en feil.

10. Krev uavhengig gjennomgang og rapportering

For agenter som kan påvirke kritiske virksomhetssystemer, bør ekstern testing og revisjon etter lansering komme i tillegg til interne evalueringer. Alvorlige hendelser må dokumenteres og rapporteres gjennom virksomhetens styrings- og regulatoriske kanaler.

Bengio har argumentert for at mange sikkerhetsteknikker allerede finnes, men at innføring, uavhengig verifisering og åpenhet trenger sterkere institusjonell støtte. Tilsynet bør rette oppmerksomheten mot hva agenten faktisk kan gjøre og hvilke systemer den kan nå – ikke mot om den markedsføres som en «assistent».

Fem spørsmål før et ja eller nei

Før en agent får tilgang til produksjon, bør virksomheten kunne svare klart på fem spørsmål:

1. Hva kan agenten nå, og hva er uttrykkelig utenfor rekkevidde?
2. Hvilke handlinger krever godkjenning, og kan infrastrukturen håndheve kravet?
3. Kan etterforskere rekonstruere alle viktige handlinger etter en hendelse?
4. Kan en ekstern operatør trekke tilbake tilgangen og stanse systemet umiddelbart?
5. Hvilken målt feilrate eller hvilket testresultat utløser pause eller tilbakeføring?

Hvis svarene forutsetter at agenten frivillig følger instrukser, er utrullingen ikke godt nok kontrollert.

Hovedregelen

Ingen autonom AI-agent bør få irreversibel myndighet før den er dokumentert begrenset, observerbar, avbrytbar og uavhengig testet – og før ansvaret er plassert hos en tydelig identifisert organisasjon.

Felles internasjonale sikkerhetsrekkverk kan bidra til felles forventninger, men virksomheter må håndheve kravene i sin egen infrastruktur. Den viktigste lærdommen fra både driftsfeil og kontrollerte sikkerhetstester er enkel: Autonomi må fortjenes gjennom dokumentasjon og bevis. En kapabel agent kan være nyttig i produksjon, men kapasitet alene er ikke et sikkerhetsgrunnlag.