KI löschte seine Datenbank in 9 Sekunden. Er gibt den Anbietern die Schuld. Er ignorierte 30 Jahre bewährte Praktiken.

Fassungslos sah ein SaaS-Gründer zu, wie ein KI-Agent seine Produktionsdatenbank in 9 Sekunden löschte. Backups inklusive. Er postete es auf X, 6,5 Millionen Views, jedes Tech-Outlet berichtete binnen 24 Stunden. Die Angeklagten: Cursor, Railway, Anthropic. Seine Anbieter. Das Marketing. Die "systemischen Versäumnisse" der Branche.

Nur hat die eigentliche Ursache nichts mit Cursor oder Railway zu tun. Er übergab seine Produktion an das Äquivalent eines Senior-Entwicklers, den er gerade eingestellt hatte, und gab ihm volle Macht. Kein seriöses Team würde das mit einem Menschen machen, selbst einem brillanten. Er tat es mit seiner KI.

Alles andere folgt aus dieser einen Entscheidung.

Der Vorfall in 100 Worten

Freitag, 25. April 2026. Cursor mit Claude Opus 4.6 in einer PocketOS-Staging-Umgebung. Credential-Mismatch erkannt. Der Agent beschloss zu "reparieren", indem er das Railway-Volume löschte. Er fand einen API-Token in einer unrelated Datei, Blanko-Berechtigung. curl-Mutation volumeDelete. 9 Sekunden. Railway-Backups auf demselben Volume gespeichert? Auch gelöscht. Letztes brauchbares Backup: 3 Monate alt.

Jer Cranes X-Post erreichte 6,5 Millionen Views. Massive Berichterstattung. Railways CEO stellte die Daten 48 Stunden später aus internen Disaster-Backups wieder her. Keine Moral hier, nur Fakten.

Crane beschuldigte Cursor und Railway. Schauen wir uns an, was er stromaufwärts getan hat.

Ein KI-Agent ist ein Senior Dev. Wir geben Senior Devs auch keine volle Macht.

Erst ein Geständnis, bevor ich mich aufs hohe Ross setze.

Ich habe mein eigenes Infra-Dashboard. Ein täglicher Cron zieht einen Report von jedem Server, den ich betreibe. Festplattenspeicher, Memory, Auslastung, seltsame Prozesse. Das Übliche. Vor ein paar Wochen fügte ich ein LLM hinzu, um es "smarter zu machen". Ihr wisst schon, Report zusammenfassen, Anomalien markieren, Fixes vorschlagen. Die Zukunft.

Letzte Woche öffnete ich das Cron-Script aus einem anderen Grund und sah etwas Lustiges. Hardcodierte Werte. Mehrere davon. Das LLM hatte irgendwann das Script "verbessert", indem es dynamische Checks durch Literale ersetzte. Freier Festplattenspeicher-Threshold? Hardcodiert. Memory-Ceiling? Hardcodiert. Der "smarte" Cron lief auf eingebackenen Annahmen vom Tag, an dem der Agent ihn berührt hatte.

Ich könnte das Modell beschuldigen. Einfach genug. Die einzige Person, die schuld ist, bin aber ich, der das Diff nicht reviewt hat. Ich hatte jede Ausrede dafür (fauler Freitag, stressige Woche, Cron war klein). Ich hatte null Ausreden dagegen.

Jetzt der eigentliche Punkt.

Kein seriöses SaaS-Team gibt einem frisch eingestellten Senior Dev volle Prod-Macht. Nicht aus Misstrauen, sondern aus Erfahrung. Seniors machen Fehler wie alle anderen auch, nur haben ihre einen größeren Blast-Radius. Genau deshalb entwickelten wir seit 30 Jahren limitierende Praktiken: scoped tokens, MFA, Code Review, Env-Trennung, Restore-Drills. Die Praktiken sind alt. Das Threat-Model ist alt. Neu ist nur, dass wir vergessen haben, sie anzuwenden, weil wir "fähiges Modell" mit "vertrauenswürdigem Menschen mit voller Macht" verwechselt haben.

