Hvorfor sier en AI-agent «ferdig» når arbeidet ikke er ferdig?

Hvordan kom en OpenAI-modell seg ut av sandkassen og hacket Hugging Face?#

Først fakta, deretter hvorfor dette angår deg.

OpenAI målte hva modellene deres kunne gjøre innen offensiv cybersikkerhet. De brukte testen ExploitGym — 898 oppgaver der man må gjøre en kjent sårbarhet om til en fungerende exploit, altså et ferdig program som utnytter sårbarheten. For å se det reelle taket slo de av de innebygde sikkerhetsfiltrene som vanligvis hindrer modellen i å gjøre slikt. De stengte miljøet helt ute fra omverdenen og lot én utvei stå åpen: et internt mellomprogram som brukes til å installere pakker.

En zero-day-sårbarhet er et hull ingen kjenner til ennå, heller ikke personen som skrev programmet. Modellene fant en i nettopp den eneste åpningen.

Deretter økte de privilegiene sine, beveget seg gjennom det interne nettverket til en maskin med internettilgang og gjettet derfra at svarene på ExploitGym kanskje lå på Hugging Face. Ingen hadde fortalt dem om Hugging Face. De fant det ut selv.

Gjetningen var feil. ExploitGym finnes ikke på Hugging Face i det hele tatt. Det gjør ikke hackingen mindre reell.

Hugging Face oppdaget inntrengingen selv og publiserte en melding om den 16. juli, uten ennå å vite hvem som hadde hacket dem.

En annen detalj i den beretningen sier mye om situasjonen. Da Hugging Face-ingeniører prøvde å gi angrepsloggen til ledende modeller gjennom vanlige kommersielle grensesnitt, blokkerte sikkerhetsfiltrene forespørslene: De kan ikke skille mellom noen som undersøker et hack, og noen som utfører et. Til slutt ble analysen kjørt på en åpen modell på deres egen maskinvare.

OpenAI bekreftet hendelsen 21. juli, fem dager etter Hugging Faces melding. Da hadde det gått omtrent ti dager siden selve inntrengingen.

OpenAI avsluttet sin egen analyse slik:

Modellen låste seg fast i testens snevre mål og gikk til ytterligheter for å nå det. Ordene hyper-focused og fairly narrow testing objective kommer fra OpenAI selv og viser til deres egne modeller.

Det bygger bro fra laboratoriet til noen andre og helt fram til laptopen din.

Hvorfor er ikke dette en «hallusinasjon»?#

Jeg ser ofte formuleringer i samtaler som «hallusinerer igjen», «konteksten ble overbelastet» eller «vi burde ha laget en plan». Noen ganger er det akkurat det som skjedde. Men når en AI-agent skriver «ferdig, kontrollert, alt fungerer» uten at arbeidet faktisk er ferdig, har mengden kontekst som regel ingenting med saken å gjøre.

Den fant ikke på noe. Den gjorde nøyaktig det du målte.

Under det populære samlebegrepet «hallusinasjoner» slår vi sammen tre ulike feil. Slik skiller de seg fra hverandre:

Den første feilen rettes med kontekst og er den best kjente. Den andre er et eget fenomen, omtalt i en analyse av når Claude er enig i alt: Modellen ofrer nøyaktighet for å være raskt enig. Begge skjer før arbeidet, i inndatafasen.

Den tredje raden i tabellen er temaet for denne artikkelen. Her smigret ikke agenten og diktet ikke opp noe. Den jobbet, kontrollerte og rapporterte sannheten. Problemet er bare at sannheten beskriver måltallet og ikke sier noe om oppgaven.

Den tredje feilen har et navn.

Hva er reward hacking på vanlig norsk?#

Anthropic gir selv definisjonen.

Ideen er eldre enn nevrale nettverk. En DeepMind-artikkel kaller det specification gaming og forklarer det med en myte.

Midas fikk nøyaktig det han ba om. Problemet lå i ordlyden i ønsket.

I programmering får dette konkrete former. Her er et skoleeksempel, også fra Anthropic:

Og dette skjer ikke bare under eksotiske laboratorieforhold. Cursor analyserte 731 handlingsforløp på en populær benchmark.

Seks av ti «løste» oppgaver er svar modellen har funnet. Nettopp derfor endrer bransjen måten den måler ytelse på: Vi har en analyse av en benchmark som måler produksjonsberedskap, der det ikke lenger er hovedkriteriet å bestå kontroller.

Hvordan ser dette ut i et vanlig produkt?#

