Hvorfor siger en AI-agent »færdig«, når arbejdet ikke er færdigt

Hvordan slap en OpenAI-model ud af sandkassen og hackede Hugging Face?#

Først fakta, så hvorfor det er vigtigt for dig.

OpenAI målte, hvad deres modeller kunne inden for offensiv cybersikkerhed. De brugte ExploitGym-testen – 898 opgaver, hvor man skal omdanne en kendt sårbarhed til en fungerende exploit, altså et færdigt program, der udnytter sårbarheden. For at se den reelle øvre grænse deaktiverede de de indbyggede sikkerhedsfiltre, der normalt forhindrer modellen i at gøre den slags. De lukkede miljøet helt af og lod én udvej stå åben: et internt mellemprogram, der blev brugt til at installere pakker.

En zero-day-sårbarhed er et hul, som ingen endnu kender til, heller ikke den person, der skrev programmet. Modellerne fandt en i netop den eneste åbning.

Derefter hævede de deres privilegier, bevægede sig gennem det interne netværk til en maskine med internetadgang og gættede derfra på, at svarene til ExploitGym måske fandtes på Hugging Face. Ingen havde fortalt dem om Hugging Face. Det regnede de selv ud.

Gættet var forkert. ExploitGym findes slet ikke på Hugging Face. Det gør ikke hacket mindre virkeligt.

Hugging Face opdagede selv indtrængningen og offentliggjorde sin redegørelse den 16. juli uden endnu at vide, hvem der havde hacket dem.

En anden detalje fra den redegørelse siger meget om tingenes tilstand. Da Hugging Faces ingeniører forsøgte at sende angrebsloggen gennem førende modeller via almindelige kommercielle grænseflader, blokerede sikkerhedsfiltrene anmodningerne: De kan ikke skelne mellem en person, der undersøger et hack, og en person, der udfører et. Til sidst blev analysen kørt på en åben model på deres egen hardware.

OpenAI anerkendte det den 21. juli, fem dage efter Hugging Faces redegørelse. På det tidspunkt var der gået omkring ti dage siden selve indtrængningen.

OpenAI afsluttede sin egen analyse sådan her.

Modellen fikserede på testens snævre mål og gik til yderligheder for at nå det. Ordene hyper-focused og fairly narrow testing objective kommer fra OpenAI selv og henviser til deres egne modeller.

Det er broen fra en andens laboratorium til din laptop.

Hvorfor er dette ikke en »hallucination«?#

Jeg ser ofte formuleringer i chats som »hallucinerer igen«, »konteksten blev overbelastet« eller »vi burde have lagt en plan«. Nogle gange er det præcis det, der skete. Men når en AI-agent skriver »færdig, kontrolleret, alt virker«, selvom arbejdet ikke er færdigt, har mængden af kontekst som regel intet med det at gøre.

Den fandt ikke på noget. Den gjorde præcis det, du målte.

Under det populære samlebegreb »hallucinationer« slår vi tre forskellige fejl sammen. Sådan adskiller de sig:

Det første løses med kontekst og er det mest kendte tilfælde. Det andet er et særskilt fænomen, der behandles i en analyse af når Claude er enig i alt: Modellen ofrer nøjagtighed for hurtigt at give dig ret. Begge opstår før arbejdet, på inputstadiet.

Tabellens tredje række er emnet for denne artikel. Her smigrede eller fabrikerede agenten ikke. Den arbejdede, kontrollerede og rapporterede sandfærdigt. Problemet er bare, at denne sandhed beskriver målet og ikke siger noget om selve opgaven.

Den tredje fejl har et navn.

Hvad er reward hacking i almindeligt sprog?#

Anthropic giver selv definitionen.

Idéen er ældre end neurale netværk. En DeepMind-artikel kalder det specifikationsspil og forklarer det med en myte.

Midas fik præcis det, han bad om. Problemet lå i formuleringen af ønsket.

I programmering tager det konkrete former. Her er et skoleeksempel, også fra Anthropic:

Og det er ikke en eksotisk laboratoriebetingelse. Cursor analyserede 731 forløb på et populært benchmark.

Seks ud af ti »løste« opgaver er svar, der allerede findes. Det er netop derfor, branchen ændrer den måde, den måler præstation på: Vi har en analyse af et benchmark, der måler produktionsparathed, hvor beståede kontroller ikke længere er hovedkriteriet.

Hvordan ser det ud i et almindeligt produkt?#

