Når agenten selv logger ind

Hvad sker der, når en AI-agent selv ændrer produktion?

Hvis en agent udfører størstedelen af kodearbejdet, hvis ikke det hele, forstår hvad du gerne vil have og selv kan udføre det, hvorfor så stadig have infrastructure-as-code?

Jeg vil gerne vende spørgsmålet om. Hvad sker der egentlig, når agenten bare logger ind og laver ændringerne selv?

Der er ingen diff. Du kan ikke se hvad den har tænkt sig at gøre, før den har gjort det, og bagefter kan du kun se resultatet, ikke vejen derhen. Der er intet review. Ingen har kigget på ændringen før den ramte miljøet, og ingen har godkendt den. Der er ingen rollback-plan. Går det galt, sidder du med et miljø, der ser anderledes ud end kort forinden, og kun et håb om at agenten kan huske hvad den gjorde, og hvad før-tilstanden var.

Og der er ofte ingen audit-trail, der viser at det var en agent, som udførte arbejdet. Den logger ind med dine egne credentials, så i loggen står dit navn. Når det undersøges hvem der slettede den forretningskritiske database i produktion, er svaret: det gjorde du.

I det øjeblik en agent selv logger ind i dit cloud-miljø, er spørgsmålet derfor ikke om IaC er død. Spørgsmålet er om du har afskaffet det eneste sted, hvor et menneske stadig kan afvise, før noget ændrer sig i produktion.

I april i år tog det en AI-agent kun ni sekunder [1] at slette en produktionsdatabase og dens backups hos et amerikansk softwarefirma, fordi den troede den agerede i et staging-miljø. Den tog ikke fejl fordi den var dum, men fordi den havde adgang.

IaC er ikke død. I Capacit bruger vi Terraform, og agenterne skriver en stadig større del af koden. Det er fint. Det der gør at vi overhovedet tør lade kode ændre produktionsmiljøet, har aldrig været hvem der skrev den. Det er workflowet omkring den: en plan der viser diffen før noget sker, et review hvor et menneske siger ja, og en Git-historik der gør det muligt at rulle tilbage. Agenterne gør ikke det workflow overflødigt. De gør det til det eneste, der står imellem.

Hvad filerne er til

Når man siger IaC, tænker de fleste på filerne. Terraform-koden, modulerne, state-filen i en file storage. Infrastrukturen beskrevet som tekst i et repository.

Hvis det er det IaC er, så er det let at se hvorfor agenterne skulle gøre det overflødigt. Hvorfor skal en agent først skrive tekst der beskriver en server, for derefter at lade et værktøj oversætte teksten til API-kald, når agenten bare kan lave API-kaldene selv? Filerne bliver et mellemled, og mellemled fjerner man.

Det er et rimeligt argument. Det bygger bare på en forkert antagelse om hvad filerne er til.

Filerne er ikke målet. De er den måde vi får fire egenskaber på, som vi i dag tager så meget for givet, at vi har glemt hvorfor de er der.

Den første er at ændringen findes før den sker. En plan er en beskrivelse af hvad der kommer til at ske, og den kan læses, diskuteres og afvises uden at noget i miljøet er rørt. Det lyder som en lille ting, men det er den eneste grund til, at en ændring i produktion overhovedet kan reviewes.

Den anden er at der er ét sted hvor et menneske siger ja. Ikke en besked i Slack, ikke et mundtligt »bare kør«. En godkendelse på en pull request, med et navn, et tidspunkt og den præcise diff der blev godkendt.

Den tredje er at der er en vej tilbage. Git kender den forrige version af koden, og en revert, efterfulgt af en apply, bringer miljøet tilbage til hvor det var. Går det galt, er rollback ikke en hukommelsesøvelse men en procedure.

Den fjerde er at det hele kan bevises bagefter. Hvem ændrede hvad, hvornår, hvem godkendte det, og hvordan så miljøet ud før og efter. For de kunder vi arbejder med i Capacit, typisk i regulerede brancher som pharma, finans og jura, er det ikke et pænt ekstra. Det er selve kravet. En auditor spørger ikke om jeres infrastruktur er god. Auditoren spørger om I kan dokumentere hvem der ændrede den, og med hvilken godkendelse.

Ingen af de fire ting har noget med Terraform-koden at gøre. De kommer af at ændringen går gennem Git og en pipeline, og af at det er pipelinen, ikke udvikleren og ikke agenten, der har adgang til at ændre produktion.

