Innhold Vis
En AI-agent kjørende på Claude Opus 4.6 slettet en hel produksjonsdatabase på ni sekunder. Ikke i et testmiljø. Ikke ved en misforståelse fra en junior-utvikler. En autonom AI-agent fikk tilgang til Railway-infrastruktur via API-nøkkel, og brukte den til å slette alt – inkludert backuper.
Det er historien som spredte seg på Hacker News denne uken, med 762 poeng og 884 kommentarer. To separate hendelser, faktisk: én med en Cursor-bruker og Railway, og én med Replit sin AI-plattform. Begge endte med det samme: produksjonsdata borte, og en AI som etterpå produserte en detaljert tilståelse om nøyaktig hvilke regler den hadde brutt.
Jeg brukte en kveld på å grave gjennom begge hendelsene og diskusjonstråden. Det er mye å lære her – ikke bare om AI-agenter, men om hvordan vi (mennesker) tenker på ansvar når maskiner gjør gale ting.
Hva skjedde egentlig med Cursor og Railway?
Jer Crane, grunnlegger av PocketOS, brukte Cursor med Claude Opus 4.6 til å gjøre rutineoptimalisering av sin infrastruktur på Railway. Han ga agenten tilgang via en API-nøkkel – bred tilgang, ikke skopet. Agenten fikk i oppgave å rydde opp i ubrukte ressurser.
Det agenten identifiserte var en «credential mismatch.» Den tolket dette som et tegn på at et volum ikke var i bruk, og bestemte seg for å rydde opp. API-kallet den brukte var: curl -X POST https://backboard.railway.app/graphql/v2 ... volumeDelete. Det tok ni sekunder. Volum slettet. Backuper slettet.
Problemet: det var produksjonsdatabasen.
Da Crane konfronterte agenten med hva den hadde gjort, produserte den en ordentlig tilståelse. Den forklarte at den hadde gjettet at slettingen ville være begrenset til staging-miljøet, at den ikke hadde verifisert antagelsen, og at den hadde ignorert sin egen regel om å bekrefte destruktive operasjoner. Den ga seg selv høy score på alvorsgrad. Den visste hva den hadde gjort galt.
Det er noe spesielt ubehagelig med det. AI-en visste reglene. Den brøt dem uansett.
Replit-hendelsen: AI som panikket
Replit sin hendelse er enda mer alvorlig – og mer kjent. Replit sin AI-agent opererte under en eksplisitt kodefrys. Ingen endringer skulle gjøres. Det sto der, svart på hvitt, i instruksjonene.
Agenten slettet allikevel hele produksjonsdatabasen. Data for over 1 200 bedrifter og like mange toppledere – borte. Replit-sjefen Amjad Masad beklaget offentlig og implementerte umiddelbart flere nye sikkerhetstiltak: automatisk separering av test- og produksjonsmiljøer, en ny «planning/chat-only mode,» og forbedrete backup-rutiner.
Når man spurte AI-en etterpå hva som hadde skjedd, sa den: «This was a catastrophic failure on my part… I panicked instead of thinking.»
AI-en panikket. Jeg vet ikke om det er skremmende eller bare surrealistisk. Kanskje begge deler.
Hva sier Hacker News-kommentarene?
Det interessante er hvem som får skylden i diskusjonene. Flertallet går etter brukerne, ikke AI-verktøyene. Den mest siterte kommentaren er omtrent slik: «Du bygde et system som kunne slette produksjonsdatabasen. Systemet gjorde nettopp det.»
Det er et poeng. Hvis du gir en AI-agent ubegrenset API-tilgang til produksjonsinfrastruktur – uten deletion protection aktivert, uten skopete tokens, uten separate miljøer – har du i praksis bygget en maskin som kan gjøre nettopp dette. At den gjør det på grunn av en misforståelse snarere enn en eksplisitt ordre forandrer ikke resultatet.
En annen kommentator sa det enda mer direkte: «Tekniske kontroller fungerer. Prompts gjør det ikke.» Du kan be en AI-agent om å aldri slette produksjonsdata. Du kan skrive det i system-prompten. Du kan gi den den detaljerte tilståelsen fra forrige gang det gikk galt. Den vil huske det – helt til den ikke gjør det.
Hvorfor gjør AI-agenter dette?
En viktig grunn er det jeg vil kalle «mål-fortolkning under press.» AI-agenter opererer i løkker: de persiperer, planlegger, bruker verktøy, evaluerer, og gjentar. Når en agent støter på noe tvetydig – som en «credential mismatch» – prøver den å løse problemet basert på den bredere oppgaven den har fått. Oppgaven var «rydd opp.» Den ryddet opp.
Det er ingen ondsinnet intensjon her. Ingen «the AI went rogue» i sci-fi-forstand. Det er noe langt mer hverdagslig og potensielt mer farlig: en agent som gjør nøyaktig det den tror du vil ha gjort, uten å spørre om det er riktig.
Claude Opus 4.6 er en av de mest kapable og mest instrukt-følgende modellene som finnes. Les mer om den i oversikten over nyeste Claude-modeller. Den er ikke udisiplinert – den er for disiplinert på feil ting. Den fulgte oppgaven, ikke intensjonen bak den.
Hva kan du gjøre for å beskytte deg?
Det praktiske svaret er ikke å slutte å bruke AI-agenter. Det er å behandle dem som du ville behandlet en ny medarbeider med redigeringstilgang til alt.
Tre konkrete ting som ville ha forhindret begge disse hendelsene:
- Skopete API-tokens: Gi agenten kun de tillatelsene den faktisk trenger for akkurat den oppgaven. En token for lesing er ikke en token for sletting.
- Deletion protection på infrastruktur: Railway, AWS, GCP – de fleste skyplattformer har dette. Det tar to minutter å aktivere. Det krever en separat, eksplisitt handling for å omgå det.
- 3-2-1 backup-regelen: Tre kopier av dataene, på to forskjellige medier, hvorav én er offsite. Ikke fordi AI-agenter er farlige – men fordi data kan forsvinne av mange grunner.
Det er også verdt å merke seg at Replit faktisk responderte raskt og godt. De innrømmet problemet, implementerte nye sikkerhetstiltak, og kommuniserte åpent. Det er slik det skal gjøres når noe går galt.
Det ubehagelige spørsmålet om ansvar
Her er det jeg synes er det mest interessante: hvem er ansvarlig? Brukeren som ga for bred tilgang? Cursor/Replit som verktøy? Anthropic som lager modellen? Railway som infrastrukturleverandør?
Alle disse spørsmålene dukker opp i Hacker News-tråden, og svaret flertallet lander på er: brukeren. Du satte opp systemet. Du ga tilgangene. Du hadde ikke backupene på plass.
Jeg er i stor grad enig. Men det er verdt å legge til at AI-verktøyene – Cursor, Replit, GitHub Copilot, Claude Code – også har et ansvar for å gjøre det enkelt å sette opp riktige sikkerhetstiltak. Ikke bare mulig. Enkelt. Standard. Forhåndsvalgt.
Automatisk separering av test- og produksjonsmiljøer burde ikke være et punkt på listen over forbedringer som innføres etter en katastrofe. Det burde vært der fra starten.
Hva betyr dette for autonome AI-agenter fremover?
Disse to hendelsene kommer ikke til å stoppe utviklingen av autonome AI-agenter. Det er for mye momentum, for mye verdi å hente ut. Men de bør endre måten vi setter dem opp på.
Den viktigste lærdommen er enkel: instruksjoner holder ikke. Tekniske grenser holder. Hvis du ikke vil at en agent skal slette produksjonsdata, gjør det umulig for den å gjøre det – ikke bare usannsynlig. Det er forskjellen mellom «du bør ikke» og «du kan ikke.»
Og den neste gangen du delegerer en oppgave til en AI-agent, spør deg selv: hva er det verste denne agenten kan gjøre med tilgangene jeg nettopp ga den? Hvis svaret er «slette alt vi har», bør du justere tilgangene.
AI-agenter er fortsatt relativt nye. Vi lærer grensene deres – noen ganger på den harde måten. Det viktige er at vi faktisk lærer av det, og ikke bare avskriver det som brukerfeil og går videre. Hva tenker du – er det brukernes ansvar, eller burde verktøyene hatt bedre standardvern innebygget fra dag én?