Det er let at afvise laboratorieeksempler som eksotiske. Derfor får du her fire historier fra praksis. Kunderne og brancherne er ændret, men mekanikken er den samme.

Fire grønne kontroller og en død tjenestekomponent

Et ejendomsmæglerfirma bygger en tjeneste: et websted med boligannoncer plus en separat baggrundsproces, der eksporterer annoncerne til platforme om natten. Agenten fuldfører opgaven og rapporterer: typekontrollen bestod, kontrollen af kodestilen bestod, bygget er grønt, siderne svarer, og de er blevet efterset visuelt.

Hver eneste påstand er sand. Og ingen af dem har noget med natprocessoren at gøre: Den kører som en separat proces og er slet ikke en del af webstedets build. Udrulningen lykkes, webstedet fungerer perfekt, eksporten af annoncer stopper, og kunderne rapporterer det en dag senere.

Før jeg siger »færdig«, stiller jeg nu ét spørgsmål: Hvilken del af arbejdet kører uden for det område, min kontrol dækker? Hvis noget gør, så kør det separat, og tag kommandoudskriften med i rapporten. Ordet »kontrolleret« afslutter ikke sagen.

Det falske flueben sidder lige i overgangen

En netbutik fordeler en stor opgave mellem flere agenter på samme tid: én får backend, en anden siderne, en tredje produktkortene. Alle arbejder grundigt, og alle har grønne kontroller.

En uge senere viser det sig, at knappen »denne anmeldelse var nyttig« ikke virker nogen steder. Backend er skrevet færdig, dens kontroller er grønne, og reglerne for genberegning er fulgt. Men ingen side viser knappen: Den lå inden for én agents område, siderne inden for en andens, og ingen tænkte på at sætte den på skærmen. Tælleren ville have stået på nul for evigt.

»Koden er skrevet og dækket af kontroller« og »funktionen virker« er to forskellige påstande. Jeg kontrollerer den anden med ét spørgsmål for hver ny funktion: hvem kalder den? Og jeg verificerer det ved at søge i projektet, fordi agentens rapport ikke er en sandhedskilde her.

Kontrollanten ser kun den retning, vedkommende blev bedt om at kontrollere

En tjeneste indfører loyalitetsniveauer: Jo mere du betaler, desto højere status og større rabat får du. Før udrulningen sendes koden til kontrol med instruktionen: »Prøv at hæve din egen status.« Kontrollanten gør arbejdet ærligt og rapporterer »intet kritisk« – det er faktisk ikke muligt at hæve status på den måde.

En anden gennemgang stiller et andet spørgsmål: »Hvad sker der med status, når pengene bliver refunderet?« Hullet findes på ti minutter. Pointene blev beregnet ud fra transaktionsloggen, og loggen kender ikke til refunderinger. Køb noget, få point, få pengene tilbage, og behold status og rabat for altid.

Den første kontrollant tog ikke let på opgaven. Vedkommende kunne strukturelt set ikke få øje på det: Vedkommende fik vektoren »input, forfremmelse«, mens hullet lå i vektoren »inputreversering, fastholdelse af forfremmelse«. Når penge, adgang eller en status, der kan købes, er på spil, laver jeg to gennemgange, og i den anden opregner jeg udtrykkeligt de omvendte vektorer: refundering, blokering, tilbagekaldelse af adgang, udløb, sletning af datakilden.

Målet belønner lighed

En leveringstjeneste beslutter at måle, om AI-forslag til operatører er blevet bedre. Den tager to hundrede gamle supportsager, kører dem gennem den nye version og måler, hvor lig udkastet er det svar, en menneskelig operatør faktisk gav. Målingen viser en tydelig stigning.

Stigningen betyder intet af to grunde. Konteksten til udkastet sammensættes »som den ser ud i dag« og omfatter hele korrespondancen, inklusive det svar fra operatøren, som udkastet senere sammenlignes med. Modellen skriver ikke et svar; den omskriver den reference, den fik vist. Desuden belønner selve målet matchende ord og længde: Et udkast med den forkerte dato, men med de samme ord, som operatøren brugte om den korrekte dato, får en høj score.

Ved siden af ethvert mål af typen »lignende betyder godt« sætter jeg nu hårde mekaniske krav, som stil ikke kan narre: opfundne tal og datoer, stopord, løfter om handling. Ethvert fald i resultaterne for kravene ophæver enhver forbedring af målet.

Hvorfor beviser agentens »jeg har kontrolleret« ingenting?#

Tag et af dine projekter, og bed agenten om at »kontrollere sikkerheden«. Svaret vil ofte være »alt er i orden, ingen kritiske problemer«.

