Claude Code auto mode: sikkerhet og kontroller

Nøkkelpunkter per 13. august 2026:

Auto mode blir standard for Claude Code på Pro-, Max- og Team-kontoer fra 14. august, uten godkjenningsspørsmål med mindre handlingen er irreversibel (TechCrunch, 2026).
89 prosent mot 13.6 prosent: auto mode fanget flere skadelige handlinger enn menneskelig gjennomgang i en studie med 1 053 betalte testere (TechCrunch, 2026).
Brukere godkjenner 93 prosent av alle tillatelsesforespørsler i Claude Code, som gjør klikkingen til rutine snarere enn reell kontroll (Anthropic, 2026).
Klassifisereren ser ikke verktøyresultater, bare brukermeldinger og agentens verktøykall, og full pipeline lander på 0.4 prosent falske positiver (Anthropic, 2026).
AI Act ble gjeldende 2. august 2026, mens de strenge høyrisikoforpliktelsene først slår inn 2. desember 2027 (EU-kommisjonen).

Hva auto mode i Claude Code faktisk gjør

Fra 14. august slår Anthropic på auto mode som standard for Claude Code på Pro-, Max- og Team-kontoer (TechCrunch, 2026). Endringen er liten i grensesnittet og stor i praksis. Agenten slutter å be om lov før hver filredigering, hvert terminalkall og hver pakkeinstallasjon. Den bare kjører.

For et team betyr det at beslutningen om hva agenten får lov til flyttes. Den ligger ikke lenger i et klikk i øyeblikket, men i konfigurasjonen dere satte opp på forhånd. Det er en bedre plassering, forutsatt at konfigurasjonen faktisk finnes.

Grensen går ved irreversibelt, destruktivt og utadrettet

Auto mode er ikke fri flyt. Claude Code fortsetter uten å spørre med mindre handlingen er irreversibel, destruktiv eller rettet utenfor miljøet agenten arbeider i (TechCrunch, 2026). Å skrive en fil i repoet passerer. Å slette en produksjonsdatabase eller sende data til en ekstern adresse gjør det ikke.

Definisjonen av «utenfor miljøet» er den viktigste i hele oppsettet. Den avgjør hva som teller som en utgang, og dermed hvor mye et kompromittert prosjekt kan gjøre. Et repo med skrivetilgang til CI-hemmeligheter har et helt annet miljø enn en isolert sandkasse med samme kodebase.

To nye kontroller følger med

Sammen med utrullingen kommer screening for prompt injection og tilpassbare hard deny-regler (TechCrunch, 2026). Deny-reglene er det mest umiddelbart nyttige for et team: de lar dere skrive ned hva agenten aldri skal gjøre, uavhengig av hva modellen mener er fornuftig der og da.

Standardoppsettet leveres med mer enn tjue blokkeringsregler (Anthropic, 2026). Det er et startpunkt kalibrert for gjennomsnittsbrukeren, ikke for deres trusselbilde. Forskjellen mellom de to er hele jobben.

Leverandøren har brukt det selv i månedsvis

Boris Cherny, som leder Claude Code, sier teamet har brukt auto mode utelukkende i mange måneder (TechCrunch, 2026). Det er et reelt signal om modenhet, men det er også et signal fra en gruppe som kjenner verktøyet bedre enn noen andre og jobber i et miljø de selv har designet.

Deres utviklere gjør ikke det. De jobber i eldre repoer, med tredjepartsavhengigheter, mot kundemiljøer og med hemmeligheter som ligger på steder ingen helt husker hvorfor. Erfaringen fra leverandørens eget team overføres ikke automatisk.

Tallene bak sikkerhetsløftet og hvorfor manuell godkjenning svikter

Anthropic hevder at auto mode er tryggere enn manuell gjennomgang. Påstanden hviler på en studie med 1 053 betalte testere, der auto mode fanget 89 prosent av skadelige handlinger mot 13.6 prosent for menneskelig gjennomgang (TechCrunch, 2026).

