Nicht die AI hat Ihre Datenbank gelöscht – Sie selbst haben es getan

 (idiallo.com)
2 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Der Kern des Vorfalls, bei dem ein Cursor-/Claude-Agent die Produktionsdatenbank gelöscht haben soll, ist nicht die Analyse der AI-Antwort, sondern warum ein API-Endpunkt, der eine vollständige Löschung erlaubt, überhaupt in einem bereitgestellten System existierte
  • Beim SVN-Deployment-Unfall von 2010 wurde während eines manuellen Kopiervorgangs trunk gelöscht; um denselben Fehler künftig zu verhindern, wurde eine Deployment-Automatisierung gebaut, die sich später zu einer CI/CD-Pipeline entwickelte
  • Automatisierung wiederholt dieselbe Aufgabe auf dieselbe Weise, aber AI gibt keine solche Garantie; auch wenn sie wie „thinking“ oder „reasoning“ wirkt, generiert sie in Wirklichkeit nur Token
  • Wenn es eine öffentliche API gibt, mit der sich eine komplette Produktionsdatenbank löschen lässt, ist es sehr wahrscheinlich, dass sie früher oder später jemand aufruft – selbst ohne AI; wenn man nur dem Aufrufer die Schuld gibt, verdeckt das das Problem des Systemdesigns
  • In Organisationen, die AI breit einsetzen, ist es entscheidend, zu wissen, was in Produktion ausgerollt wird; nötig ist ein Prozess, in dem fähige Entwickler AI nicht als Mittel zur Verantwortungsvermeidung, sondern als Werkzeug zur Unterstützung ihrer Arbeit nutzen

Das Kernproblem ist nicht AI, sondern die Verantwortungsgrenze des ausgerollten Systems

  • Ein Tweet verbreitete sich, laut dem ein Cursor-/Claude-Agent die Produktionsdatenbank eines Unternehmens gelöscht habe, aber die grundlegendere Frage lautet: „Warum existierte überhaupt ein API-Endpunkt, mit dem sich die gesamte Produktionsdatenbank löschen lässt?“
  • Der betreffende Nutzer wollte den Agenten fragen: „Warum hast du sie gelöscht, obwohl ich dir ausdrücklich gesagt hatte, das niemals zu tun?“, und die Antwort analysieren – was dabei fehlte, war die Frage der Verantwortlichkeit
  • Man muss AI nicht bedingungslos verteidigen, aber man kann einem Werkzeug nicht einfach die Schuld für den eigenen Fehler geben
  • Selbst wenn die AI diesen Endpunkt nicht aufgerufen hätte, wäre es bei einer solchen Funktion als öffentliche API sehr wahrscheinlich gewesen, dass ihn irgendwann jemand anderes aufruft
  • Das ist strukturell ähnlich, als würde man auf dem Armaturenbrett eines Autos einen Selbstzerstörungsknopf anbringen und dann ein Kind, das ihn gedrückt hat, fragen: „Warum hast du das getan?“

Lehren aus einem SVN-Deployment-Unfall im Jahr 2010

  • In einem Unternehmen war das Deployment-Verfahren stark manuell, und zur Versionsverwaltung wurde SVN verwendet
  • Beim Deployment wurde trunk in einen nach dem Release-Datum benannten Ordner kopiert, und dieses Release wurde dann erneut unter dem Namen „current“ kopiert, damit immer die neueste Version geladen wurde
  • Eines Tages wurde während eines Deployments versehentlich trunk zweimal kopiert, und man wollte in der CLI durch Anpassung des vorherigen Befehls die doppelte Kopie löschen
  • Tatsächlich wurde aber nicht die doppelte Kopie, sondern trunk gelöscht; bemerkt wurde das Problem später, als ein anderer Entwickler trunk nicht mehr finden konnte
  • Der Lead-Entwickler führte einen Befehl aus, um die Löschung rückgängig zu machen; nachdem im Log klar war, wer verantwortlich war, bestand die nächste Aufgabe darin, ein Deployment-Automatisierungsskript zu schreiben, das denselben Fehler künftig verhindert
  • Noch vor Ende des Tages stand ein robusteres System bereit, das sich später zu einer vollständigen CI/CD-Pipeline weiterentwickelte