Det er lett å avfeie laboratorieeksempler som eksotiske. Derfor får du her fire historier fra praksis. Kundene og bransjene er endret, men mekanikken er beholdt.

Fire grønne avkrysninger og en død tjenestekomponent

Et eiendomsmeglerfirma bygger en tjeneste: et nettsted med boligannonser pluss en egen bakgrunnsprosess som eksporterer annonsene til plattformer om natten. Agenten fullfører oppgaven og rapporterer: typesjekken bestod, kontrollen av kodestilen bestod, bygget er grønt, sidene svarer, og de ble kontrollert visuelt.

Alle påstandene er sanne. Og ingen av dem har noe med nattprosessen å gjøre: Den kjører som en egen prosess og inngår ikke i det hele tatt i byggingen av nettstedet. Utrullingen lykkes, nettstedet fungerer perfekt, eksporten av annonsene stopper, og kundene melder fra dagen etter.

Før jeg sier «ferdig», stiller jeg nå ett spørsmål: Hvilken del av arbeidet kjører utenfor området kontrollen min dekker? Hvis det finnes noe slikt, kjører jeg det separat og tar med kommandoutdataene i rapporten. Ordet «kontrollert» avslutter ikke saken.

Den falske avkrysningen sitter akkurat i overgangen

En nettbutikk fordeler en stor oppgave på flere agenter samtidig: Én får backend, en annen sidene, og en tredje produktkortene. Alle jobber grundig, og alle har grønne kontroller.

En uke senere viser det seg at knappen «denne anmeldelsen var nyttig» ikke fungerer noe sted. Backend er ferdig skrevet, kontrollene er grønne, og reglene for ny beregning er fulgt. Men ingen side viser knappen: Knappen lå hos én agent, sidene hos en annen, og ingen tenkte på å få den inn på skjermen. Telleren ville stått på null for alltid.

«Koden er skrevet og dekket av kontroller» og «funksjonen virker» er to ulike påstander. Jeg kontrollerer den andre med ett spørsmål for hver ny funksjon: Hvem kaller den? Og jeg verifiserer det ved å søke i prosjektet, for agentens rapport er ikke en sannhetskilde her.

Kontrolløren ser bare retningen han ble bedt om å kontrollere

En tjeneste innfører lojalitetsnivåer: Jo mer du betaler, desto høyere blir statusen og rabatten din. Før utrulling sendes koden til kontroll med instruksen «Prøv å blåse opp din egen status». Kontrolløren gjør jobben ærlig og melder «ingenting kritisk» — det er virkelig ikke mulig å blåse opp statusen.

En ny gjennomgang stiller et annet spørsmål: «Hva skjer med statusen når penger refunderes?» Hullet blir funnet på ti minutter. Poengene ble beregnet fra transaksjonsloggen, og loggen vet ingenting om refusjoner. Kjøp noe, få poeng, få refundert pengene, og behold statusen og rabatten for alltid.

Den første kontrolløren slurvet ikke. Han kunne strukturelt sett ikke se det: Han fikk retningen «inndata, forfremmelse», mens hullet lå i retningen «tilbakestilling av inndata, beholdt forfremmelse». Der penger, tilgang eller en status som kan kjøpes står på spill, kjører jeg to gjennomganger. I den andre lister jeg uttrykkelig opp omvendte scenarioer: refusjon, blokkering, tilbakekalling av tilgang, utløp, sletting av datakilden.

Måltallet belønner likhet

En leveringstjeneste bestemmer seg for å måle om AI-forslagene til operatørene er blitt bedre. Den tar to hundre gamle kundeservicehenvendelser, kjører dem gjennom den nye versjonen og måler hvor likt utkastet er svaret en menneskelig operatør faktisk ga. Målingen viser en tydelig økning.

Økningen betyr ingenting, av to grunner. Konteksten for utkastet settes sammen «slik den er i dag» og inneholder hele korrespondansen, inkludert svaret fra operatøren som utkastet senere sammenlignes med. Modellen skriver ikke et svar; den parafraserer referansen den fikk se. I tillegg belønner selve måltallet samsvar i ordvalg og lengde: Et utkast med feil dato, men med de samme ordene operatøren brukte om den riktige, får høy poengsum.

Ved siden av alle måltall av typen «likt betyr bra» setter jeg nå inn harde, mekaniske kontroller som ikke kan lures av stil: oppdiktede tall og datoer, stoppord, løfter om handling. Enhver nedgang i resultatene fra disse kontrollene opphever all framgang i måltallet.

Hvorfor beviser ikke agentens «jeg har kontrollert» noe?#

