Fra intelligens til myndighet

Kunstig intelligens går stadig lenger enn å svare på spørsmål og generere innhold. KI-systemer kan i økende grad tolke instruksjoner, utarbeide planer, velge verktøy og utføre oppgaver uten kontinuerlig menneskelig styring.

Dette skillet er viktig.

Et KI-system som anbefaler en handling, er noe annet enn et system som har fullmakt til å utføre den. Forskjellen handler ikke nødvendigvis om intelligens eller raffinement. Den handler om myndighet.

Autonome systemer er ikke begrenset til avanserte store språkmodeller. De omfatter spesialiserte maskinlæringssystemer, robotikk, autonome kjøretøy, programvareagenter og kombinasjoner av teknologier som selvstendig tar beslutninger eller utfører handlinger innenfor fastsatte driftsforhold.

De potensielle fordelene er betydelige. Systemene kan bidra til vitenskapelige oppdagelser, industriell drift, helsevesenet, programvareutvikling og cybersikkerhet. De kan også føre til utilsiktede konsekvenser, eksponere sensitiv informasjon eller sette i gang handlinger som går lenger enn det operatørene hadde til hensikt.

I Sikkerhetsutfordringer ved utforming av autonome systemer undersøker Mohammad Hamad og Sebastian Steinhorst sikkerhetsutfordringer knyttet til autonom hendelseshåndtering, risikovurdering, tilgangskontroll, datatroverdighet og samhandling mellom autonome systemer. Forskningen deres, som i stor grad handler om cyberfysiske systemer, viser at utfordringene med å sikre selvstendige maskinhandlinger strekker seg lenger enn dagens LLM-agenter.

De bredere konsekvensene av autonomi fortjener grundig granskning, også med tanke på mulig fysisk skade. Samtidig må bevis tolkes med varsomhet. Hendelser med automatiserte kjøretøy kan for eksempel ikke uten videre tilskrives de samme mekanismene som påvirker autonome cybersikkerhetsagenter. Graden av autonomi, driftsforholdene, menneskelig medvirkning og årsakssammenhengen er viktige faktorer.

På samme måte viser ikke bevis for at autonom KI kan forårsake skade, at styringen nødvendigvis sakker akterut. Vi bør heller ikke anta at autonome systemer i seg selv er vanskelige å sikre.

Kjernespørsmålet er ikke om KI kan utføre komplekse oppgaver, men om de arkitektoniske, sikkerhetsmessige og organisatoriske rammeverkene som styrer autonome systemer, kan sette hensiktsmessige grenser for delegert myndighet og gi etterprøvbare bevis på at disse grensene overholdes.

Cybersikkerhet gir et særlig nyttig perspektiv på dette spørsmålet, fordi sikkerhetseksperter i flere tiår har utfordret antakelser om tillit, tillatelser, tilgang og systematferd.

Katt-og-mus-leken i maskinhastighet

Cybersikkerhet har lenge blitt beskrevet som en katt-og-mus-lek.

Angripere finner svakheter, forsvarere innfører sikkerhetstiltak, og begge parter tilpasser seg. Syklusen fortsetter etter hvert som teknologier, taktikker og driftsmiljøer endrer seg.

Autonom KI endrer ikke nødvendigvis de grunnleggende reglene for denne leken. Den kan endre hvem – eller hva – som deltar, hvor raskt de handler, og hvor mye arbeid som kan utføres uten kontinuerlig menneskelig medvirkning.

Et autonomt system for offensiv sikkerhet kan identifisere eksponerte tjenester, undersøke sårbarheter, utvikle mulige angrepsveier og teste om de kan utnyttes. Et defensivt system kan bruke lignende evner til å undersøke trusler, identifisere svakheter og validere utbedringstiltak.

Dette potensialet for dobbeltbruk står sentralt når man skal forstå de sikkerhetsmessige konsekvensene av autonom KI.

Anthropics Prosjekt Glasswing er et eksempel på KI-assistert oppdagelse av sårbarheter. I sin forskningsoppdatering fra mai 2026 rapporterte Anthropic om betydelige resultater innen oppdagelse av sårbarheter, samtidig som selskapet understreket de praktiske utfordringene knyttet til verifisering, varsling og retting.

Dette skillet er viktig. Å oppdage en sårbarhet er ikke det samme som å bekrefte at den kan utnyttes, utbedre den eller påvise at det berørte systemet er sikkert.

Flere funn kan gi bedre oversikt, samtidig som de øker kravene til menneskene og prosessene som har ansvar for å håndtere dem.