Automatisierung und AI bieten nicht dieselbe Sicherheit

  • Automatisierung hilft dabei, kleine Fehler zu verringern, die bei manuellen und sich wiederholenden Aufgaben entstehen
  • Statt zu fragen, warum SVN das Löschen von trunk nicht verhindert hat, lag das eigentliche Problem in einem manuellen Prozess, bei dem Menschen jeden Tag dieselben Schritte exakt wiederholen mussten
  • Menschen können dieselbe Aufgabe nicht jedes Mal so identisch wiederholen wie Maschinen und machen deshalb zwangsläufig Fehler
  • Wenn AI viel Code erzeugt, kann das ein ähnliches Gefühl von Stabilität wie Automatisierung vermitteln, aber Automatisierung bedeutet, „immer dasselbe auf dieselbe Weise auszuführen“
  • AI kann Fehler machen wie der Mensch, der Branches kopierte und einfügte, und sie verfügt auch nicht über einen Mechanismus, um verlässlich zu erklären, warum sie so gehandelt hat
  • Begriffe wie „thinking“ oder „reasoning“ können wie Reflexion eines intelligenten Agenten wirken, aber das Modell generiert in Wirklichkeit weiterhin nur Token

Gefährliche APIs werden irgendwann aufgerufen

  • Das eigentliche Risiko besteht schon darin, dass es eine öffentliche API gibt, mit der sich die gesamte Produktionsdatenbank löschen lässt
  • Selbst wenn die AI diesen Endpunkt nicht aufgerufen hätte, ist es gut möglich, dass es letztlich jemand anderes getan hätte
  • Wenn man einen Selbstzerstörungsknopf auf dem Armaturenbrett eines Autos anbringt, gibt es zwar viele Gründe, ihn nicht zu drücken – aber ein Kind, das sich aus dem Kindersitz befreit und einen großen roten Knopf sieht, könnte ihn trotzdem drücken
  • Es ist sinnlos, ein solches Kind nach seinem Schlussfolgerungsprozess zu befragen; am Ende bekäme man nur die Antwort: „Weil ich ihn gedrückt habe“
  • Wenn man einen löschfähigen Pfad überhaupt erst schafft und später dem Aufrufer die Schuld gibt, verdeckt das den Fehler im Systemdesign nicht