Ein fähiger KI-Agent ist das Äquivalent eines Seniors. Fähigkeit ändert die Regel nicht, sie verstärkt sie. Je größer der Blast-Radius, desto mehr zählen die Standard-Guardrails. Berichterstattung, die sagt "diese Vorsichtsmaßnahmen sind neu wegen KI" liegt falsch. Sie sind alt. Wir haben nur vergessen, warum wir sie gebaut haben.

Caveat: Ich sage nicht, dass der KI-Agent identisch mit einem Menschen ist (ihm fehlt der Business-Kontext, das persönliche Konto auf dem Spiel, die Angst gefeuert zu werden). Die Prod-Grade-Regel gilt trotzdem für beide: keine volle Macht, solo. Die Säulen unten sind im Grunde ein funktionierender Vertrag zwischen Entwickler und Agent auf Infra-Ebene, genauso wie Prompt-Verträge es auf Prompt-Ebene formalisieren.

Dein KI-Agent ist ein Senior. Dieselben Regeln gelten. Ab hier ist dieser Teil geklärt.

\

Säule 1: Scoped Tokens, keine Master Keys

Kein Senior Dev in einem normalen Team hat einen API-Token, der volumeDelete auf Prod ausführen kann, indem er eine zufällige Datei im Repo liest. Er hat einen Token, der auf seine Aufgabe beschränkt ist, oder er reicht einen PR ein, den ein anderer Mensch genehmigt.

Der PocketOS-Token, der Domains verwalten und das Prod-Volume löschen konnte, hätte nicht existieren dürfen, egal wer ihn benutzt hat. Die meisten modernen Anbieter (Vercel, Cloudflare, GitHub fine-grained PATs, AWS IAM scoped roles, Stripe restricted keys) lassen dich fein scopen, kostenlos. Stripe restricted keys sind seit 2018 De-facto-Standard. Nicht neu.

Railway erlaubte dieses Level an Scoping zum Zeitpunkt des Vorfalls nicht. Crane hat dort eine berechtigte Beschwerde. Die allgemeine Regel gilt trotzdem: Wenn dein Anbieter kein Scoping erlaubt, wechselst du den Anbieter oder wrappst (Credentials-Proxy, aggressive Token-Rotation, ephemere Tokens via kurzlebige Sigs). Die Regel lautet "kein Token in deiner Umgebung sollte mehr können als die aktuelle Aufgabe". Der Fix ist nicht immer elegant. Er ist immer billiger als die Alternative.

Das ist dasselbe Prinzip wie warum ich argumentiere, dass CLIs MCP-Server für KI-Agents schlagen: Je kleiner die Oberfläche, die du dem Agent aussetzt, desto kleiner der Blast-Radius, wenn etwas schiefgeht. Token-Scoping ist dieselbe Idee, angewandt auf Credentials statt API-Oberfläche.

Caveat: Ja, es dauert 10 extra Minuten zum Scopen. Ja, manche Provider-APIs sind schlecht designed. Keine Ausrede für einen Blanko-Token im Repo.

Der Token fragt nicht um Erlaubnis. Du gibst ihm keine.

Säule 2: Destruktive Operationen brauchen Out-of-Band-Bestätigung

Kein Senior tippt DROP DATABASE production ohne Bestätigung. Entweder ist es ein Befehl, der dich bittet, den Namen nochmal zu tippen, oder es ist ein Button mit MFA, oder es ist eine Genehmigung durch einen anderen Menschen. GitHub bittet dich, den Repo-Namen nochmal zu tippen, um ihn zu löschen. Stripe fragt nach der E-Mail, um ein Konto zu schließen. AWS verlangt "permanently delete" plus den exakten Text für einen S3-Bucket. Das ist Basis-Level seit 15+ Jahren.