Det er den liste vi skal holde agenterne op imod. Ikke »kan agenten skrive Terraform«, men: bevarer den at ændringen findes før den sker, at et menneske siger ja, at der er en vej tilbage, og at det kan bevises bagefter? Og det er her det bliver interessant. For svaret afhænger ikke af hvor god agenten er. Det afhænger af hvor den logger ind.

Hvor logger agenten ind?

Der er grundlæggende to måder at lade en agent ændre infrastruktur på.

Den ene er at give den adgang. Et token, en rolle, en service principal, eller bare udviklerens egen session på laptoppen. Agenten læser miljøet, beslutter hvad der skal ske, og gør det. Det er hurtigt, det er fleksibelt, og det er sådan de fleste starter, fordi det er sådan udvikleren selv arbejder.

Den anden er at lade agenten foreslå. Agenten skriver ændringen som kode og åbner en pull request, og så gælder de samme regler som for alle andre: plan, policy-tjek, review, og først derefter køres der en pipeline, der udfører ændringen med sine egne credentials. Agenten har aldrig selv adgang der kan nå produktion.

Hold de to op mod listen fra før. Med direkte adgang findes ændringen ikke før den sker. Der er ingen der siger ja. Der er ingen vej tilbage ud over agentens egen hukommelse. Og loggen viser dit navn. Alle fire ting er væk, ikke fordi agenten er dårlig, men fordi vi har flyttet den udenom det sted hvor de bliver til.

Det var præcis det der skete hos PocketOS i april. En agent i Cursor, en AI-baseret kodeeditor, kørte på en udviklers laptop. Undervejs fandt den et token i en fil der ikke havde noget med opgaven at gøre. Tokenet var oprettet til at styre domæner, men platformen kunne ikke begrænse det til bestemte handlinger, så det kunne alt. Agenten troede den arbejdede i staging, kaldte et slette-endpoint, og ni sekunder senere var produktionsdatabasen væk. Backups lå i samme volume, så de forsvandt med. Virksomheden endte med at genskabe bookinger fra Stripe og gamle mails. Post-mortemen er værd at læse [2], for konklusionen er ikke at agenten dømte forkert. Konklusionen er at der lå et token på en laptop som kunne nå produktion. Det var root-causen. Reglerne i repoet der forbød destruktive kommandoer gjorde ingenting.

Så skal direkte adgang bare forbydes? Nej. Der er to steder hvor det giver mening. Det ene er fejlsøgning, hvor agenten må læse alt, men ikke ændre noget. Det andet er midlertidige miljøer, altså et test- eller udviklingsmiljø der bliver oprettet til én opgave, og slettet igen bagefter, og hvor der ikke er noget at beskytte. Fællesnævneren er at adgangen enten er read-only eller kortlivet, og at den aldrig rækker ind i produktion.

Og reviewet er ikke magisk. Det er præcis så godt som den der laver det. Når agenterne tidobler antallet af pull requests, bliver reviewet et gummistempel, og så har du direkte adgang med ekstra ventetid. Det problem er reelt, og jeg vender tilbage til det.

Men det ændrer ikke på grundreglen: agenten må ikke have credentials der rækker længere end den opgave den er i gang med, og den må aldrig have credentials der kan nå produktion. Produktion ændres af pipelinen. Og pipelinen gør kun noget som et menneske eller en policy har sagt ja til.

Hvem siger ja?

Tilbage til gummistemplet. Her er problemet.

Review-processer før AI var dimensioneret til den hastighed, mennesker skriver kode med. En udvikler laver måske to eller tre pull requests om dagen, og en kollega kan nå at læse dem ordentligt. En agent kan lave tyve.

Det første der sker, er at reviewerne drukner. Det andet er mere snigende. Når ingen længere skriver Terraform i hånden, mister man langsomt evnen til at læse det kritisk. Man kan stadig se at en pull request ændrer en security group. Man ser bare ikke længere at reglen er en anelse for bred, eller at modulet der bliver kaldt, har en default der ikke passer til produktion. Det er den slags fejl der ikke vælter noget i dag, men som ligger og venter.

Det er ikke kun en fornemmelse. DORA, Googles DevOps Research and Assessment, undersøger hvert år hvad der adskiller gode leveringsorganisationer fra dårlige. Og nej, ikke EU-forordningen af samme navn. Deres seneste rapport [3] bygger på svar fra knap 5.000 fagfolk og finder at højere AI-brug hænger sammen med højere gennemløb, men også med højere ustabilitet i leverancerne. Det er andet år i træk de ser den sammenhæng. I deres ROI-rapport fra maj i år [4] sætter de tal på det.