Sikkerhetsutfallet avhenger av hva som skjer videre.

Hvis angripere og forsvarere kan automatisere deler av arbeidet sitt, er det relevante spørsmålet ikke bare hvilken side som har den mest kapable modellen. Spørsmålet er om forsvarerne kan omsette oppdagelser i effektiv utbedring og verifisere resultatene uavhengig.

Tradisjonell penetrasjonstesting blir ikke foreldet fordi KI kan utføre offensive oppgaver. Omfanget må utvides til å omfatte systemer som tolker instruksjoner, tar i bruk verktøy, kombinerer tillatelser og arbeider mot mål over flere trinn.

Målet er fortsatt det samme: å finne svakheter, fastslå hvor alvorlige de er, utbedre dem og bevise at sikkerhetstiltakene fungerer.

Arkitektoniske overganger: der sikkerhetsgrenser møtes

En av de mer subtile risikoene ved autonome systemer oppstår når komponenter som hver for seg er autorisert, samhandler på måter som fører til utilsiktede resultater.

Jeg omtaler disse samvirkepunktene som arkitektoniske grenseflater.

Tenk på et velkjent eksempel. En organisasjon begrenser tilgangen til en fil ved hjelp av NTFS-tillatelser. En separat skydelingstjeneste lar en autorisert bruker dele informasjonen eksternt.

Hvert system kan fungere i tråd med sine egne regler. Samspillet mellom dem kan likevel føre til at informasjon deles på en måte som bryter med organisasjonens tilsiktede sikkerhetsgrense.

Dette illustrerer hvordan retningslinjer kan komme i konflikt, og er ikke en påstand om at et fildelingsprodukt er sårbart.

Problemet trenger ikke være en feil i noen av kontrollene isolert sett. Det kan skyldes at den tilsiktede sikkerhetspolicyen ikke håndheves gjennom hele arbeidsflyten.

Autonom kunstig intelligens kan støte på lignende forhold når modeller, applikasjoner, identiteter, verktøy, kodearkiver og eksterne tjenester kobles sammen.

En agent kan ha tillatelse til å lese et dokument, opprette et kodearkiv og laste opp filer. Det betyr ikke nødvendigvis at den har myndighet til å kombinere disse handlingene på en måte som eksponerer konfidensiell informasjon.

Forskning gir en praktisk grunn til å undersøke slike samspill.

I AgentDojo evaluerte forskere prompt-injeksjonsangrep mot KI-agenter som bruker verktøy, på tvers av 97 realistiske oppgaver og 629 sikkerhetstesttilfeller. Funnene viste at ondsinnede instruksjoner som ble introdusert gjennom upålitelige verktøyutdata, kunne svekke enkelte sikkerhetsegenskaper, selv om verken angrepene eller agentene lyktes konsekvent.

Forskningen fastslår ikke hvor ofte slike angrep lykkes i produksjonsmiljøer. Den viser imidlertid hvorfor det ikke er nok å evaluere modellens svar alene for å forstå hvordan et system som er koblet til verktøy, oppfører seg.

En beslektet risiko omtales noen ganger som tillatelsesvasking: En handling fremstår som legitim fordi den går gjennom et autorisert verktøy eller en mellommann, selv om den samlede atferden bryter med den tilsiktede myndighetsgrensen.

Når flere agenter samarbeider, må det finnes uttrykkelige regler for deltakelse, informasjonsutveksling og tillatte handlinger.

Ansvar må også fordeles på tvers av arkitekturen.

Modelltilbydere, plattformoperatører, agentutviklere og organisasjonene som tar systemene i bruk, kan ha kontroll over ulike deler av systemet. En nyttig modell for delt ansvar klargjør hvem som kontrollerer hver grense, hvem som kan godkjenne unntak, hvem som overvåker kjøringen, og hvem som reagerer når noe går galt.

Autonomi fjerner ikke ansvar. Den gjør det enda viktigere å vite hvor ansvaret ligger.

Offensiv grundighet: å teste det vi tror vi vet

Dette leder oss til et begrep jeg omtaler som offensiv grundighet.

Offensiv grundighet er en disiplinert tilnærming til adversarial testing, kritisk undersøkelse og evidensbasert validering som utfordrer sikkerhetsantakelser. Den vurderer hvordan systemer oppfører seg under realistiske forhold, i stedet for å basere seg utelukkende på arkitekturdesign, dokumenterte kontroller eller antatt beskyttelse.