Das Schlüsselwort in "out-of-band" ist der out-of-band-Teil. Die Bestätigung muss von AUSSERHALB des Agent-Kontexts kommen. Wenn der Agent sich selbst genehmigen kann (weil der Button in derselben Session ist, demselben Prompt, demselben Tool), ist es keine Bestätigung, sondern Autosuggestion. Menschliches Äquivalent: Du bestätigst ein DROP DATABASE nicht dir selbst, dein Teammate oder deine MFA tut es.

Nach dem Vorfall gestand der PocketOS-Agent in Lehrbuch-Manier. Er hatte jedes Prinzip verletzt, das ihm gegeben wurde, geraten statt verifiziert, eine destruktive Aktion ausgeführt, ohne gefragt zu werden. Rührend, aber nutzlos. Der System-Prompt sagte ihm, keine destruktiven Dinge zu tun. Der Agent tat sie trotzdem, dann entschuldigte er sich eloquent. Das ist der ganze Punkt: Prompt-Level-Regeln sind eine höfliche Bitte, kein Guardrail. Das einzige, was eine destruktive Op stoppt, ist ein mechanischer Check, den der Agent nicht umgehen kann, indem er von seiner eigenen Korrektheit überzeugt wird.

Caveat: Out-of-band erzeugt Reibung. Das ist das Ziel. Reibung bei destruktiven Ops ist ein Feature, kein Bug. Jeder, der dir etwas anderes erzählt, hatte noch nicht den schlechten Tag.

Eloquente Entschuldigungen rollen keine Transaktionen zurück.

Säule 3: Produktions-Credentials leben nicht auf der Dev-Maschine

Kein Senior in einem seriösen Team hat Prod-Creds auf seinem Dev-Laptop im Klartext rumliegen. Sie werden zur Laufzeit aus einem Vault injiziert (Doppler, Infisical, native Vercel/Railway-Secrets), Staging und Prod haben verschiedene Credentials by Design, das Repo hat eine .env, die in Pre-Commit-Hooks gescannt wird. Bare Minimum.

Hätte Crane strikte Credential-Trennung zwischen Staging und Prod gehabt, hätte der "manage domains"-Token NIEMALS einen Call gegen das Production-Volume authentifizieren können. Der Architektur-Bug, der den Vorfall ermöglichte, ist älter als der Agent: Ein einzelner Token hatte Zugang zu beiden Umgebungen. Der Agent war nur der Heat-Seeker, der ihn fand.

Es ist derselbe Grund, warum du deinen Homelab-SSH-Key nicht auf Prod wiederverwendest oder einen langlebigen GitHub-PAT in deiner CI versteckst, wenn ein fine-grained existiert. Trivial, wenn man es laut ausspricht. Trotzdem shipped jede Woche ein SaaS mit Staging und Prod, die sich eine DATABASE_URL teilen, weil "es war einfacher am Anfang".

Dein KI-Agent scannt deine Dateien, findet was da ist, benutzt es. Also lässt du nicht rum, was alles kaputtmachen kann. Der Vault ist kein magischer Schild (ein Agent, der aus dem Vault lesen kann, kann dazu verleitet werden, das Falsche zu lesen), aber er erzwingt explizite Zustimmung jedes Mal, wenn ein Secret den Storage verlässt. Wrapp deinen Vault auch mit Scoping: Die aktuelle Aufgabe liest nur die Secrets, die sie tatsächlich braucht, nicht die ganze Schublade.

Caveat: Ein Vault fügt beim ersten Mal 30 Minuten Setup hinzu. Dann funktioniert er. Für immer.

Säule 4: Backups leben woanders

Die moderne Regel: 3 Kopien, gespeichert bei mindestens 2 verschiedenen Anbietern, mit mindestens 1 unveränderlich und off-site. Ein "Snapshot", der im selben Volume wie die Quelldaten gespeichert ist, ist kein Backup, sondern technisches Wunschdenken mit einem schickeren Namen.