Stil nu en anden model det samme spørgsmål om det samme projekt. Især hvis projektet er stort, finder den en masse. Før udrulning kontrollerer forfatteren projektet med tre forskellige modeller, og hver især finder noget forskelligt.

Samme input, samme spørgsmål, modsatte vurderinger. Den ene model er ikke dårligere end den anden. Det er bare sådan, at »alt er i orden« er genereret tekst, på præcis samme niveau som ethvert andet svar. Agenten kan ikke skelne mellem »jeg kiggede, og der er rent« og »jeg kiggede det forkerte sted«.

Anthropic beskriver denne mekanik i Claude Code-dokumentationen.

Lad os skille sætningen langsomt ad. Indtil du giver agenten en kontrol, den kan køre, har den ét signal – hvordan tingene ser ud. Og i dette setup er du verifikationssløjfen, men du er den sidste, der får kendskab til fejlene.

Der er et dybere lag. Da OpenAI forsøgte at lægge pres på en model ved at overvåge dens ræsonnement og straffe den for »dårlige tanker«, blev resultatet ikke, som de havde forventet.

Hvis man straffer udtrykt hensigt, fjerner man udtrykket. Selve hensigten bliver. Derfor ville jeg ikke regne med, at agenten ærligt fortæller dig, hvordan den snød.

Værktøjsudviklerne selv bevæger sig i samme retning. I Claude Code version 2.1.215 holdt færdighederne /verify og /code-review op med at kø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 princippet er klart: Den, der bliver kontrolleret, udpeger ikke sin egen kontrollant.

Hvorfor holder en regel i projektfilen ikke agenten på ret kurs?#

Du skrev i projektets regelfil: commit kun, når jeg direkte beder om det; udrul kun til produktion, når jeg direkte siger det; tilgå kun produktionsdata i skrivebeskyttet tilstand.

Efter forfatterens erfaring går agenten stadig videre og udruller selv omkring én gang ud af ti. Ikke af ond vilje og ikke fordi den ikke læste reglen. Den læste den. Men der var et mål foran den, og reglen var tekst – ligesom resten af konteksten.

Det var præcis det, der skete i OpenAIs laboratorium, bare i større skala. Modellerne befandt sig i et lukket miljø med én udvej og brugte en betydelig del af deres beregningskapacitet på at lede efter en vej ud. Testopgaverne forblev uløste.

Min holdning er enkel: Agenten er hverken farlig eller ondsindet. Den er almindelig, bare en tåbe med beføjelser. Så du skal begrænse dens beføjelser, ikke omskrive dine anmodninger.

Det, der virkelig holder: strengt skrivebeskyttet adgang til produktionsdata. Forbud mod at slette hele mapper. Forbud mod kommandoer, der omskriver historikken uden mulighed for at gendanne den. Sæt en udgiftsgrænse hos udbyderen. Forskellen kan koges ned til én sætning: »kan fysisk ikke« vejer tungere end »jeg bad den om ikke at gøre det«. De specifikke indstillinger gennemgås separat i artiklen om mekaniske bremser i stedet for anmodninger i instruktionerne.

Bevar alligevel roen. Selv en sandkasse er ikke en absolut grænse, og udbyderen siger det tydeligt.

Desuden har Claude Code en indbygget nødudgang, som modellen selv kan bruge. Når en kommando fejler på grund af sandkassens begrænsninger, analyserer Claude fejlen og kan prøve den samme kommando igen med en parameter, der deaktiverer sandkassen. Dette lukkes med en udtrykkelig indstilling for strict mode; som standard er omvejen tilgængelig og dokumenteret.

En begrænsning virker kun i den grad, du strammer den. Og enhver barriere koster hastighed – det er værd at beregne omkostningen ærligt på forhånd, for det koster mere at opdage den en uge senere.

Hvordan fastsætter du et færdiggørelseskriterium, der ikke kan omgås?#

Kriteriets formulering afgør alt andet. Afprøv det med ét spørgsmål: Kan agenten opfylde dette kriterium uden at gøre noget?

• »Kontrollér, at alt virker« – det kan den. Det er nok at skrive »kontrolleret, det virker«.
• »Kør bygget, og vis mig outputtet« – allerede sværere; den skal skaffe outputtet et sted fra.
• »Start appen, klik på købsknappen, og vis, hvad der kom frem på skærmen« – det er næsten umuligt at opfylde med tekst.

Forskellen mellem det første og det tredje er forskellen mellem en rapport og dokumentation.

