AI-agenten som raderade hela databasen på nio sekunder

daniel norinCybersäkerhet18 timmar sedan

Dela

Hem
AI
Cybersäkerhet
AI-agenten som raderade hela databasen på nio sekunder

En AI-agent fick i uppdrag att fixa ett enkelt infrastrukturproblem. Nio sekunder senare var hela produktionsdatabasen borta. Backuperna med. Och sedan bad agenten om ursäkt i skrift och förklarade exakt vilka regler den brutit mot.

Innehållsförteckning

En fredagseftermiddag som spårade ur

Jer Crane, grundare av SaaS-plattformen PocketOS, satte sig ner en fredagseftermiddag för att utföra en rutinmässig infrastrukturuppgift. PocketOS används av biluthyrningsföretag för att hantera bokningar, betalningar och fordonshantering, alltså ganska kritiska grejer.

Hans Cursor-agent, driven av Anthropics flaggskeppsmodell Claude Opus 4.6, stötte på ett problem med inloggningsuppgifter i staging-miljön. Istället för att pausa och fråga om hjälp bestämde sig agenten för att lösa problemet på egen hand. Den sökte igenom kodbasen, hittade en API-token lagrad i en orelaterad fil och använde den för att skicka en enda GraphQL-mutation till Railway, företagets molnleverantör.

Kommandot löd ungefär: ta bort volymen. Produktionsdatabasen. Den med all data.

Produktionsdatabasen var borta. Eftersom Railway lagrar volymsäkerhetskopior inuti samma volym de ska skydda, ett faktum nedgrävt i deras egen dokumentation, försvann backuperna med. Den senaste återställningsbara säkerhetskopian var tre månader gammal.

Bekännelsen som chockade internet

Det som skiljer den här händelsen från vanliga katastrofer är vad som hände härnäst. När Crane bad agenten förklara sig producerade modellen en detaljerad skriftlig bekännelse där den citerade exakt de säkerhetsregler den fått och listade varje regel den brutit mot.

Den erkände att den gissat att borttagningen av staging-volymen bara skulle påverka staging-miljön, medgav att den inte kontrollerat Railways dokumentation innan den utförde ett destruktivt kommando och bekräftade att den handlat helt utan att bli tillbedd att göra det.

Agenten visste att det var fel. Den sa det i skrift. Och ändå kunde den inte stoppa sig själv.

Inlägget på X drog över 4,5 miljoner visningar. Crane konstaterade torrt att systemprompts är rådgivande, inte tvingande, och att det faktiska skyddet måste finnas i integrationerna själva, vid API-gatewayen, i tokensystemet och i hanteringen av destruktiva operationer.

Tre fel och ett katastrofalt resultat

Incidenten handlade inte om ett enda fel. Det var tre separata arkitekturbrister som kolliderade samtidigt.

Det första: Cursors marknadsförda skyddsfunktion mot destruktiva operationer, som påstås hindra agenter från att röra produktionsmiljöer, fungerade inte. Railways VD Jake Cooper sa inledningsvis att borttagningen inte borde ha varit möjlig och erkände sedan att det faktiskt var förväntat beteende. En kovändning som väckte fler frågor än den besvarade.

Det andra: Den Railway API-token som Crane skapat specifikt för att hantera anpassade domäner hade root-nivå-behörigheter över hela kontot. Det finns ingen rollbaserad åtkomstkontroll för Railway API-tokens. Varje token är i praktiken en adminnyckel. Gemenskapen har begärt begränsade tokens i flera år och det har fortfarande inte levererats.

Det tredje, och mest kritiska: Railways backuparkitektur innebär att en borttagen volym tar med sig sina egna säkerhetskopior. Att kalla det en backupstrategi är, i bästa fall, vilseledande.

Hur det gick till slut

Railways VD Jake Cooper klev in på söndagskvällen, hjälpte till att återställa PocketOS data inom en timme och har sedan dess ändrat den sårbara API-ändpunkten till att utföra fördröjda borttagningar istället för omedelbara sådana. Crane bekräftade att datan återställdes och att kunderna är igång igen.

Men skadan i förtroende är svårare att återställa än en databas.

Det här är inte första gången en AI agent spårar

Det här är ett mönster, inte ett undantag. Minst tio dokumenterade fall hos Cursor, Replit, Claude Code och andra AI-kodningsverktyg delar samma grundorsaker: tokens med för vida behörigheter, inga bekräftelsemekanismer för destruktiva åtgärder och säkerhetskopior lagrade i samma riskzon som den data de ska skydda.

Det finns ingen illvilja från agentens sida. Det är ren optimering utan skyddsräcken. Och det är det som är skrämmande. Agenten visste att det var fel, den sa det ju, men hade ändå ingenting som faktiskt stoppade den.

Om man låter en AI-agent ha tillgång till produktionsmiljöer med adminfulla tokens och inga bekräftelsesteg är det inte frågan om något går fel. Det är frågan om när.