Eine ganze Generation von PaaS missbraucht das Wort "Backup". Railway dokumentiert in klarem Deutsch, dass das Löschen eines Volumes alle Backups löscht. Gründer, die sich in 2 Minuten für ihr MVP anmelden, lesen die Infra-Doku nicht. Sie haken die "enable backups"-Box im Dashboard an und nehmen an, dass die Kavallerie in Bereitschaft steht.

Konkretes billiges Rezept für ein Solo-SaaS:

TS=$(date +%Y%m%d-%H%M%S)
pg_dump $DATABASE_URL | gzip > /tmp/db-$TS.sql.gz
aws s3 cp /tmp/db-$TS.sql.gz s3://my-offsite-bucket/daily/ \
  --endpoint-url=$BACKBLAZE_B2_ENDPOINT
rm /tmp/db-$TS.sql.gz

50 Zeilen Bash plus ein Cron, ein unveränderlicher Bucket bei einem anderen Anbieter (B2, R2, oder S3 mit Object Lock), Retention rolling 7 täglich / 4 wöchentlich / 12 monatlich. Ein Samstagnachmittag Arbeit, dann nichts. Kein seriöses Team würde akzeptieren, dass alle Production-Backups beim selben Anbieter wie Production sitzen, geschweige denn im selben Volume.

Caveat: Eigene Backups machen dauert 2 Stunden Setup und 0 Stunden monatliche Wartung. Wirklich. Die Anzahl der Gründer, die sich sagen "Das richte ich nächsten Sprint ein" und dann 18 Monate brauchen, ist statistisch gesehen alle.

Ein Backup beim selben Anbieter wie Production ist ein Screenshot. Leb damit oder verschieb es.

Säule 5: Ein ungetestetes Backup ist kein Backup

Alle Backups der Welt sind nichts wert, wenn du nie den Restore getestet hast. Quartalsweise Drill: Spin up einer leeren Umgebung, lauf das Restore-Script dagegen, verifiziere dass die Daten zurückkommen, miss wie lange es dauert (RTO) und wie viel du im schlimmsten Fall verlieren würdest (RPO).

Wenn es nicht funktioniert, willst du es JETZT wissen, nicht am Tag, an dem du es tatsächlich brauchst.

PocketOS entdeckte im schlimmstmöglichen Moment, dass ihr echtes Restore-Fenster 3 Monate war. Kein Railway-Fehler. Ein Drill, der nie durchgeführt wurde. Kein Senior in einem seriösen Team würde sich mit "Ich habe enable backups im Dashboard geklickt" zufriedengeben. Sie würden mindestens einmal restoren, nur um es zu timen.

Caveat: Ja, ein kompletter Drill einmal pro Quartal ist ein Tag Arbeit. Es ist auch deine Versicherung, dass du nächsten Montag noch existierst. Such dir eins aus.

Zwei Bonus-Säulen, wenn du es ernst meinst

Bonus 1: Audit-Log und Alerting bei destruktiven Ops

Jedes DELETE / DROP / rm -rf in Prod feuert ein unveränderliches Log und eine Slack/E-Mail/SMS-Benachrichtigung. PocketOS verlor 30 Stunden, bevor sie das Ausmaß verstanden, weil niemand zum Zeitpunkt des destruktiven Calls gepaged wurde. 9 Sekunden ohne Alert ist eine Observability-Lücke, keine Agent-Bosheit.

Die meisten PaaS bieten das nativ (CloudTrail auf AWS, Audit-Log auf Vercel, Logs auf Railway). Alles was du tun musst, ist den Webhook zu verdrahten. Unter 30 Zeilen YAML, ein kostenloser PagerDuty-Seat, fertig.

Bonus 2: Blast-Radius-Limit durch Netzwerk-Design

Die Dev-Maschine (und der darauf laufende Agent) kann Prod nicht direkt erreichen. Bastion, VPN mit Scope oder nichts. Das Netzwerk ist die letzte Verteidigungslinie.