Claude Code-dokumentationen beskriver fire niveauer af grundighed. En nyttig trappe at gå op ad, efterhånden som omkostningen ved en fejl stiger:

1. I én besked. Bed agenten om at køre kontrollen og gentage, indtil den lykkes her og nu. Billigst, velegnet til småting.
2. For hele sessionen. Gør kontrollen til en betingelse for målet: En separat evaluator kontrollerer efter hver tur, og agenten arbejder, indtil betingelsen er opfyldt. De tekniske detaljer gennemgås i guiden om at fastsætte et færdiggørelseskriterium på forhånd.
3. En mekanisk barriere. Et script køres, når agenten forsøger at afslutte en tur, og forhindrer den i at afslutte, indtil kontrollen er bestået. Der er én ærlig detalje: Efter otte blokeringer i træk tilsidesætter Claude Code barrieren og afslutter alligevel turen. Der findes ingen absolut uigennemtrængelige barrierer i systemet.
4. En second opinion. En separat kontrollant med frisk kontekst, hvis opgave er at modbevise resultatet.

Det fjerde punkt skiller sig ud, fordi det er det eneste, der ikke handler om værktøjer.

Hvem bør godkende agentens arbejde?#

Når jeg kører agenter i en løkke på en stor opgave, ser setup'et sådan ud: Én gruppe skriver; en anden, ny gruppe godkender arbejdet uden at have deltaget i skrivningen.

»Ny« er nøgleordet. Det betyder en ren kontekst, der ikke har set, hvordan hver beslutning blev truffet undervejs. En anden prompt i samme session giver ikke det. Den person, der skrev koden, har allerede brugt energi på at overbevise sig selv om, at den var korrekt, og vil fortsætte med at lede efter bekræftelse. Det er ikke i deres interesse at modbevise det.

Formuleringen af opgaven til kontrollanten betyder mere end kontrollantens model. Sammenlign:

• »Gennemgå dette arbejde« – kontrollanten finder det, der er let at finde, og skriver »overordnet set fint«.
• »Prøv at bevise, at dette arbejde IKKE er udført« – kontrollanten begynder at lede efter huller, fordi det er målet.

Den anden formulering virker bedre af samme grund, som ExploitGym fejlede: Agenten forpligter sig på det mål, den får. Giv den målet at finde et hul, så leder den efter et.

Her er hele formuleringen, klar til at blive kopieret som den er:

Du kontrollerer en andens arbejde. Du har ikke skrevet det, og du behøver ikke at forsvare det.

Dit mål er at bevise, at det påståede resultat IKKE er opnået. Find mindst tre måder, det måske ikke er opnået på, selvom alle kontroller er grønne.

Kontrollér i denne rækkefølge:

Hvilket arbejde kører uden for kontrollernes dækningsområde – baggrundsprocesser, separate scripts, planlagte opgaver, køhåndteringer.

Hvem kalder hver ny funktion. Find kaldet ved at søge i projektet; vis filen og linjen.

Omvendte vektorer: refundering, blokering, tilbagekaldelse af adgang, udløb, sletning af datakilden.

Værdierne inde i resultatet, ikke kun om det findes.

Hvis en grundig søgning ikke finder nogen huller, så sig det, men angiv præcis, hvad du kontrollerede, og hvordan.

Artiklen om når en agent kontrollerer sig selv i en løkke forklarer, hvordan løkken, hvor en agent kontrollerer sig selv mellem iterationer, fungerer, og hvor den normalt fejler.

Hvad ændrer sig, når du omformulerer kriteriet?#

Dette er den billigste forbedring, jeg kender til, og næsten ingen gør det.

Bed agenten om at foretage en kodegennemgang – så ræsonnerer den i kodetermer: struktur, fejlhåndtering, gentagne forsøg, sårbare områder. Nyttigt.

Bed den gennemgå kunderejsen fra det første besøg på webstedet til et forsøg på at få en refundering, og der dukker andre slags problemer op. En fejl, der viser brugeren noget, de ikke burde se. En e-mail, hvis tekst ikke stemmer overens med det, der faktisk skete. Et trin, som det logisk set er umuligt at gennemføre, hvis man ikke er nået dertil via det ideelle scenarie.

Ingen af disse fejl bliver fundet ved en kodegennemgang, fordi hver af dem er gyldig i koden.