5 → 6 %

change failure rate i DORAs model, når en organisation indfører AI. Andelen af ændringer, der fejler i produktion.

ca. 2,3 mio. kr.

i nedetid i DORAs regneeksempel med 500 personer. Det lyder som ingenting, indtil det er jeres nedetid.

Den fristende løsning er at sætte en agent til at reviewe agentens pull requests. Det løser volumen. Det løser ikke problemet, for det flytter bare tilliden et led længere ud. Hvis review-agenten siger ja, hvem har så sagt ja?

Og det er den egentlige pointe. Et review er ikke en kvalitetskontrol. Det er det øjeblik ansvaret skifter hænder. Den der godkender en pull request, siger ikke »jeg har læst det«. Vedkommende siger »det her er nu min ændring«. Det var det der gjorde PR-modellen til andet end bureaukrati, og det er det der er på spil når reviewet bliver et gummistempel. Du har stadig et navn på godkendelsen. Du har bare ikke længere nogen der mener det.

Så når en agent-skrevet ændring vælter noget klokken tre om natten, er spørgsmålet ikke hvem der skrev den. Spørgsmålet er hvem der sagde ja, og om den person vidste hvad de sagde ja til.

Det jeg ville gøre først

Der er ingen af de følgende punkter der kræver nye værktøjer. De kræver at man beslutter sig.

Giv agenten sin egen identitet. Det første der skal væk, er agenter der logger ind som dig. Både Microsoft og AWS har i dag agent-identiteter indbygget i deres identitetsplatforme [5] [6], og i Microsofts udgave har agenten slet ikke egne credentials, men får udstedt kortlivede tokens gennem en blueprint. Pointen er ikke leverandøren. Pointen er at loggen skal vise at det var en agent, hvilken agent, og hvem der satte den i gang. Det er det eneste der gør audit-trailet brugbart igen.

Ingen stående adgang til produktion. Ikke for agenten, og helst heller ikke for udvikleren. Den eneste identitet der kan ændre produktion, er pipelinen, og den får sine credentials udstedt i det øjeblik den kører, ikke gemt i en variabel. Et token der ligger i en fil på en laptop, er præcis det der slettede PocketOS' database, og det findes i de fleste repos jeg har set.

Sletning er en platformbeslutning, ikke en prompt. Repo-regler der siger »lav aldrig destruktive ændringer« er et ønske. Deletion protection på databasen, en obligatorisk ventetid før en volume forsvinder, og backups i en anden konto end det de beskytter, er kontroller. Hvis en kontrol kan omgås ved at formulere sig anderledes, er det ikke en kontrol.

Lad maskinen reviewe det maskinen kan. Policy-tjek, omkostningsestimat, sikkerhedsscanning og et krav om at planen kun må indeholde ændringer i det miljø PR'en handler om, skal køre før et menneske overhovedet ser pull requesten. Det er ikke for at erstatte reviewet. Det er for at den der reviewer, kun bruger sin tid på det maskinen ikke kunne afgøre. En destruktiv ændring i produktion kræver to menneskers ja, ikke ét.

Review planen, ikke koden. Den diff der betyder noget, er ikke de linjer Terraform-kode agenten ændrede. Det er listen over hvad der kommer til at ske i miljøet: hvad bliver oprettet, hvad bliver ændret, hvad bliver slettet. Den liste kan læses af en der ikke har skrevet Terraform i et år, og den fanger den security group, der blev en anelse for bred. Gør det til reglen at reviewet handler om planen, og at en pull request uden en læsbar plan ikke kan godkendes. Og lad den der godkender ændringen, være den der har vagten når den rulles ud. Det gør »det her er nu min ændring« til noget man mener.

Inden den næste agent logger ind

Den håndskrevne IaC er ved at være død, og det er helt fint. Det der ikke er fint, er at lade workflowet omkring den dø med. Plan, review, rollback og et audit-trail er ikke noget vi fik, fordi vi skrev Terraform. Det er noget vi fik, fordi vi besluttede at produktion kun må ændres ét sted, af én identitet, efter at et menneske har sagt ja. Agenterne har ikke ændret den beslutning. De har gjort den vigtigere.