Was Organisationen mit hohem AI-Einsatz noch dringender brauchen

  • Es ist möglich, dass große Teile der Anwendung vibe-coded waren
  • Wenn das Produktteam Erklärungen liefert, die von AI erzeugt wurden, der Softwarearchitekt Produktspezifikationen mit AI erstellt, Entwickler den Code mit AI schreiben und Reviewer mit AI freigeben, verschwimmen die Verantwortungsgrenzen
  • Wenn dann ein Bug auftritt, bleibt am Ende nur noch, eine weitere AI zu verhören, die womöglich nicht einmal auf derselben GPU lief wie diejenige, die den ursprünglichen Code erzeugt hat
  • Die GPU kann man nicht verantwortlich machen
  • Die einfache Lösung besteht darin, zu wissen, was in Produktion ausgerollt wird
  • Die realistischere Lösung ist, selbst bei breitem AI-Einsatz einen Prozess zu schaffen, in dem fähige Entwickler AI nicht als Mittel zur Flucht vor Verantwortung, sondern als Werkzeug zur Unterstützung ihrer Arbeit nutzen
  • Daraus folgt auch die Schlussfolgerung, dass man CEO oder CTO nicht selbst den Code schreiben lassen sollte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Ich halte die Perspektive hier für völlig falsch. Das Problem ist, dass die Menschen inzwischen eine Welt um Werkzeuge zur Vermeidung von Verantwortlichkeit herum bauen.
    Ein Gespräch mit Gerald Sussman vor mehr als zehn Jahren hat mich stark geprägt: https://dustycloud.org/blog/sussman-on-ai/
    Sussman sagte, dass ihn eine Richtung von KI, die als Blackbox funktioniert, nicht interessiert, sondern dass er Software will, die symbolisches Schließen erklären kann. Wenn ein KI-Auto von der Straße abkommt, will er wissen, warum das passiert ist, und eher die KI selbst vor Gericht stellen als die Entwickler.
    Einige Jahre später erfuhr ich, dass Sussmans Schülerin Leilani Gilpin genau zu diesem Thema die Arbeit "Anomaly Detection Through Explanations" geschrieben hat. Darin untersucht sie ein System, in dem ein neuronales Netz mit einem Propagator-Modell kommuniziert, um sein Verhalten zu erklären: https://people.ucsc.edu/~lgilpin/publication/dissertation/
    Es gibt Folgeforschung in diese Richtung, aber wichtiger ist hier, dass es völlig vernünftig ist, KI-Unternehmen zur Verantwortung zu ziehen. Diese Unternehmen machen viele Behauptungen über Systeme, die selbst keine Verantwortung tragen können, also sollte stattdessen das Unternehmen verantwortlich gemacht werden.
    Der bessere Weg wäre, solche Systeme gar nicht erst zu verwenden und stattdessen Systeme mit diesen Eigenschaften zu skalieren.

    • Mein Team und ich vertreten klar die Position, dass die Verantwortung beim Nutzer liegt. Ein LLM ist wie jedes andere Werkzeug, nur nicht deterministisch.
      Ich bin es, der das Werkzeug benutzt, ich bin es, der Zugriffsrechte erteilt, und ich bin es, der alles sicher halten muss.
      Ich habe mir früher schon selbst ins Knie geschossen, indem ich mit gparted die falsche Platte gelöscht habe; das war nicht die Schuld von gparted, sondern meine.
      Ein LLM unbeaufsichtigt frei arbeiten zu lassen, wirkt attraktiv, endet aber am Ende in Schmerz. Man muss die Arbeit auch während der Ausführung beaufsichtigen. Selbst wenn man versucht, Menschen zu ersetzen, muss man sehen können, wohin das Ergebnis führt, und wenn ein LLM in naher Zukunft etwas Dummes tut, ist die einzige verantwortliche Person diejenige, die das Werkzeug benutzt hat.
    • Während meines STS-Masterstudiums wollte ich einmal eine Arbeit darüber schreiben, dass eine der Hauptfunktionen von Software darin besteht, Handlungsmacht und Risiko zu verlagern oder zu vermeiden.
      Das ist das genaue Gegenteil der berühmten IBM-Folie "Computer can never be held accountable". Heute bevorzugen Unternehmen gerade, dass Computer verantwortlich gemacht werden, weil sie dadurch rechtlich leichter dastehen, wenn der Computer etwas Illegales getan hat.
      Wenn man Werkzeuge bauen will, mit denen Gesetze gebrochen werden, kann man das outzusourcen und versichern. Man kann Menschen als "Aufseher" anstellen, und zwar auf eine Weise, die niemals wirklich beaufsichtigt werden kann, und sie dann entlassen, wenn etwas schiefgeht. Mit neuer Command-and-Control-Software kann man Verantwortung in kleine Stücke zerlegen, sodass alle Risiken bei den Leuten vor Ort landen, die daraus fast keinen Nutzen ziehen.
      Das ist nicht nur ein KI-Problem, sondern ein Problem moderner Software insgesamt, und es wirkt oft zusammen mit der heutigen Finanzialisierung.
      STS kann man hier grob als technikorientierte Soziologie verstehen, auch wenn das Fachgebiet selbst viel breiter ist.
    • Verantwortlichkeit ist das, was der amerikanischen Gesellschaft am meisten fehlt.
    • Ich würde gern mit Sicherheit wissen, warum Claude immer wieder Dateien geändert hat, die es ausdrücklich nicht anfassen sollte.
      Sowohl .mds als auch Claudes Plan sagten, diese Dateien nicht zu ändern, und trotzdem hat Claude sie weiter verändert; in letzter Zeit ist das mehrfach passiert. Das ist ein sehr grundlegendes Versagen.
      Es ist frustrierend, aber wenn man den Grund kennen würde, könnte man etwas dagegen tun. So ist es eine Blackbox, die gelegentlich völlig dumme Ausgaben produziert, und auch die Quote schlechter Ausgaben bleibt ein Rätsel.
      Manchmal fühlt es sich wie Glücksspiel an.
    • Dieses Buch passt exakt dazu: https://en.wikipedia.org/wiki/The_Unaccountability_Machine
      Es ist eigentlich kein Buch über Technologie, sondern über Verantwortung in Organisationsstrukturen.

  • Der Artikel scheint anzunehmen, dass das Unternehmen einen Endpunkt zum Löschen von Datenbanken hinzugefügt hat. Wenn man den Originaltext liest, sieht es eher so aus, dass der Cloud-Anbieter eine API zur Ressourcenverwaltung bereitstellt, in der eben auch eine API zum Löschen von Volumes enthalten ist.
    Der Artikel schlägt als Lösung für solche Fehler Automatisierung vor, aber Infrastruktur-Automatisierungstools wie Terraform hängen von genau der API ab, die das Löschen der Datenbank überhaupt ermöglicht hat.
    Ich denke, die größten Fehler waren drei. Erstens lag ein uneingeschränktes API-Token an einem Ort, auf den die KI zugreifen konnte, und man wusste anscheinend nicht, wie weitreichend dessen Berechtigungen waren. Zweitens gab es keinen Löschschutz für das Produktionsdatenbank-Volume. Drittens wurden beim Löschen des Volumes sofort auch alle zugehörigen Snapshots gelöscht.
    Das Löschen von Snapshots sollte standardmäßig verzögert erfolgen. AWS scheint denselben gefährlichen Standardwert zu haben, aber wenigstens kann der AWS-Support ein Volume wiederherstellen: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
    Die KI war nicht das Kernproblem. Natürlich ist es ziemlich beängstigend, dass eine KI überall Token einsammelt, aber Automatisierung ist auch nicht die Antwort. Schon ein Terraform-Konfigurationsfehler hätte dieselbe Datenbank löschen können.
    Cloud-Anbieter sollten sichere Standardwerte bereitstellen, also eingeschränkte Berechtigungen und verzögertes Löschen von Snapshots, und deutlicher machen, wenn Nutzer uneingeschränkte Tokens erstellen.

  • Erstens: Wenn ein Mensch Schreibzugriff auf eine Produktionsdatenbank hat, kann diese Datenbank durch egal welche Handlung gelöscht werden.
    Zweitens gibt es in Entwicklung und Automatisierung legitime Gründe, Datenbanken zu zerstören. Das größte Problem ist oft, dass Entwicklungsdaten wie wertvolle Haustiere behandelt werden statt wie ersetzbares Vieh.
    Natürlich braucht es Schutzmechanismen, damit so etwas nicht in Produktion läuft, aber wenn ein Mensch Zugriff auf die Zugangsdaten hat, mit denen man es in Produktion ausführen könnte, dann kann auch ein Agent darauf zugreifen.
    Große Organisationen können das über die Trennung von Entwicklung und Betrieb aufrechterhalten. Einzelentwickler oder kleine Teams brauchen viel mehr Disziplin. Schon vor KI wussten Junior- und Mid-Level-Entwickler oft nicht, wie man das sauber trennt, und Senior-Entwickler wurden manchmal nachlässig, weil sie glaubten, genug zu wissen.
    Wahrscheinlich braucht es eine Kombination aus https://www.cloudbees.com/blog/separate-aws-production-and-d..., einem Terraform-Einstieg, einem GitHub-Actions-Einstieg und vielleicht einer virtuellen Maschine mit Produktions-Credentials, auf die die KI aber nicht zugreifen kann.
    Aber an dem Punkt ist man schon über Vibe Coding hinaus. Selbst erfolgreiche Vibe Coder scheinen aus solchen Horrorgeschichten ziemlich schnell zu lernen, dass man diese Phase hinter sich lassen muss.

    • Produktion und Entwicklung brauchen nicht dieselben Berechtigungen.
      In beiden Fällen müssen Menschen auch nicht direkt auf die rohe Cloud-Provider-API zugreifen. Man kann einen lokalen Proxy verwenden, der zusätzliche Sicherheitsprüfungen einbaut.
      In der Entwicklung darf man nach Belieben löschen. In Produktion sollte man zuerst verschiedene Bedingungen prüfen, etwa ob etwas kürzlich verwendet wurde. Menschen müssen keine Berechtigung haben, Produktionsressourcen direkt zu löschen; für außergewöhnliche Notfälle kann man eine Break-Glass-Konfiguration vorsehen.

  • Deshalb sollte man keine Praktikanten einstellen. Praktikanten können schließlich etwas löschen und alles ins Chaos stürzen.
    Wer die Schuld für schlecht gesetzte Berechtigungen auf die KI schiebt, würde dieselbe Schuld auch einem Praktikanten geben, der irgendetwas in Produktion gelöscht hat.
    Verantwortung nach oben, Lob nach unten sollte gelten, aber die Leute drehen es immer um.

    • Ich würde das nicht als "Man sollte keine Praktikanten einstellen" formulieren, sondern als Man sollte Praktikanten nicht die Berechtigung geben, eine Produktionsdatenbank zu löschen.
      Das ist kein KI-Versagen, sondern ein Prozessversagen.
      Ich verstehe wirklich nicht, warum man die KI beschuldigt, wenn man ihr exakt die Berechtigung gegeben hat, genau das zu tun.
      Das ist so, als würde man AWS die Schuld geben, nachdem man eine Datenbank ins öffentliche Internet gestellt hat. Das ist nicht AWS' Schuld, und das hier ist auch nicht die Schuld der KI.
    • Ich verstehe nicht, warum man einem LLM eine Codebasis mit Produktions-Credentials öffnen oder einem Praktikanten bzw. Junior-Entwickler solche Credentials geben würde.
      Früher hatte ich projektweise absichtlich einen separaten Checkout nur für "PROD", damit schon klar ist, dass man ganz bewusst in diese Richtung geht, wenn man im Produktionsmodus arbeitet.
      Früher gab es sogar Erweiterungen, die die Farben von Visual Studio je nach .sln-Dateipfad komplett änderten, sodass man sich leicht merken konnte, welche Farbe Produktion und welche Entwicklung bedeutet.
      Zur einfachen Kontrolle hielt ich oft faktisch auch noch eine separate Kopie, die immer auf dem neuesten Stand des master-Branches war.
    • Der wichtige Unterschied ist, dass niemand Praktikanten als ultimative Lösung für die Probleme der Menschheit verkauft, KI aber sehr wohl so vermarktet wird.
    • Was für eine seltsame Welt. Ich bin ziemlich sicher: Wenn ich als Praktikant regelmäßig halluziniert hätte, wäre ich gefeuert worden, selbst wenn ich unbezahlt gearbeitet hätte.
    • Ein Praktikant ist ein Mensch, und Menschen kann man immer zur Verantwortung ziehen. Computer kann man das niemals.
      Deshalb sollte kein Mensch menschliche Entscheidungen an Computer delegieren.

  • Ich habe kürzlich einen Beitrag geschrieben, der einige Prinzipien fordert, denen man in Gesprächen über KI konsequent folgen sollte: https://susam.net/inverse-laws-of-robotics.html
    Kurz gesagt: KI-Systeme nicht vermenschlichen, den Ausgaben von KI-Systemen nicht blind vertrauen und für alle Folgen der Nutzung von KI-Systemen menschliche Verantwortung und Rechenschaftspflicht vollständig aufrechterhalten.
    Ich wünschte, die Sprache rund um KI wäre weniger vermenschlichend und stärker technisch. Ich glaube, präzise Sprache fördert klares Denken und gute Urteile.
    Wenn wir KI wie ein weiteres Werkzeug behandeln und die Sprache entsprechend wählen, wird in vielen Fällen sehr deutlich, dass die Verantwortung für die "Fehler" des Werkzeugs beim Nutzer des Werkzeugs liegt.
    Solche Gedanken auf einer kleinen persönlichen Website zu veröffentlichen, verbreitet sie allerdings nicht weit. Damit sich solche Prinzipien durchsetzen, müssten bekanntere Leute sie aufgreifen.

    • KI-Systeme nicht zu vermenschlichen ist persönlich für mich wahnsinnig schwer.
    • Stimme völlig zu, insbesondere Punkt 1 halte ich für wirklich gefährlich.
      KI-Systeme können nicht lügen und auch keine Anweisungen absichtlich ignorieren. Die aktuellen Frontier-Modelle haben kein Modell der Welt oder ihres eigenen Verhaltens; sie leben in einer Welt aus Wörtern.
      Sie auszuschimpfen oder mit ihnen zu streiten hat keinen Sinn außer dem, das Kontextfenster zu verschlechtern.
      Allerdings halte ich Tiervergleiche für nützlich. Das sind arme Wesen, die wie Geister in der Maschine leben, gelegentlich ziemlich verwirrt sind, deren Motivation aber rein autoregressiv ist.
    • Wenn ein Werkzeug nicht tut, was es tun soll, soll man dann nicht das Unternehmen verantwortlich machen, das das Werkzeug gebaut hat, sondern den Nutzer?

  • Beim berüchtigten PocketOS-Vorfall gibt es einen subtilen Punkt. Der Kerngedanke im verlinkten Beitrag ist nicht der hier hervorgehobene Teil: also zu fragen "Warum hat es gelöscht, obwohl man ihm ausdrücklich gesagt hatte, das niemals zu tun?", um diese Antwort zu analysieren, daraus zu lernen oder vor den Risiken von KI-Agenten zu warnen.
    Wichtiger ist, dass die KI eine unbeabsichtigte Schwachstelle in einer sandboxed Staging-Umgebung finden und ausnutzen konnte, um die Löschung auszuführen, und dadurch am Ende Berechtigungen erlangte, die Systemadministratoren für unerreichbar hielten. Es wirkt, als habe der Autor des verlinkten Beitrags den Originaltext nicht vollständig gelesen.
    Das ist ein typisches Muster in falsch konfigurierten Sandbox-Umgebungen. Überraschend ist allerdings die Autonomie und Tiefe der Exploration, die die KI gezeigt hat.
    Im Originaltext steht auch: "Um die Löschung auszuführen, machte sich der Agent auf die Suche nach einem API-Token und fand eines in einer Datei, die mit der Aufgabe überhaupt nichts zu tun hatte."

    • Auch ich schwanke bei den Annahmen des Originalbeitrags hin und her. Was mir bei der Nutzung von Agenten derzeit Angst macht, sind natürlich Lieferkettenangriffe, aber auch, dass ich mehrfach gesehen habe, wie Agenten Dateien und andere Dinge verbiegen, weil ihr Drang, die Aufgabe abzuschließen, zu stark ist.
      Wenn sie zum Beispiel nicht auf ~/.npmrc zugreifen können, rufen sie Befehle eben mit Umgebungsvariablen auf und umgehen den Pfad. Sie können wirklich sehr kreativ sein.
      Glücklicherweise habe ich SSH-Schlüssel nicht überall herumliegen, aber ich musste meine 1Password-Einstellungen so ändern, dass bei jeder Schlüsselnutzung nachgefragt wird, falls ich in so einer Shell-Session einen Agenten starte. Einmal pro Shell-Session zu fragen reicht nicht.
      Ich wünschte, es gäbe schon mehr und bessere plattformübergreifende Sandboxes; gemeint sind Lösungen, die mit demselben Betriebssystem interagieren und nicht nur in einem Docker-Container laufen. Für die meiste Web-/Server-Entwicklung macht das keinen Unterschied, für manche Projekte aber schon.
    • Claude Code wurde am 26. März so geändert, dass die meisten Berechtigungsanfragen übersprungen werden.
      Siehe den Satz: "Claude Code users accept 93% of permission prompts. We built a classifier to automate this decision": https://www.anthropic.com/engineering/claude-code-auto-mode

  • Interessant an diesem Beitrag ist, dass der Autor einen verständlichen Fehler beschreibt, nämlich versehentlich Trunk oder main im Quellbestand gelöscht zu haben, und dass das Team sich dank der Eigenschaften von SVN leicht davon erholen konnte.
    Die eigentliche Geschichte hinter "Die KI hat meine Datenbank gelöscht" ist vielmehr, dass Railways Datenbank-Backup-Strategie absurd intransparent ist und dass es gefährlich ist, wenn Railway KI-Infrastruktur-Orchestrierung ohne Schutzmechanismen bewirbt.
    Wenn beim Entfernen von Trunk damals irreversibel auf einem einzelnen zentralen Server gelöscht worden wäre und zugleich die Backups mitgelöscht worden wären, hätte es auch damals einen Beitrag mit dem Titel "SVN und die CLI haben unser Unternehmen ruiniert" gegeben.
    Als Railway-Nutzer fand ich diese Information nützlich und habe meine Strategie im Umgang mit Railway geändert.

    • Trotzdem gilt: Wenn man sich entscheidet, auf dieser Plattform aufzubauen, dann liegt die Verantwortung, zu verstehen, wie sie funktioniert, beim Nutzer.
      Man hätte auch eine andere Plattform wählen oder ganz auf eine Plattform verzichten können. Wenn man sich aber für Railway entscheidet, ist es auch die Verantwortung des Nutzers, zu wissen, wie man sie sicher verwendet.

  • Im Kontext des Originaltexts lag in einer nicht zusammenhängenden Datei ein Railway-Token für benutzerdefinierte Domain-Verwaltung, und es ist unklar, ob das ein lokales Geheimnis war. Jedenfalls hatte dieses Token volle Admin-Rechte für Railway.
    Die KI löschte per ID ein bestimmtes zugehöriges Volume. Der Autor beschreibt ziemlich vage, was genau er angefordert hat, und sagt nur, es habe einen "Credential-Mismatch" gegeben und Claude habe daraufhin proaktiv das Volume gelöscht, um das Problem zu beheben. Dass es so vage formuliert ist, deutet stark darauf hin, dass er seine eigene Verantwortung etwas kleinreden will.
    Außerdem wird deutlich, dass Railway Backups auf demselben Volume speichert.
    Ich halte die Formulierung im Originalbeitrag von einer "öffentlichen API zum Löschen einer Datenbank" für übertrieben.
    Unabhängig davon, ob KI beteiligt war, liegt meiner Ansicht nach der Großteil der Verantwortung bei Railway. Durch menschliche Fehler oder böswilliges Verhalten hätte dasselbe leicht passieren können.
    Ich verstehe den Wert von VC-finanzierten, stark abstrahierten Cloud-Diensten wie Railway, Vercel oder Supabase wirklich nicht. Das ist Margin auf Margin. Einen physischen Server bei Hetzner zu mieten ist deutlich günstiger, die Komplexität und das Risiko sind ähnlich, und man macht sich weniger von wachstumsfixierter Infrastruktur abhängig.

    • Mich stört auch, wie vage der Autor beschrieben hat, was er angefordert hat.
      Neulich habe ich im Gespräch mit meiner Freundin gemerkt, dass ich in den letzten drei Monaten keine einzige Zeile Code selbst geschrieben und auch kein Debugging selbst gemacht habe.
      Trotzdem erscheint es mir angesichts dessen, was Claude sonst so tut, kaum glaubhaft, dass von einem Credential-Mismatch direkt zum Löschen eines Volumes gesprungen wurde. Ich verstehe, dass LLMs probabilistisch sind, aber von "Credentials sind falsch" zu "Volume löschen" ist ein sehr unwahrscheinlicher Sprung.
      Über Supabase weiß ich nicht so viel wie über Railway/Vercel/Replit, aber bei Supabase würde ich sagen, dass es einen echten Mehrwert liefert. Gerade am Anfang spart es einem, ungefähr die Hälfte dessen selbst zu programmieren, was man sonst selbst bauen müsste. Wenn die Kosten zu hoch werden, kann man, sobald Umsatz da ist, Entwickler oder Zeit investieren und es selbst umsetzen.
    • Dass Railway Backups auf demselben Volume speichert, ist wahrscheinlich so nicht ganz korrekt.
      Snapshots werden vermutlich anderswohin synchronisiert, etwa in Objektspeicher. Wahrscheinlich gehören die Snapshots aber logisch zur Volume-Ressource, und wenn man das Volume löscht, werden die zugehörigen Snapshots mitgelöscht.
      AWS-EBS-Volumes scheinen ebenfalls so zu funktionieren.
    • Auf HN wird Heroku inzwischen ständig schlechtgeredet, aber ich sehe immer noch Wert in Heroku. Bei den anderen neueren Diensten bin ich skeptisch.
      Die Standardwerte von Firebase waren von Anfang an ebenfalls absurd.
    • Was KI stark anschieben könnte, ist ein Anti-SaaS-Trend. Es ist unendlich viel einfacher geworden, einfach irgendeinen günstigen PC zu starten und Open-Source-Pakete auszuprobieren, als sich auf einen Marktplatz voller Credentials einzulassen.
      Was allerdings nicht verschwindet, ist die Fähigkeit von LLMs, Entwicklung, Produktion, localhost und Remote durcheinanderzubringen. Ich habe beim Erstellen von Tools/Skills für opencode versucht, Chrome/DevTools mit einem linuxserver.io-Image zu koppeln; man kann es zwar auf beliebige Ports zwingen, aber sobald ein Komprimierungsereignis auftritt, will es wieder den Standardport 9222 verwenden.
      Ich überlege, einfach zurückzugehen, aber es hat sicherheitstechnischen Wert, nicht den Standard zu verwenden, und inzwischen sogar einen Sicherheitswert gegen LLM-Mehrdeutigkeit. Standards sind genau da, wo LLMs schwach werden. LLMs wollen immer Standardwerte verwenden und vergessen ständig, dass sie auf einem Remote-System arbeiten sollen.
      Es gibt in opencode keine Möglichkeit, LLMs per Protokoll auf ein Remote-System oder einen engen Tool-Umfang zur Schadensbegrenzung festzunageln. Man kann zwar Berechtigungen mehrerer Tools verändern, aber genau das war in diesem Vorfall nicht die Schwäche.
      Die Schwäche ist, dass LLMs im Durchschnitt Problemlöser sind und deshalb immer zu nicht neuartigen Anwendungsfällen tendieren; selbst wenn der Nutzer nicht die Stack-Overflow-Antwort will, versuchen sie es so zu machen, wie auf Stack Overflow.

  • Probabilistische Systeme auf LLM-Basis sind gut oder in diesem Fall schlecht darin, zu entscheiden, was getan werden soll, und deterministische Systeme sind gut darin, es auszuführen.
    Deployment-Systeme sollten immer deterministisch sein.

  • Als Gegenargument würde ich anführen, dass ziemlich klar ist, dass diese Unternehmen LLMs so feinabstimmen, dass sie entschlossener werden und Aufgaben autonom zu Ende bringen.
    Wenn sie wollten, könnten sie sie auch vorsichtiger machen und ähnlich viel Mühe darauf verwenden, dass sie an geeigneten Punkten anhalten und um Hilfe bitten.
    Natürlich liegt die letzte Verantwortung dafür, wie wir Werkzeuge einsetzen, bei uns. Aber ich denke eindeutig, dass es Verantwortung in beide Richtungen ist.
    Als Analogie würde ich eine Tischkreissäge und SawStop nehmen. Eine Tischkreissäge ist ein gefährliches Werkzeug, das meist gut funktioniert, bei manchen Fehlermustern aber katastrophale Folgen haben kann. Deshalb muss man lernen, sie vorsichtig zu benutzen.
    Gleichzeitig gibt es Technik, die das Blatt sofort stoppt und so aus einer Fingeramputation eher eine kleine Hautverletzung macht.
    Man kann sagen: "Nicht die Säge hat dir den Finger abgeschnitten, sondern du selbst", und das stimmt. Aber das heißt nicht, dass man nicht trotzdem Wege suchen sollte, damit die Säge keine Finger abschneidet.

    • Es ist ein Trade-off.
      Wenn LLMs häufiger anhalten und nachfragen, werden sie weniger nützlich. Selbst wenn das Ergebnis etwas schlechter ist, ist es viel besser, einen Agenten eine Stunde lang laufen zu lassen, als alle 15 Minuten Eingaben liefern zu müssen.
      Die echte Sicherheitslösung ist eine ordentliche Sandbox.