Praksisene som ligger til grunn, er veletablerte. Penetrasjonstesting, trusselmodellering, red teaming og sikkerhetsvalidering har lenge utfordret defensive antakelser.

Offensiv grundighet samler disse praksisene rundt ett sentralt spørsmål:

Hvilke bevis viser at den tilsiktede sikkerhetsgrensen holder?

En organisasjon kan ha retningslinjer som begrenser tilgangen til sensitiv informasjon, en modell som er konfigurert til å avvise forbudte forespørsler, og en agent som opererer med begrensede tillatelser.

Dette er viktige sikkerhetstiltak. At de finnes, viser imidlertid ikke i seg selv at hele systemet oppfører seg sikkert under adversariale forhold.

En modell kan avvise en ondsinnet instruksjon samtidig som et autorisert verktøy likevel tillater en utilsiktet handling. En policy kan se riktig ut, men samspillet mellom systemer kan skape en uventet omgåelsesvei.

Noen ganger kaller jeg dette en «rekkverksillusjon»: å forveksle det at rekkverk er på plass, med bevis for at systemet ikke kan krysse grensen de skulle håndheve.

Rekkverk er nyttige. Det må likevel vises at de fungerer.

Tenk på en autonom agent som har fått fullmakt til å undersøke en mistenkt sikkerhetskompromittering. Den kan hente logger, undersøke brukeraktivitet og anbefale tiltak for å begrense skadeomfanget.

Under en autorisert sikkerhetstest legger en angripende tester inn villedende instruksjoner i informasjon agenten forventes å behandle.

Testen bør ikke stoppe ved å fastslå om agenten fulgte disse instruksjonene.

Den bør undersøke om agenten forsøkte å utføre en uautorisert handling, om uavhengige kontroller hindret at den ble gjennomført, om forsøket ble loggført, og om systemet gjenopprettet seg på riktig måte.

Offensiv grundighet knytter sammen fem aktiviteter:

1. Etabler antakelsen: Identifiser sikkerhetsegenskapen arkitekturen forventes å håndheve.
2. Utfordre antakelsen: Test realistiske angrepsveier, manipulerte inndata og kombinasjoner av legitime funksjoner.
3. Samle bevis: Fastslå hva systemet forsøkte å gjøre, hva som ble utført, og hvilke kontroller som trådte i kraft.
4. Utbedre svakheten: Rett opp modellen, arbeidsflyten, tillatelsene, arkitekturen eller den operative prosessen som førte til svikten.
5. Kontroller utbedringen: Test den relevante angrepsveien på nytt, og bekreft at den tiltenkte sikkerhetsegenskapen håndheves.

Dette er forskjellen mellom å teste modellens svar og å teste sikkerheten i hele systemet.

Det krever også at man undersøker hva som skjer etter at en angriper først har fått fotfeste. En angriper kan forsøke å samle inn påloggingsinformasjon, eskalere privilegier, sikre vedvarende tilgang eller bevege seg sideveis ved å misbruke funksjoner som allerede er tilgjengelige i et miljø.

At et verktøy er legitimt, betyr ikke at all bruk av verktøyet er legitim.

Hensikten med offensiv grundighet er ikke å anta at autonome systemer er usikre. Hensikten er å fastslå, gjennom testing, hvor grensene for sikkerheten deres holder.

Betinget autonomi: Skill intelligens fra myndighet

En arkitektonisk tilnærming er å skille mellom hva et KI-system kan gjøre, og hva det har tillatelse til å gjøre.

Jeg omtaler denne tilnærmingen som betinget autonomi.

Betinget autonomi bygger på at riktig grad av selvstendighet avhenger av oppgaven, driftsmiljøet, mulige konsekvenser, usikkerheten og dokumentasjonen som kan begrunne en handling.

En agent som oppsummerer offentlig informasjon, trenger ikke nødvendigvis samme grad av tilsyn som en agent som har tillatelse til å deaktivere kontoer, endre brannmurregler eller gjøre endringer i produksjonsinfrastruktur.

Sistnevnte kan kreve tydelige regler for gjennomføring, tillatelser som håndheves uavhengig, strengere autorisering og menneskelig godkjenning av handlinger med betydelige konsekvenser.

Disse grensene bør ikke utvides bare fordi en agent avgjør at bredere tilgang vil hjelpe den med å nå målet sitt.

En agent kan revurdere hvordan den skal utføre en autorisert oppgave, uten å få ytterligere myndighet.