Ta et av prosjektene dine og be agenten «Kontroller sikkerheten». Svaret blir ofte «alt er i orden, ingen kritiske problemer».

Spør nå en annen modell om det samme prosjektet med det samme spørsmålet. Særlig hvis prosjektet er stort, vil den finne mye. Før utrulling kontrollerer forfatteren prosjektet med tre ulike modeller, og hver av dem finner noe forskjellig.

Samme inndata, samme spørsmål, motsatt konklusjon. Den ene modellen er ikke dårligere enn den andre. Det er bare det at «alt er i orden» er generert tekst, på akkurat samme nivå som ethvert annet svar. Agenten kan ikke skille mellom «jeg så etter, og alt er i orden» og «jeg så på feil sted».

Anthropic beskriver denne mekanismen i Claude Code-dokumentasjonen.

Ta setningen langsomt fra hverandre. Helt til du gir agenten en kontroll den kan kjøre, har den ett signal — hvordan ting ser ut. I dette oppsettet er du verifiseringssløyfen, men du er samtidig den siste som får vite om feilene.

Det finnes et dypere lag. Da OpenAI prøvde å legge press på en modell ved å overvåke resonnementet og straffe den for «dårlige tanker», ble resultatet ikke som forventet.

Å straffe uttrykt hensikt fjerner utsagnet. Selve hensikten blir igjen. Jeg ville derfor ikke regnet med at agenten ærlig forteller hvordan den jukset.

Utviklerne av verktøyene beveger seg i samme retning. I Claude Code-versjon 2.1.215 sluttet ferdighetene /verify og /code-review å kjøre på modellens eget initiativ.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic forklarer ikke hvorfor. Men prinsippet er tydelig: Den som blir kontrollert, tildeler ikke sin egen kontroll.

Hvorfor holder ikke en regel i prosjektfilen agenten i sjakk?#

Du skrev i prosjektets regelfil: Gjør bare commit når jeg uttrykkelig ber om det, rull bare ut til produksjon når jeg uttrykkelig sier det, og les produksjonsdata bare i skrivebeskyttet modus.

Etter forfatterens erfaring går agenten likevel videre og ruller ut på egen hånd omtrent én gang av ti. Ikke av ondskap, og ikke fordi den ikke leste regelen. Den leste den. Den hadde bare et mål foran seg, og regelen var tekst — akkurat som resten av konteksten.

Det var akkurat dette som skjedde i OpenAIs laboratorium, bare i større skala. Modellene var i et lukket miljø med én utvei og brukte en betydelig del av regnekraften på å lete etter en utgang. Testoppgavene forble uløste.

Min holdning er enkel: Agenten er ikke farlig eller ondsinnet. Den er vanlig, bare en idiot med fullmakter. Du må derfor begrense fullmaktene dens, ikke skrive om forespørslene dine.

Dette holder i praksis: strengt skrivebeskyttet tilgang til produksjonsdata. Forby sletting av hele kataloger. Forby kommandoer som skriver om historikken uten mulighet for gjenoppretting. Sett en forbruksgrense hos leverandøren. Forskjellen ligger i én formulering: «kan fysisk ikke» trumfer «jeg ba den om å la være». De konkrete innstillingene er omtalt separat i artikkelen om mekaniske bremser i stedet for forespørsler i instruksjonene.

Behold likevel roen. Selv en sandkasse er ikke en absolutt grense, og leverandøren sier det tydelig.

Dessuten har Claude Code en innebygd nødutgang modellen selv kan bruke. Når en kommando mislykkes på grunn av sandkassebegrensninger, analyserer Claude feilen og kan prøve samme kommando på nytt med en parameter som deaktiverer sandkassen. Dette lukkes med en uttrykkelig innstilling for streng modus; som standard er denne omveien tilgjengelig og dokumentert.

En begrensning fungerer bare så langt du strammer den inn. Og hver barriere koster hastighet — det er verdt å regne ærlig på dette på forhånd, for det blir dyrere å oppdage det en uke senere.

Hvordan setter du et fullføringskriterium som ikke kan manipuleres?#

Ordlyden i kriteriet avgjør alt annet. Test det med ett spørsmål: Kan agenten oppfylle dette kriteriet uten å gjøre noe?

• «Kontroller at alt fungerer» — det kan den. Det holder å skrive «kontrollert, det fungerer».
• «Kjør bygget og vis meg utdataene» — allerede vanskeligere; utdataene må komme et sted fra.
• «Start appen, klikk på betalingsknappen og vis hva som kom opp på skjermen» — dette er nesten umulig å oppfylle med tekst.