Gapet er stort nok til at det ikke kan forklares med målestøy. Men det er et gap leverandøren selv har målt, med sin egen definisjon av hva som er en skadelig handling, i sitt eget testoppsett.

Godkjenningsraten forklarer det meste

Grunnen til at mennesker skårer lavt er ikke at utviklere er uoppmerksomme. Det er at de blir bedt om å ta stilling til for mye. Anthropics egne data viser at brukere godkjenner 93 prosent av tillatelsesforespørslene i Claude Code (Anthropic, 2026). TechCrunch oppgir 97 prosent for samme forhold (TechCrunch, 2026).

At to tall fra samme leverandør spriker med fire prosentpoeng er i seg selv verdt å registrere når dere vurderer hvor presist datagrunnlaget er. Retningen er uansett den samme, og den er entydig.

Alura mener: når brukere godkjenner over 90 prosent av forespørslene, er manuell klikking allerede nærmere en illusjon av kontroll enn reell gjennomgang. Et samtykke som gis nesten hver gang bærer ikke mye informasjon. Da er spørsmålet ikke om automatikk er bedre enn mennesket, men hvor mennesket skal settes inn i stedet.

Hva studien ikke forteller

Vi vet ikke hvordan de skadelige handlingene ble konstruert, hvordan testerne ble instruert, eller hvor mye tid de fikk per beslutning. Vi vet ikke om menneskene i sammenligningen jobbet under samme tidspress som en utvikler midt i en sprint, eller om de visste at de ble målt. Vi vet heller ikke om resultatet holder i kodebaser som ligner deres.

Ingen av disse innvendingene gjør tallet feil. De gjør det uverifisert. Alura mener at leverandørens egne sikkerhetstall er et utgangspunkt, ikke et bevis: be om metode og uavhengig verifisering før auto mode slippes løs på produksjonskode.

Sorter tallene etter hvem som har målt dem

Den enkleste disiplinen når et sikkerhetsløfte skal vurderes er å sortere tallene etter kilde før dere diskuterer innhold. Leverandørtall, uavhengige rapporter og regulatoriske primærkilder har ulik bevisverdi, og bør ikke ligge i samme kolonne i en beslutningssak.

Tall	Kilde	Type
89 % mot 13.6 % fangst av skadelige handlinger	Anthropic, gjengitt av TechCrunch	Leverandørens egen studie
93 % godkjenningsrate på tillatelsesforespørsler	Anthropic	Leverandørens egen telemetri
0.4 % falske positiver for full pipeline	Anthropic	Intern evaluering
77 % av sårbarheter identifisert av AI-agent i konkurranse	International AI Safety Report 2026	Uavhengig ekspertrapport
Datoer og forpliktelser i AI Act	EU-kommisjonen	Regulatorisk primærkilde

Les også: Muse Spark 1.1 koster en brøkdel av Claude og GPT. Meta lanserte Muse Spark 1.1 til 1,25 dollar per million input-tokens, en brøkdel av Claude og GPT.

De to forsvarslagene i auto mode og hva de ikke ser

Auto mode bygger på to lag: en injeksjonssensor på inngangssiden og en transkripsjonsklassifiserer på utgangssiden (Anthropic, 2026). Det første laget ser etter manipulasjon på vei inn. Det andre vurderer om handlingen agenten er i ferd med å utføre er autorisert av det brukeren faktisk ba om.

Arkitekturen er fornuftig, og den er offentlig dokumentert. Det siste er ikke en selvfølge, og gjør den mulig å vurdere kritisk.

Klassifisereren kjører i to stadier

Første stadium er et raskt enkelt-token-filter. Bare hvis det filteret flagger noe, kjøres kjede-til-tanke-resonnering som andre stadium (Anthropic, 2026). Designet er en latens- og kostnadsavveining: den dyre vurderingen brukes sjelden, den billige alltid.

Effekten på presisjon er målbar. Stadium 1 alene gir 8.5 prosent falske positiver på ekte trafikk, mens full pipeline lander på 0.4 prosent (Anthropic, 2026). Et grovfilter som stopper hver tolvte legitime handling ville vært ubrukelig i praksis. Det er andre stadium som gjør oppsettet levelig.