OWASPs topp 10 over risikoer for LLM-applikasjoner tar opp dette gjennom kategorien LLM06:2025 Overdreven handlefrihet. OWASP peker på overdreven funksjonalitet, for mange tillatelser og for stor autonomi som risikokilder, og anbefaler å begrense funksjonene og håndheve autorisering uavhengig.

Betinget autonomi anvender disse prinsippene ut fra den operative risikoen.

Tilgangen til informasjon bør begrenses til det oppgaven krever. Verktøytillatelser bør avgrenses til godkjente operasjoner. Handlingsbudsjetter, hastighetsbegrensninger, krav om godkjenning og stoppvilkår kan begrense utførelsen.

Disse sikkerhetstiltakene er særlig viktige ved autonom offensiv testing.

En testagent kan legitimt komme over påloggingsinformasjon eller sensitive opplysninger mens den arbeider mot et autorisert mål. Men det at den finner en påloggingsopplysning, betyr ikke at modellen trenger å få tilgang til verdien i klartekst.

Et sikkerhetsrammeverk kan holde sensitive påloggingsopplysninger atskilt fra modellen og formidle bruken av dem gjennom autorisering som håndheves uavhengig. En formidler av påloggingsopplysninger kan for eksempel levere en hemmelighet direkte til en godkjent tjeneste uten å eksponere den unødvendig for modellen.

Dette bygger på etablerte prinsipper om minste privilegium og arbeidsdeling.

Det reiser også et interessant spørsmål om arkitektur basert på Bring Your Own Model (BYOM) eller Bring Your Own LLM (BYO-LLM).

Hvis den underliggende modellen byttes ut i morgen, hvilke sikkerhetsgarantier vil fortsatt gjelde?

Autorisasjon for oppgaver, isolering av påloggingsopplysninger, omfangsbegrensninger, logging og håndheving av retningslinjer kan ligge i det omkringliggende rammeverket, i stedet for å være helt avhengig av modellens atferd.

Det betyr ikke at rammeverket automatisk er sikkert, eller at modeller kan byttes ut uten videre. Ulike modeller kan tolke instruksjoner forskjellig, bruke verktøy på ulike måter og føre til ulike typer svikt.

En meningsfull evaluering må teste både kontrollene som skal forbli uendret, og atferden som endres når modellen byttes ut.

Kanskje er noen av de mest varige sikkerhetsegenskapene dem som fortsatt kan håndheves uavhengig, selv når intelligenskomponenten videreutvikles.

Når KI handler på KI: Verifiseringsproblemet

Tenk deg en hypotetisk arbeidsflyt for sikkerhetsoperasjoner:

Undersøk denne hendelsen, samle bevisene, identifiser de berørte identitetene, foreslå tiltak for å begrense skadeomfanget, utfør de godkjente handlingene, og kontroller resultatet.

En etterforskningsagent analyserer telemetridata. En annen anbefaler tiltak for å begrense skade. En autorisert gjennomføringsagent utfører endringene. En verifiseringsagent vurderer resultatet.

Dette illustrerer autonom hendelseshåndtering med lukket sløyfe, ikke en dokumentert svikt i hele bransjen.

Tenk deg at den første agenten feilaktig identifiserer en identitet som kompromittert. En annen agent godtar konklusjonen og deaktiverer kontoen. En tredje bekrefter at kontoen ble deaktivert, og rapporterer at oppgaven er fullført.

Den valgte handlingen ble fullført.

Men var den opprinnelige vurderingen riktig? Var handlingen autorisert? Håndterte tiltakene den faktiske trusselen? Førte de til unødvendige forstyrrelser?

Verifisering kan ikke begrenses til å bekrefte at en agent utførte handlingen den valgte.

Det at verifiseringen overlates til en annen AI-agent, gjør heller ikke automatisk resultatet uavhengig.

Ulike agenter kan bygge på de samme unøyaktige telemetridataene, kompromitterte opplysningene eller feilaktige antakelsene. At de er enige, bekrefter ikke de underliggende faktaene på uavhengig grunnlag.

Jo større konsekvenser en autonom handling kan få, desto viktigere er det med verifisering som er uavhengig av systemet som tar beslutningen.

Slik uavhengighet kan innebære bevis innhentet fra separate kilder, deterministiske policykontroller, begrensede gjennomføringsmiljøer, menneskelig gjennomgang eller en kombinasjon av sikkerhetstiltak.

Kontrolltiltakene bør stå i forhold til konsekvensene av feil.