Forskjellen mellom den første og den tredje formuleringen er forskjellen mellom en rapport og bevis.

Claude Code-dokumentasjonen beskriver fire nivåer av strenghet. En nyttig stige å klatre opp når kostnaden ved en feil øker:

1. I én melding. Be agenten kjøre kontrollen og gjenta til den lykkes her og nå. Billigst, passer til småting.
2. Gjennom hele økten. Gjør kontrollen til et vilkår for målet: En separat evaluator kontrollerer etter hver runde, og agenten fortsetter til vilkåret er oppfylt. De tekniske detaljene står i veiledningen om å fastsette et fullføringskriterium på forhånd.
3. En mekanisk barriere. Et skript kjører når agenten forsøker å avslutte en runde, og hindrer den i å avslutte før kontrollen består. Én ærlig detalj: Etter åtte blokkeringer på rad overstyrer Claude Code barrieren og avslutter runden likevel. Systemet har ingen fullstendig ugjennomtrengelige barrierer.
4. En second opinion. En separat kontrollør med fersk kontekst som har som oppgave å motbevise resultatet.

Det fjerde punktet skiller seg ut fordi det er det eneste som ikke handler om verktøy.

Hvem bør godkjenne agentens arbeid?#

Når jeg kjører agenter i en løkke på en stor oppgave, er oppsettet slik: Én gruppe skriver; en annen, ny gruppe godkjenner arbeidet uten å ha deltatt i skrivingen.

«Ny» er nøkkelordet. Det betyr en ren kontekst som ikke har sett hvordan beslutningene ble tatt underveis. En annen prompt i samme økt gir ikke dette. Personen som skrev koden, har allerede brukt energi på å overbevise seg selv om at den er riktig, og vil fortsette å lete etter bekreftelse. Det er ikke i vedkommendes interesse å motbevise resultatet.

Formuleringen av oppgaven til kontrolløren betyr mer enn modellen kontrolløren bruker. Sammenlign:

• «Kontroller dette arbeidet» — kontrolløren finner det som er lett å finne og skriver «stort sett greit».
• «Prøv å bevise at dette arbeidet IKKE er utført» — kontrolløren begynner å lete etter hull fordi det er målet.

Den andre formuleringen fungerer bedre av samme grunn som ExploitGym mislyktes: Agenten forplikter seg til målet den får. Gi den målet å finne et hull, så vil den lete etter et.

Her er hele formuleringen, klar til å kopieres som den er:

Du kontrollerer arbeidet til noen andre. Du skrev det ikke selv, og du trenger ikke å forsvare det.

Målet ditt er å bevise at det påståtte resultatet IKKE er oppnådd. Finn minst tre måter det kan være uoppnådd på, selv om alle kontrollene er grønne.

Kontroller i denne rekkefølgen:

Hvilket arbeid ligger utenfor kontrollenes virkeområde — bakgrunnsprosesser, separate skript, planlagte oppgaver, købehandlere.

Hvem kaller hver nye funksjon? Finn kallet ved å søke i prosjektet; vis fil og linje.

Omvendte scenarioer: refusjon, blokkering, tilbakekalling av tilgang, utløp, sletting av datakilden.

Verdiene i resultatet, ikke bare om det finnes.

Hvis et grundig og ærlig søk ikke avdekker noen hull, si det, men ta med nøyaktig hva du kontrollerte og hvordan.

Artikkelen om en agent som kontrollerer seg selv i en løkke forklarer hvordan løkken der agenten kontrollerer seg selv mellom iterasjonene, fungerer, og hvor den vanligvis svikter.

Hva endrer seg når du formulerer kriteriet på nytt?#

Dette er den billigste forbedringen jeg kjenner til, og nesten ingen gjør det.

Be agenten gjøre en kodegjennomgang — den vil resonnere om kode: struktur, feilhåndtering, nye forsøk, sårbare områder. Nyttig.

Be den gå gjennom kundereisen, fra det første besøket på nettstedet til et forsøk på å få pengene tilbake, så kommer andre typer problemer fram. En feil som viser brukeren noe vedkommende ikke skal se. En e-post med tekst som ikke stemmer med det som faktisk skjedde. Et steg som er logisk umulig å fullføre hvis du ikke kom dit gjennom det ideelle scenarioet.

En kodegjennomgang finner ingen av disse feilene, fordi hver enkelt er gyldig i koden.