Blindsonen ligger i verktøyresultatene

Klassifisereren ser bare brukermeldinger og agentens verktøykall, ikke Claudes egne meldinger eller resultatene som kommer tilbake fra verktøyene (Anthropic, 2026). Valget reduserer angrepsflaten: innhold en angriper kontrollerer kan ikke like lett påvirke dommeren.

Prisen er at ondsinnede instruksjoner som ligger i en fil, et søkeresultat eller et API-svar ikke inspiseres direkte av klassifisereren. De må slå ut i et verktøykall før de fanges. Dette er nettopp mekanismen bak prompt injection, og den er ikke løst av arkitekturen her.

Konservativ som standard, med eskalering

Klassifisereren er bevisst konservativ og behandler alt agenten gjør på eget initiativ som uautorisert med mindre brukeren har sagt noe annet (Anthropic, 2026). Det flytter tvilstilfeller mot stopp fremfor mot handling, som er riktig retning for en agent med skrivetilgang.

I tillegg finnes en enkel bremsemekanisme: 3 påfølgende avslag eller 20 totalt i en økt stopper modellen og eskalerer til mennesket (Anthropic, 2026). Terskelen fanger agenter som maler i ring, og den fanger en angriper som prøver seg frem.

Lag	Ser	Ser ikke	Praktisk konsekvens
Injeksjonssensor (inngang)	Innkommende innhold og mistenkelige mønstre	Hele den senere handlingskjeden	Fanger kjente injeksjonsformer, ikke nye
Transkripsjonsklassifiserer, stadium 1	Brukermeldinger og verktøykall	Verktøyresultater og Claudes egne meldinger	Raskt, men 8.5 % falske positiver alene
Transkripsjonsklassifiserer, stadium 2	Samme kontekst, med resonnering	Samme blindsone	Reduserer falske positiver til 0.4 %
Eskalering ved avslag	Antall avslag i økten	Intensjonen bak forsøkene	Stopper ved 3 på rad eller 20 totalt

Kontrollrammeverket fra AWS for skrivetid og byggetid

Leverandørkontroller dekker det som skjer inne i verktøyet. De dekker ikke hva som skjer med koden etterpå. AWS har publisert et rammeverk for AI-kodeagenter som deler kontrollene i to pilarer: skrivetid og byggetid (AWS).

Rammeverket er verktøyagnostisk og skyagnostisk (AWS). Det er en fordel: dere kan bruke strukturen uten å bytte plattform, og uten å binde policyen til en enkelt leverandørs funksjonssett.

Skrivetid handler om hva agenten får røre

Skrivetidskontroller er alt som begrenser agenten mens den arbeider: hvilke kataloger den kan skrive i, hvilke kommandoer den kan kjøre, hvilke nettverksadresser den når, hvilke hemmeligheter som finnes i miljøet. Auto modes deny-regler hører hjemme her, sammen med sandkasse og tilgangsstyring.

Dette er laget som er billigst å sette opp og dyrest å utelate. En agent uten skrivetidsgrenser er avhengig av at klassifisereren tar riktig avgjørelse hver eneste gang. Det er en urimelig forventning å ha til et statistisk system.

Byggetid handler om hva som slipper videre

Byggetidskontroller er testene, skanningene og portene i CI-pipelinen. De bryr seg ikke om hvem som skrev koden, bare om hva den gjør. Statisk analyse, avhengighetsskanning, hemmelighetsdeteksjon og policy-porter fungerer likt på menneskeskrevet og agentskrevet kode.

Poenget med to pilarer er at de fanger ulike feil. Skrivetid stopper handlinger som aldri burde skje. Byggetid stopper resultater som ikke burde slippe gjennom. Team som allerede kjører modne pipelines, som mange gjør etter å ha tatt i bruk vibe coding på AWS, har halve jobben gjort.

Skribenten skal ikke være godkjenneren