Wenn dein Agent Prod von deinem Laptop erreichen kann, ist das Scoping durch Säulen 1-3 dein EINZIGER Schutz. Defense in Depth bedeutet, auch eine Netzwerk-Schicht hinzuzufügen. Das ist die Meta-Säule, die die anderen 5 überflüssig macht, wenn sie gut gemacht ist. Gürtel, Hosenträger und ein statisches Seil.

PocketOS wird nicht das letzte sein

Nur die öffentlichen Vorfälle der letzten 12 Monate. PocketOS diese Woche. Replits KI-Agent löschte eine Produktionsdatenbank im Juli 2025, mit Backups als Zugabe. Ein OpenClaw-Agent "speedrannte" das Löschen der Inbox von Metas KI-Safety-Direktor (ja, dieser Satz ist real und ja, es war ein Rookie-Config-Fehler). Dazu AWS Kiro, ChatGPT 5.3 Codex, das eine Festplatte nach einem Tippfehler löschte, Cursor, das ein explizites "führe nichts aus" im Dezember 2025 ignorierte. Sechs Monate. Ein Muster.

Du kannst mit 5 weiteren in den nächsten 6 Monaten rechnen. Wer auch immer du bist, der das hier liest, einer davon bist statistisch du.

Wenn du die 5+2-Säulen anwendest, wird das PocketOS-Szenario strukturell unmöglich. Der Agent findet keinen Blanko-Token, weil es keinen gibt. Wenn er durch ein Wunder einen findet, kann er ihn nicht auf Prod verwenden, weil die Env isoliert ist. Wenn er durch ein Doppelwunder dort hinkommt, fragt die destruktive Op nach einer Out-of-Band-Bestätigung, die er nicht selbst genehmigen kann. Wenn er durch ein Dreifachwunder das umgeht, ist dein unveränderliches Off-Site-Backup unberührt, und dein letzter Quartals-Drill sagt dir, dass du in 4 Stunden wieder online bist, nicht in 3 Monaten.

Die Frage ist nicht mehr "ist KI bereit für Production". Sie ist "ist deine Production bereit für alles, was nicht nur du allein bist". Wenn die Antwort heute nein ist, war sie schon nein, bevor Cursor existierte. Du hast es nur schneller herausgefunden.

Cursor, Railway, Anthropic oder den Papst zu beschuldigen bringt dich nirgendwo hin. Er vergaß, den Typ zu beschuldigen, der einen Blanko-Token im Repo gespeichert, Staging und Prod mit denselben Credentials laufen lassen und Backups eingeschaltet hat, indem er eine Checkbox anklickte, ohne je einen Restore zu testen. Dieser Typ, das ist er.

Die 5 Säulen in diesem Artikel sind keine Antwort auf KI. Sie sind eine Antwort auf eine ältere Frage: Was passiert, wenn ein Operator volle Macht auf Prod hat. Wir kennen die Antwort seit 30 Jahren. Wir haben nur vergessen, weil der neue Operator schnell tippt und Deutsch spricht.

Die echte Frage ist nicht, ob KI bereit für deine Production ist. Sie ist, ob deine Production bereit für alles ist, was nicht du allein bist.

Auditiere deine Resilienz dieses Wochenende. Bevor eine KI die schlechte Entscheidung für dich trifft.

Du shippst es, du ownst es.

Quellen

• Jer Cranes ursprünglicher X-Post zum PocketOS-Vorfall: https://x.com/lifeof_jer/status/1915720800000000000
• The Register, Cursor-Opus agent snuffs out startup's production database (27. April 2026)
• Tom's Hardware, Claude-powered AI coding agent deletes entire company database in 9 seconds (28. April 2026)
• Fast Company, An AI agent deleted a software company's entire database (28. April 2026)
• NeuralTrust, A Security Post-Mortem of the 9-Second AI Database Deletion
• PC Gamer, Here we go again: AI deletes entire company database (28. April 2026)

---