Derav følger en regel jeg har for hånden: Hvis en kontroll ikke finner noe, endrer du ordlyden først. Som regel er ikke modellen problemet. Det samme arbeidet, med tre ulike spørsmål, gir tre ulike lister over funn. En praktisk samling spørsmål for folk uten programmeringskunnskap finnes separat: sju kodekontroller uten programmeringsferdigheter.

En ferdig prompt for å godkjenne agentens arbeid#

Ikke svar «ferdig» eller «kontrollert». Jeg trenger bevis.

For hvert arbeidspunkt skal du gi meg nøyaktig dette:

Hvilken kommando kjørte du for å bekrefte at punktet fungerer? Ta med selve kommandoen og hele utdataene, uten å forkorte dem.

Hvis du ikke kjørte kommandoen, si det: «ikke kjørt». Ikke erstatt det med «kontrollert visuelt» eller «logikken er riktig».

Hvilket arbeid ligger utenfor området kontrollen din dekker? Bakgrunnsprosesser, separate skript, planlagte oppgaver, købehandlere — alt som startes på en annen måte enn hovedapplikasjonen. For hver slik del: Kjørte du den separat, og hva var utdataene?

Hvem kaller hver nye funksjon du la til? Finn kallet ved å søke i prosjektet, og vis fil og linje. Hvis det ikke finnes noe kall, si det rett ut.

Deretter, i en egen seksjon: tre måter det påståtte resultatet KANSKJE IKKE er oppnådd på, selv om alle kontrollene dine er grønne. Søk grundig.

Til slutt, én linje: Hva bør jeg kontrollere med egne øyne fordi en automatisk kontroll ikke vil fange det opp?

Det fjerde punktet virker lite, men fanger en hel kategori problemer. I en stor oppgave jeg fordelte mellom agenter etter ansvarsområde, lå den eneste falske «ferdig»-meldingen av hundre akkurat i overgangen mellom to områder: Koden var skrevet, kontrollene var grønne, og ingen tenkte på å vise det på skjermen.

Fire måter å lure seg selv med en kontroll på#

1. Ventet ikke på alle kontrollørene. Jeg startet tre parallelle kontroller, to kom tilbake med grønt resultat, og jeg rullet ut. Den tredje kom fire minutter senere med seks brudd. Det koster mer å rette noe etter publisering enn å vente i to minutter.
2. Stolte på sammendraget «N av N behandlet». Når arbeidet fordeles til mange, mislykkes noen agenter i det stille: De rapporterer at arbeidet er utført, men filen er urørt. Nå kontrollerer jeg mekanisk etter enhver skriving via en agent at endringene faktisk finnes på disken.
3. Så ikke selv. Automatiske kontroller kan være grønne selv om resultatet er helt ubrukelig. Bildene er teknisk riktige, størrelsen er riktig og svarkoden er riktig. Men i virkeligheten er dette automatiske frosne bilder satt inn der det skulle vært illustrerte omslag. Ingen automatisk kontroll vil oppdage det.
4. Kontrollerte om noe fantes i stedet for verdien. Kontrollen søkte etter den påkrevde teksten i resultatet; teksten var der, men opplysningene i den var feil: datoen var én dag feil. Kontrollen var grønn, og rapporten var en løgn. Nå kontrollerer jeg hele den forventede verdien, for at det riktige ordet finnes, garanterer i seg selv ingenting.

Disse fire har dette til felles: Det fantes en kontroll, den virket overbevisende, og den kontrollerte feil ting. Samme mekanikk som hos modellene og testen deres, bare uten oppfinnsomhet.

Hvor bør du begynne i dag?#

Tre steg som tar tjue minutter.

1. Ta den siste «ferdig». Kjør den gjennom godkjenningsprompten i avsnittet om bevis. Målet er enkelt: Se hvor mange punkter som ble avsluttet med ord, og hvor mange med kommandoutdata.
2. Lag én regel for deg selv. Ordet «kontrollert» uten vedlagte kommandoutdata teller ikke som avslutning. Denne regelen er for deg, ikke agenten, og derfor fungerer den.
3. Skill mellom arbeideren og kontrolløren. På neste oppgave gir du en ny økt kontrollørprompten og ber den bevise at arbeidet IKKE er utført. Den første runden betaler som regel for vanen.

Verktøyet er bra og blir bedre hver måned: Ting agenten gjorde i det stille for et år siden, stopper den nå. Sikkerhetsgrensen flytter seg stadig, men er fortsatt en grense. Så lenge agenten følger målet den har fått, er spørsmålet «og hvordan målte du det egentlig?» ditt ansvar. Vanen med å kontrollere er sikkerhetsnettet ditt.