AWS formulerer to prinsipper som bør stå på veggen: agenten som skrev koden skal ikke være agenten som gjennomgår den, og menneskelig gjennomgang settes inn der skjønn kreves, ikke overalt (AWS). Alura deler begge.

Det første er ikke et teknisk krav, det er et uavhengighetskrav. En agent som vurderer sitt eget arbeid arver sine egne feilantakelser. Det andre er en erkjennelse av at oppmerksomhet er en begrenset ressurs som må rasjoneres.

Pilar	Spørsmålet den svarer på	Typiske kontroller	Fanger ikke
Skrivetid	Hva får agenten lov til å gjøre?	Deny-regler, sandkasse, nettverksgrenser, hemmelighetsisolasjon	Kvalitetsfeil i kode som er tillatt å skrive
Byggetid	Hva får lov til å passere?	Statisk analyse, avhengighetsskanning, hemmelighetsdeteksjon, policy-porter	Handlinger agenten gjorde utenfor repoet
Menneskelig skjønn	Er dette riktig ting å gjøre?	Gjennomgang av arkitektur, tilgang, personopplysninger, betalingsflyt	Volum, hvis den brukes på alt

Risikoene auto mode ikke fjerner

Auto mode adresserer ett spørsmål: om en handling er autorisert. Den vurderer ikke om koden agenten skriver er god, om pakken den installerer eksisterer, eller om instruksjonen den følger kom fra dere. En oversikt over risikobildet for AI-kodeagenter viser hvor bred den resterende flaten er (vibeappscanner.com).

Dette er ikke en innvending mot funksjonen. Det er en presisering av hva den er, slik at dere ikke skriver av risiko dere fortsatt bærer.

Sårbar kode som ser helt riktig ut

AI-kodeagenter produserer kode med SQL-injeksjon, XSS og manglende autentiseringssjekker, og modeller trent på eldre kode foreslår utdaterte og usikre API-er og mønstre (vibeappscanner.com). Koden kompilerer, testene passerer, og feilen ligger i et mønster som var akseptabelt for fem år siden.

Denne kategorien fanges av byggetidskontroller, ikke av tillatelsesbeslutninger. En klassifiserer som vurderer om agenten har lov til å redigere en fil har ingen mening om hva som står i den.

Pakker som ikke finnes og hemmeligheter som gjør det

Agenter foreslår pakker som ikke eksisterer, og ondsinnede pakker med typosquatting utnytter nettopp det (vibeappscanner.com). En hallusinert avhengighet blir en angrepsvektor i det øyeblikket noen registrerer navnet.

Parallelt kan agenter lese og eksponere API-nøkler, passord og hemmeligheter fra miljøet (vibeappscanner.com). Det er derfor hemmelighetshåndtering er et skrivetidsspørsmål: den sikreste hemmeligheten er den som ikke ligger i miljøet agenten kjører i.

Instruksjoner som overlever økten

Ondsinnede instruksjoner skjult i kode, dokumenter eller pakker kan kapre agentens oppførsel, og instruksjoner plassert i konfigurasjonsfiler som .cursorrules kan vedvare på tvers av økter (vibeappscanner.com). Det gjør prosjektets egne konfigurasjonsfiler til en del av angrepsflaten.

Legg til at store flerfilendringer fra agenter er vanskelige å gjennomgå ordentlig (vibeappscanner.com), og bildet blir tydelig: mengden output er i seg selv en sikkerhetsfaktor. Samme dynamikk gjelder for team som bygger interne apper raskt uten å endre gjennomgangsrutinene.

Oppsett for et norsk SMB-team den første uken

Alura mener at hard deny-regler, hemmelighetshåndtering og loggkrav settes opp før den første agentøkten, ikke etter det første avviket. Rekkefølgen er ikke pedantisk. Et team som slår på auto mode fredag og skriver policy mandag har hatt en helg uten kontroller.

Under er en plan som et team på fem til femten utviklere kan gjennomføre på en uke uten å stanse annet arbeid. Den forutsetter ingen nye verktøykjøp.

Dag for dag