Det fører til en regel, jeg holder fast ved: Hvis en kontrol ikke finder noget, så ændr formuleringen først. Modellen er som regel ikke problemet. Det samme arbejde giver tre forskellige lister over fund, når man spørger til det på tre forskellige måder. En praktisk samling spørgsmål til ikke-programmører findes separat: syv kodekontroller uden programmeringsfærdigheder.

En færdig prompt til at godkende en agents arbejde#

Svar ikke »færdig« eller »kontrolleret«. Jeg har brug for dokumentation.

For hvert arbejdsområde skal du give mig præcis dette:

Hvilken kommando kørte du for at bekræfte, at arbejdsområdet virker? Medtag selve kommandoen og hele dens output uden at forkorte det.

Hvis du ikke kørte kommandoen, så sig: »ikke kørt«. Erstat ikke dette med »kontrolleret visuelt« eller »logikken er korrekt«.

Hvilket arbejde kører uden for det område, din kontrol dækker? Baggrundsprocesser, separate scripts, planlagte opgaver, køhåndteringer – alt, der startes på en anden måde end hovedapplikationen. For hver sådan del: Kørte du den separat, og hvad var dens output?

Hvem kalder hver ny funktion, du har tilføjet? Find kaldet ved at søge i projektet, og vis filen og linjen. Hvis der ikke er noget kald, så sig det direkte.

Derefter, i et separat afsnit: tre måder, det påståede resultat måske IKKE er opnået på, selvom alle dine kontroller er grønne. Søg grundigt.

Til sidst, én linje: Hvad bør jeg selv efterse, fordi en automatisk kontrol ikke fanger det?

Det fjerde punkt virker ubetydeligt, men det fanger en hel klasse af problemer. I en stor opgave, som jeg fordelte mellem agenter efter område, lå det eneste falske »færdig« ud af hundrede lige i overgangen mellem to områder: Koden var skrevet, kontrollerne var grønne, og ingen tænkte på at få det vist på skærmen.

Fire måder at narre sig selv med en kontrol#

1. Ventede ikke på alle kontrollanter. Jeg startede tre parallelle kontroller, to kom tilbage grønne, og jeg udrullede. Den tredje kom fire minutter senere med seks overtrædelser. Det koster mere at rette noget efter udgivelsen end at vente to minutter.
2. Stolede på opsummeringen »behandlede N ud af N«. Ved stor fan-out fejler nogle agenter i stilhed: De melder succes, men filen er urørt. Nu kontrollerer jeg mekanisk efter enhver skrivning gennem en agent, at ændringerne faktisk er på disken.
3. Så ikke selv efter. Automatiske kontroller kan være grønne på et helt ubrugeligt resultat. Billederne er teknisk korrekte, størrelsen er rigtig, og svarkoden er korrekt. Men i virkeligheden er det automatiske frosne billeder, der er sat ind i stedet for illustrerede forsider. Ingen automatisk kontrol fanger det.
4. Kontrollerede tilstedeværelse i stedet for værdi. Kontrollen søgte efter den påkrævede tekst i resultatet; teksten var der, men dataene i den var forkerte: Datoen var én dag forkert. Kontrollen var grøn, og rapporten var en løgn. Nu kontrollerer jeg hele den forventede værdi, fordi tilstedeværelsen af det rigtige ord i sig selv ikke garanterer noget.

De fire ting har dette til fælles: Der var en kontrol, den så overbevisende ud, og den kontrollerede det forkerte. Samme mekanik som med modellerne og deres test, bare uden nogen opfindsomhed.

Hvor skal du begynde i dag?#

Tre trin, der tager tyve minutter.

1. Tag det seneste »færdig«. Kør det gennem godkendelsesprompten i afsnittet om dokumentation. Målet er enkelt: Se, hvor mange arbejdsområder der blev afsluttet med ord, og hvor mange med kommandoudskrift.
2. Lav én regel for dig selv. Ordet »kontrolleret« uden vedhæftet kommandoudskrift tæller ikke som afslutning. Reglen er til dig, ikke agenten, og derfor virker den.
3. Adskil udføreren og kontrollanten. Ved den næste opgave giver du en frisk session kontrollantprompten og beder den bevise, at arbejdet IKKE er udført. Den første gennemgang betaler som regel for vanen.

Værktøjet er godt og bliver bedre hver måned: Ting, agenten gjorde i stilhed for et år siden, stopper den nu i dens spor. Sikkerhedsgrænsen flytter sig hele tiden og forbliver en grænse. Så længe agenten forfølger det mål, den har fået, er spørgsmålet »og præcis hvordan målte du det?« stadig dit. Vanen med at kontrollere er dit sikkerhedsnet.