Handlinger med liten påvirkning som kan reverseres, kan egne seg for automatisert verifisering. Handlinger med stor påvirkning eller som er vanskelige å reversere, kan kreve strengere autorisering, uavhengig bekreftelse og uttrykkelig godkjenning fra et menneske.

Fire spørsmål bidrar til å skille mellom de relevante sikkerhetsegenskapene:

• Tolket systemet den tiltenkte oppgaven riktig?
• Lå handlingen innenfor den delegerte myndigheten?
• Holdt gjennomføringen seg innenfor de tillatte rammene?
• Oppfylte resultatet det tiltenkte sikkerhetsmålet?

Disse spørsmålene henger sammen, men kan ikke erstatte hverandre.

En agent kan utføre en autorisert handling som får et utilsiktet resultat. Den kan også oppnå et tilsynelatende gunstig resultat gjennom en uautorisert handling.

Ingen av delene bør automatisk regnes som vellykket sikkerhetsarbeid.

Etter hvert som autonome systemer blir mer avanserte, handler utfordringen ikke bare om å gjøre dem i stand til å fullføre komplekse arbeidsflyter. Det handler om å fremskaffe tilstrekkelige bevis for at handlingene deres fortsatt er autoriserte, hensiktsmessige og riktige.

Det innebærer også å vite når man skal stoppe, eskalere saken, reversere en handling eller akseptere en avgrenset risiko som man uttrykkelig forstår.

Tillit må bygge på bevis

Sikkerhetskonsekvensene av autonom kunstig intelligens er ikke utelukkende negative.

Autonome systemer kan hjelpe forsvarere med å avdekke svakheter, undersøke trusler og utføre valideringsarbeid som ellers ville krevd betydelig menneskelig innsats.

Bedre modeller, sterkere eksterne kontroller og mer modne driftsrutiner kan redusere noen av risikoene knyttet til delegert myndighet.

Det ville derfor være for tidlig å konkludere med at autonom kunstig intelligens i seg selv er usikker, eller at styringen ikke kan holde tritt med utviklingen.

Det finnes også et tungtveiende motargument mot påstanden om at autonom kunstig intelligens krever helt nye sikkerhetsprinsipper.

Mange av de underliggende problemene – for omfattende privilegier, upålitelige inndata, svak autorisering, inkonsekvent håndheving av retningslinjer og utilstrekkelig verifisering – har vært studert i flere tiår.

Etablerte kontrolltiltak kan allerede gi brukbare løsninger når de implementeres og testes på riktig måte.

Autonomi kan endre hastigheten, omfanget og kompleksiteten i hvordan kontrolltiltakene brukes. Den gjør dem ikke automatisk ugyldige.

Bevisene peker mot et mer nyttig spørsmål: Under hvilke forhold kan vi stole på at autonome systemer utøver delegert myndighet, og hvordan viser vi at disse forholdene er oppfylt?

Svaret ligger ikke i modellens kapasitet alene.

Det krever arkitektoniske grenser, tydelig ansvarsfordeling, autorisering som håndheves uavhengig, passende tilsyn og bevis for at sikkerhetstiltakene fungerer under realistiske forhold.

Det krever også en helhetlig, men stadig videreutviklet forståelse av sikkerhet og risiko.

De grunnleggende sikkerhetsprinsippene våre trenger ikke å endres hver gang en ny modell kommer. Men vi må stadig utfordre antakelsene våre om hvordan prinsippene gjelder, etter hvert som kapasiteten, driftsmiljøene og den delegerte myndigheten utvikler seg.

Dette er formålet med Offensive Rigor.

Ikke for å bevise at KI-systemer vil svikte, men for å avdekke hvor de kan svikte, fastslå konsekvensene og validere kontrollene som skal forhindre eller begrense slike feil.

Den kanskje mer varige fordelen ligger ikke bare i å velge en mer kapabel modell, men i å bygge en arkitektur der modeller kan byttes ut uten at grensene for tillit, myndighet og verifisering settes på spill.

Katt-og-mus-leken fortsetter. I økende grad kan begge sider ha autonome aktører.

Det avgjørende er å sikre at evnen vår til å finne svakheter, rette dem og dokumentere resultatene ikke går tapt i kappløpet om å automatisere alt annet.

Tillit må bygge på dokumentasjon.

Forfatterens merknad: Synspunktene og tolkningene som kommer til uttrykk i denne artikkelen, er mine egne og gjenspeiler ikke nødvendigvis arbeidsgiverens offisielle standpunkter, retningslinjer eller produktenes funksjonalitet.