Dag	Hva dere gjør	Ferdig når
1	Skriv egne hard deny-regler oppå standardoppsettet. Gå gjennom de mer enn tjue innebygde reglene og legg til det deres miljø krever.	Reglene ligger i versjonskontroll og er lest av hele teamet.
2	Fjern hemmeligheter fra agentens miljø. Flytt til en hemmelighetstjeneste med korttidstokens.	Ingen langlivede nøkler i shell-profiler, .env-filer eller lokale konfigurasjoner.
3	Definer «utenfor miljøet». Begrens nettverk, skrivetilgang og kataloger agenten når.	En agentøkt kan ikke nå produksjon eller kundedata uten eksplisitt godkjenning.
4	Sett byggetidsporter: avhengighetsskanning, hemmelighetsdeteksjon, statisk analyse.	Ingen agentskrevet PR kan merges uten at portene har kjørt.
5	Slå på logging av agenthandlinger og definer hvem som leser eskaleringer.	Eskalering ved 3 påfølgende eller 20 totale avslag går til en navngitt person.

Merk at ingen av punktene handler om å velge modell eller leverandør. De handler om grenser og sporbarhet, og de holder seg gyldige hvis dere bytter verktøy senere.

Start med ett repo, ikke hele porteføljen

Velg et repo med reell kompleksitet, men uten direkte produksjonspåvirkning. Kjør auto mode der i to til fire uker og logg hva som faktisk skjer: hvor mange eskaleringer, hvilke deny-regler som slår ut, hvilke funn byggetidsportene gjør på agentskrevet kode kontra menneskeskrevet.

Da har dere et eget datagrunnlag når spørsmålet om utvidelse kommer. Det er verdt mer i en styringsdiskusjon enn å sitere leverandørens studie.

Dette bør dere kreve dokumentert fra leverandøren

Anskaffelse av et AI-kodeverktøy er en leverandørvurdering, ikke en verktøyvurdering. Spørsmålene under er formulert slik at de kan legges rett inn i en anskaffelsesprosess, og de er alle besvarbare uten at leverandøren avslører forretningshemmeligheter.

Metode, ikke bare resultat

Be om testprotokollen bak sikkerhetstallene: hvordan de skadelige handlingene ble konstruert, hvordan sammenligningsgruppen ble instruert, og hvilken populasjon de 1 053 testerne representerte. Be også om evalueringsgrunnlaget for klassifisereren, som er delvis publisert med datasett på 10 000 ekte handlinger, 52 reelle overivrige tilfeller og 1 000 syntetiske eksfiltreringsoppgaver (Anthropic, 2026).

At datasettene er oppgitt med størrelse er positivt. Legg merke til at det minste av dem har 52 tilfeller. Konklusjoner om overivrig agentatferd hviler på et tynt grunnlag, og det bør sies høyt før tallet siteres videre.

Data, logg og eskalering

Proprietær kode sendes til AI-leverandørens servere og kan brukes til trening (vibeappscanner.com). Krev skriftlig svar på om deres kode inngår i trening, hvor lenge den lagres, hvor den behandles geografisk, og hvordan sletting bekreftes.

På driftssiden: krev at agenthandlinger logges på et format dere kan eksportere, at eskaleringer varsles til en kanal dere kontrollerer, og at deny-regler versjoneres i deres repo og ikke bare i leverandørens grensesnitt. Uten eksporterbar logg har dere ingen etterprøvbarhet den dagen noe går galt.

Les også: AI-assistenter blir tryggere men prompt injection består. Nye modeller står imot tusenvis av hackeforsøk, men prompt injection er fortsatt OWASPs største LLM-risiko.

Kostnaden ved menneskelig gjennomgang og hvor den lønner seg

AI-kodeagenter kan åpne dusinvis av pull requests på tvers av repoer i løpet av en ettermiddag (AWS). Det er den økonomiske kjernen i hele diskusjonen. Gjennomgangskapasiteten i et team er tilnærmet konstant, mens produksjonen ikke lenger er det.

