Das Werkzeug, das zu viel zurückgab

Die Zugangsdaten in meinen KI-Transkripten kamen meist als Antworten von Werkzeugen zurück, nicht aus meinen Eingaben. Wie das passiert ist, und das Werkzeug, das keine zurückgeben kann.

Am 23. September 2026 verschob Claude zwei Einträge in meinem Passwort-Manager mit einem fertigen MCP-Server (einem Plug-in, über das der Assistent ein Werkzeug aufruft). Jeder Aufruf lieferte den ganzen Eintrag samt Passwortverlauf und Notizen. Nach den zwei Ordnerwechseln stand rund ein Dutzend Passwörter im Klartext in einem einzigen archivierten Transkript.

Woher die Lecks kamen

Am 26. August durchsuchte eine Überprüfung mein Sitzungsarchiv und fand 124 verschiedene Zugangsdaten an 11.821 Stellen in 431 Dateien, manche bis zu fünf Monate lang ungeschützt. Einige hatte ich im Juli selbst eingefügt; die meisten kamen wörtlich aus Werkzeugen zurück. Die Notiz mit den Lehren vom 2. September: „Secrets leak through tool results, not through prose.“

Wie Zugangsdaten in die Transkripte kamen: über Tool-Antworten – und der Aufbau, der ihnen keinen Platz lässt.

Drei weitere, nach der Lektion

Noch am Tag, an dem die Lektion aufgeschrieben wurde, passierte es wieder. Am selben Abend ließ ein Hilfsagent von Claude ein Skript mit bash -x laufen, was jeden Befehl mit eingesetzten Variablen ausgibt, und drei Zugangsdaten landeten in der Ausgabe.

Am 17. September ließ ich Claude Infisical, einen selbst gehosteten Secrets-Manager, auf meinem Heimserver Yavin* installieren. Claudes nächste Suche im Passwort-Manager war zu breit, und der Connector gab alle drei neuen Einträge vollständig zurück. Claudes Notiz: „That over-broad call was mine.“ Um Viertel vor drei lief schon eine zweite Generation, mit frischen Schlüsseln.

Rotieren statt schwärzen

Am 26. August bereinigten Claude und ich das Archiv: 11.821 Ersetzungen. Doch meine Transkripte werden mit Absicht aufbewahrt, in Snapshots und Backups; Bereinigen säubert eine Kopie. Rotieren, also die Zugangsdaten an der Quelle ersetzen, macht alle Kopien auf einmal wertlos; bei mir geschah das in Etappen, den September hindurch.

Das Passwort, das keinen Rechner erreichte

Am 11. September um 17:41 habe ich mein Mail-Passwort in Vaultwarden geändert und Laptop, Handy und Tablet von Hand nachgezogen. Fünf weitere Kopien auf drei Rechnern behielten das alte, und die Mail-Jobs scheiterten bis zum Montag rund 1.400-mal.

Im Juli hatte ich Vaultwarden zur maßgeblichen Quelle für Server-Secrets erklärt, aber nichts las daraus: Der Verteilcode setzte eine Funktion voraus, die Vaultwarden fehlt, und nichts prüfte, ob verteilte Passwörter noch funktionierten. Die erste Lehre aus dem Review: „A secret store nothing reads is documentation, not infrastructure.“

Drei Tage, fünf veraltete Kopien: die Rotation vom 11. September und der tägliche Test, der daraus wurde.

Was Claude und ich stattdessen gebaut haben

Am 14. September ein Verteilwerkzeug: eine Liste aller verteilten Kopien, Werte vom Passwort-Manager auf den Rechner, am Chat vorbei, und ein täglicher Test jeder Kopie, per Anmeldung, wo der Dienst es erlaubt. Am 17. September Infisical als Speicher nur für Maschinen, denn ein Passwort-Manager, den ein Mensch entsperren muss, kann keine Nachtjobs versorgen. Am 23. September ein Passwort-Manager-Werkzeug für den Assistenten, das nur Namen, Ordner, Typen, Datumsangaben und Ja/Nein-Merkmale ausgibt; an einer Attrappe des Passwort-Managers getestet, ersetzte es am selben Tag den fertigen Connector.

Das Muster

Secrets nur per Verweis, durchgesetzt von Werkzeugen, die nicht lecken können; rotieren statt schwärzen. Mein Regelwerk wies den Assistenten seit Juli an, keine Secrets auszugeben; die Antworten der Werkzeuge enthielten sie trotzdem. Gehalten hat ein Werkzeug, dessen Antwort kein Feld für einen Wert hat. Bevor ich ein Werkzeug anbinde, frage ich heute, was das Größte ist, das es zurückgeben kann.

Gelöst ist nicht alles. Die Sperre gegen das Lesen ganzer Einträge greift in Claude Code, aber, wie wir am 23. September feststellten, nicht in der Desktop-App; dort schützt allein, dass der alte Connector weg ist. Noch nutzen nicht alle Jobs den Maschinenspeicher.

Teil 8 von zwölf in der Serie darüber, wie ich mein AI OS gebaut habe. Der Anfang: das Vorwort.

Als Nächstes: unter Aufsicht bauen, unbeaufsichtigt laufen lassen – warum die KI sich weigerte, an meinen Servern zu arbeiten, während ich weg war, und damit recht hatte.

* Rechnernamen sind geändert (hier: Yavin, mein Heimserver). Die echten stammen aus einer anderen Saga.

Anhang – für alle, die selbst bauen

Lies die Werkzeugliste eines Connectors, bevor du ihn installierst. Frag, was jeder Aufruf höchstens zurückgeben kann; eine Liste oder Suche mit ganzen Datensätzen liefert eines Tages ein Secret mit.
Nimm lieber eine Projektion. Ein Werkzeug mit fester Feldauswahl kann kein Feld verraten, das ihm fehlt. Teste es an einer Attrappe des Passwort-Managers mit erfundenen Werten.
Bewege Werte von Rechner zu Rechner, nie durch den Chat. Der Assistent braucht Namen und Ergebnisse, keine Werte.
Lass kein Skript, das Secrets lädt, mit Trace laufen. bash -x und set -x geben die eingesetzten Variablen aus.
Erfasse alle Kopien in einer Liste, bevor du rotierst, und prüfe täglich, ob jede noch funktioniert.
Durchsuche dein Transkript-Archiv nach festem Plan und lass dir den Fundort melden, nicht den Fund.
Rotieren statt schwärzen. Archive und Backups sind mit Absicht unveränderlich; wer Zugangsdaten an der Quelle ersetzt, macht jede Kopie nutzlos.
Was ich stattdessen erwogen habe: den fertigen Connector mit strengeren Regeln (die Regel versagte dreimal); den Cloud-Secrets-Dienst vom Hersteller des Passwort-Managers (Maschinen-Secrets bei einem US-Anbieter, gegen meinen Weg zu europäischer Infrastruktur); dessen selbst gehostete Ausgabe (eine Enterprise-Lizenz und der Abschied von Vaultwarden); Vaultwarden allein mit dem Verteilwerkzeug (braucht einen Menschen, der entsperrt). Ich wählte ein reines Metadaten-Werkzeug für den Passwort-Manager plus selbst gehostetes Infisical: die einzige Kombination, die unbeaufsichtigt auf meiner eigenen Hardware läuft.