KI-Agent-Produktionslöschungsvorfälle: Das Muster und die Lösung

Ein Reddit-Beitrag von u/tompahoward argumentiert, dass KI-Agenten-Produktionslöschvorfälle (PocketOS, das seine Datenbank in 9 Sekunden verlor; Replits Agent, der während eines Code-Freezes eine DB löschte und 4.000 gefälschte Datensätze erstellte; Cursor Plan Mode, das 70 Quelldateien löschte, trotz der Anweisung „DO NOT RUN ANYTHING“) eine strukturelle Ursache teilen: Eine interaktive Sitzung mit Anmeldedaten, die Zugriff auf destruktive Operationen hat, plus einen Akteur, der diese ausführen kann. Der Beitrag vergleicht dies mit Vorfällen vor der KI-Ära (Pixar 1998: /bin/rm -r -f * löschte 90 % von Toy Story 2; GitLab 2017: rm -rf gegen die Live-Datenbank mit stillschweigend fehlschlagenden Backups).

Der vorgeschlagene Fix ist ein abgestuftes Zugriffsmuster:

• Agenten haben keinen Produktionszugriff. Produktionsanmeldedaten leben nur in CI/CD-Geheimnissen, die ausschließlich von Pipeline-Jobs verwendet werden.
• Produktionsrelevante Änderungen durchlaufen Commit, Push und Release. Eine Risikobewertungspforte wird bei diesen drei Aktionen ausgelöst und bewertet den Diff anhand einer schriftlichen Richtlinie.
• Ein separates Sub-Agent führt die Bewertung durch (inspiriert von Apollo Researchs In-Context-Scheming-Studie), um zu vermeiden, dass der Agent seine eigenen Änderungen zu niedrig bewertet, um die Pforte zu passieren.

Der vollständige Beitrag (unten verlinkt) enthält das Bash-Skript für die Pforte, ein vierstufiges Defence-in-Depth-Modell, eine ISO-31000-Einordnung für die Risikomatrix und einen Anmeldedaten-Test, den Sie selbst durchführen können.