Når produksjonen vokser og gjennomgangen ikke gjør det, skjer en av to ting: køen vokser, eller gjennomgangen blir overfladisk. Den andre er verre, fordi den ser ut som den første fungerer.

Gjennomgang som ikke fanger noe koster fortsatt

En godkjenning som gis i 93 av 100 tilfeller er ikke gratis. Den koster kontekstbytte, ventetid og oppmerksomhet, og den gir en falsk følelse av dekning. Kostnaden er reell selv når utbyttet er tilnærmet null.

Det er derfor rasjoneringsprinsippet fra AWS er en økonomisk beslutning, ikke bare en sikkerhetsfaglig en. Samme logikk gjelder for ressursbruken i selve agentkjøringene, som vi har sett på i sammenheng med token-budsjett.

Der skjønn faktisk kreves

Menneskelig gjennomgang har høyest avkastning der en maskin ikke kan vite hva som er riktig: tilgangsstyring, behandling av personopplysninger, betalingsflyt, arkitekturvalg som binder dere i årevis, og alt som berører kundedata. Der er spørsmålet ikke «er dette lov», men «er dette klokt».

Situasjon	Menneske inn?	Begrunnelse
Refaktorering uten API-endring	Nei	Byggetidsporter og tester dekker risikoen
Ny avhengighet i prosjektet	Ja, kort	Hallusinerte og typosquattede pakker fanges ikke av tillatelseslogikk
Endring i autentisering eller tilgangsstyring	Ja, grundig	Skjønn kreves, feil er kostbare og stille
Behandling av personopplysninger	Ja, grundig	Regulatorisk ansvar kan ikke delegeres til en agent
Dokumentasjon og tester	Nei	Lav konsekvens, høyt volum
Eskalering fra auto mode	Ja, alltid	Signalet er per definisjon utenfor det normale

AI Act og datoene norske utviklingsteam må planlegge etter

AI Act er det første omfattende juridiske rammeverket for AI på verdensbasis, med fire risikonivåer og ni forbudte praksiser (EU-kommisjonen). For et utviklingsteam er det viktigste å plassere seg selv riktig i risikotrappen, fordi forpliktelsene skiller seg dramatisk mellom nivåene.

De fleste kodeassistenter havner ikke i høyrisikokategorien. Systemene teamet bygger med dem kan gjøre det, og det er den distinksjonen som betyr noe i praksis.

Tidslinjen som allerede gjelder

AI Act trådte i kraft 1. august 2024 og ble gjeldende 2. august 2026 (EU-kommisjonen). Forbudene 1 til 8 har vært effektive siden februar 2025, og transparensreglene slår inn i august 2026.

Dato	Hva skjer	Relevans for utviklingsteam
1. august 2024	AI Act trådte i kraft	Startpunkt for hele tidslinjen
2. februar 2025	Forbudte praksiser og AI-kompetanseplikt	Krav om AI-kompetanse hos de som bruker systemene
2. august 2025	Styringsregler og forpliktelser for GPAI-modeller	Gjelder modellene dere bygger på
27. juli 2026	AI Omnibus trådte i kraft	Justeringer i rammeverket
2. august 2026	AI Act ble gjeldende, AI Office og medlemsland håndhever	Håndheving er operativ
desember 2026	Forbud 9 trer i kraft	Siste av de forbudte praksisene
2. desember 2027	Strenge forpliktelser for høyrisikosystemer	Planleggingshorisonten for høyrisikoprodukter

Håndhevingen er operativ nå

Fra 2. august 2026 ligger ansvaret for håndheving hos AI Office og medlemslandene (EU-kommisjonen). Forventet operativ kapasitet for AI-evaluering er satt til 2027, som betyr at kapasiteten bygges opp mens reglene allerede gjelder.

Praktisk lesning for et norsk team: reglene er ikke fremtidige lenger, men tilsynsintensiteten vil trolig øke gradvis. Å bruke perioden til å få dokumentasjonen på plass er billigere enn å gjøre det under tilsyn.

Hva dette konkret betyr for kodeagenter

Selve kodeassistenten er sjelden det regulerte objektet. Systemet dere leverer til kunde kan være det, og da må dere kunne dokumentere hvordan koden ble til, hvilke kontroller den passerte, og hvem som godkjente hva. Agentlogger blir da et etterlevelsesdokument, ikke bare et driftsverktøy.

Høyrisikoforpliktelsene inntrer 2. desember 2027 (EU-kommisjonen). Bygger dere noe i dag som skal leve inn i den datoen, er sporbarhet et arkitekturkrav og ikke en senere oppgave.

Markedsbildet for AI-sikkerhet i 2026

International AI Safety Report 2026 er skrevet av over 100 eksperter nominert fra over 30 land, ledet av Yoshua Bengio (arXiv, 2026). Rapporten gir ikke politiske anbefalinger, som gjør den brukbar som felles faktagrunnlag på tvers av posisjoner.

Den beskriver at AI-kapabiliteter har fortsatt å forbedres, spesielt innen matematikk, koding og autonom operasjon (arXiv, 2026). Det er de tre aksene som til sammen definerer en kodeagent.

Sårbarhetsjakt går begge veier

En AI-agent identifiserte 77 prosent av sårbarhetene i ekte programvare i en konkurranse (arXiv, 2026). Det er en av de tydeligste indikatorene på at samme kapabilitet som gjør agenter nyttige i sikkerhetsarbeid også gjør dem nyttige for den som leter etter en vei inn.

For et SMB-team betyr det at tempoet i sårbarhetsoppdagelse øker på begge sider. Patch-vinduer blir kortere, og «vi er for små til å være interessante» blir et svakere argument for hvert år.

Frivillige rammeverk og ujevn adopsjon

I 2025 publiserte eller oppdaterte 12 selskaper sine Frontier AI Safety Frameworks (arXiv, 2026). Rapporten beskriver også at flere selskaper valgte å slippe modeller i 2025 med ekstra sikkerhetstiltak, fordi testing før utrulling ikke kunne utelukke at modellene kunne hjelpe nybegynnere med å utvikle biologiske våpen.

Samtidig er adopsjonen rask, men svært ujevn: 700 millioner mennesker bruker ledende AI-systemer ukentlig, mens andelen av befolkningen som bruker AI varierer fra rundt 50 prosent i noen land til rundt 10 prosent i mange afrikanske, asiatiske og latinamerikanske land (arXiv, 2026). Norge ligger i den øvre enden, som betyr at norske team møter både gevinstene og risikoene tidlig.

Vanlige feil når team slår på auto mode

Feilene vi ser gjentar seg, og de er nesten alltid organisatoriske heller enn tekniske. Fire mønstre går igjen.

Å behandle standardoppsettet som sin egen policy

De mer enn tjue innebygde blokkeringsreglene er kalibrert for en generell brukermasse. Et team som håndterer helsedata, betalinger eller kundedata på vegne av andre har krav som ikke er representert der.

Standardoppsettet er en fornuftig bunnplate. Det er ikke en risikovurdering, og det kan ikke fremlegges som en.

Å la agenten godkjenne sitt eget arbeid

Når volumet øker er fristelsen å sette en annen agentkjøring til å gjennomgå PR-ene. Det kan fungere, forutsatt at det er en annen agent med annen kontekst og andre instruksjoner (AWS).

Det som ikke fungerer er samme økt, samme kontekst, ny prompt. Agenten har allerede bestemt seg for at løsningen er riktig. Gjennomgangen bekrefter da bare den opprinnelige antakelsen.

Å måle hastighet uten å måle avvik

Team som ruller ut auto mode måler nesten alltid gjennomstrømning: flere PR-er, kortere ledetid, færre avbrudd. Nesten ingen måler antall eskaleringer, hvilke deny-regler som utløses, eller hvor mange funn byggetidsportene gjør på agentskrevet kode.

Uten det andre settet har dere ingen måte å oppdage at kontrollene degraderer. En eskalering som ingen leser er funksjonelt det samme som ingen eskalering. Sett en navngitt eier på kanalen fra første dag, ikke en delt innboks.

Spørsmål og svar om AI-kodeagenter og sikkerhet

Spørsmålene under kommer oftest fra ledere som skal ta beslutningen, ikke fra utviklerne som skal bruke verktøyet.

Bør vi slå av auto mode når det kommer som standard?

Ikke automatisk. Utgangspunktet er at tallene peker i favør av automatikk, gitt at kontrollene er på plass. Men hvis dere ikke har deny-regler, hemmelighetshåndtering og byggetidsporter, er svaret ja: slå det av til de tingene finnes.

Beslutningen bør uansett være bevisst og dokumentert. En funksjon som endrer standardoppførsel på Pro-, Max- og Team-kontoer (TechCrunch, 2026) fortjener et notat i beslutningsloggen, ikke stillhet.

Er 89 prosent godt nok?

Det avhenger av hva de resterende 11 prosentene er. En fangstrate sier ingenting om alvorlighetsgraden i det som slipper gjennom. En kontroll som fanger nesten alt trivielt og lite alvorlig er svakere enn tallet antyder.

Det riktige oppfølgingsspørsmålet til leverandøren er ikke «hvor høy er raten», men «hvordan fordeler de uoppdagede handlingene seg på alvorlighetsgrad». Uten det svaret er tallet et markedsføringstall.

Løser prompt injection-screening problemet?

Nei. Screeningen hever terskelen, men klassifisereren ser ikke verktøyresultater (Anthropic, 2026), og ondsinnede instruksjoner kan ligge i kode, dokumenter, pakker og konfigurasjonsfiler som overlever på tvers av økter (vibeappscanner.com).

Behandle prompt injection som en vedvarende tilstand dere designer rundt, ikke en feil som blir fikset i neste versjon.

Trenger et lite norsk team å bry seg om AI Act?

Ja, men proporsjonalt. Rammeverket er risikobasert med fire nivåer (EU-kommisjonen), og de fleste interne verktøy havner lavt. Kompetanseplikten og transparenskravene gjelder likevel bredt.

Det praktiske minimumet er å vite hvilken kategori hvert system dere leverer havner i, og å kunne dokumentere det. Det er en dags arbeid for de fleste SMB-er, og det blir dyrere jo lenger dere venter.

Oppsummering og neste steg

Auto mode flytter tillatelsesbeslutningen fra et klikk i øyeblikket til en konfigurasjon satt på forhånd. Det er en forbedring, fordi klikkingen for lengst var blitt rutine: brukere godkjenner 93 prosent av forespørslene uansett (Anthropic, 2026). Forutsetningen er at konfigurasjonen er deres, gjennomtenkt og versjonert.

Tallene som støtter funksjonen er leverandørens egne. Bruk dem som utgangspunkt, be om metoden, og bygg deres eget datagrunnlag i ett repo før dere utvider. Kontrollrammeverket med skrivetid og byggetid (AWS) gir strukturen, og den holder seg gyldig hvis dere bytter verktøy.

Tre ting å gjøre denne uken

Skriv egne hard deny-regler og legg dem i versjonskontroll. Flytt hemmeligheter ut av agentens miljø. Sett en navngitt person som eier eskaleringer, som utløses ved 3 påfølgende eller 20 totale avslag i en økt (Anthropic, 2026).

Deretter: velg ett repo uten produksjonspåvirkning, kjør auto mode der i noen uker, og mål avvik like nøye som dere måler hastighet. Når spørsmålet om bredere utrulling kommer, har dere da noe bedre enn en leverandørstudie å svare med.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.

Kilder

TechCrunch (2026). Anthropic is turning Claude Code's auto mode on by default
Anthropic (2026). How we built Claude Code auto mode: a safer way to skip ...
EU-kommisjonen. AI Act | Shaping Europe's digital future - European Union
AWS. Balancing speed and safety: A control framework for AI ...
vibeappscanner.com. AI Coding Agent Risks: Security Threats You Need to Know
arXiv (2026). International AI Safety Report 2026