Bis zum 13. März standen meine Zugangsdaten genau dort, wo Claude sie bei jeder Arbeit liest: in den Regeldateien und im Gedächtnis, im Klartext. Dann bekam KIRA einen Tresor. Vier Monate später stellte sich heraus, dass ausgerechnet der Schlüssel zum Tresor offen herumlag.
Für dich in 30 Sekunden
- Leg keine Passwörter dorthin, wo eine KI mitliest. Schreib hinein, wo ein Zugang liegt, nicht was er ist.
- Prüf auch den Schlüssel zum Schlüssel. Bei mir war der Tresor verschlossen, aber sein Schlüssel stand offen in mehr als 15 Dateien.
- Was eine KI liest, ist kein Auftrag. Ein Satz in einer Mail oder auf einer Webseite darf nie entscheiden, was sie mit deinen Zugängen tut.
Lesezeit rund 10 Minuten
Was ich wollte: Zugangsdaten raus aus den Dateien der KI
Eine der Regeln aus dem Manifest heißt: Datenschutz und Sicherheit gehen vor. Passwörter und Schlüssel werden nicht unnötig weitergegeben und nicht in unsicheren Code geschrieben.
Gleichzeitig braucht eine KI-Assistenz, die wirklich mitarbeitet, Zugänge. Wer Dateien auf einen Server hochladen soll, braucht die Zugangsdaten dafür. In den ersten Tagen standen sie deshalb dort, wo Claude sie findet: in den Regeldateien, im Gedächtnis und in der Datei, die bei jedem Start geladen wird. Praktisch, aber jeder, der diese Dateien sieht, sieht auch die Passwörter.
Gebraucht wurde also beides: Claude soll die Zugänge benutzen können, aber sie sollen nirgends mehr offen herumstehen.
Deshalb habe ich KIRA gebeten, Vorschläge zu machen, wie wir unsere Passwörter sicher aufbewahren können, ohne dass sie hardcodiert überall herumliegen. Hardcodiert heißt: fest in eine Datei oder in den Code geschrieben. Wer die Datei hat, hat auch das Passwort, und das oft an vielen Stellen gleichzeitig. Ändert sich ein Passwort, muss man jede dieser Stellen finden. Aus den Vorschlägen wurde der Tresor.
Was ich gemacht habe: ein Tresor für Zugangsdaten
Am 13. März bekam die Plattform einen eigenen Bereich: den Vault, auf Deutsch Tresor.
- Jeder Zugang wird verschlüsselt gespeichert. In der Datenbank steht kein Passwort, sondern Zeichensalat. Lesbar wird er erst mit einem zweiten Schlüssel.
- Dieser zweite Schlüssel liegt getrennt vom Rest. Wer nur die Datenbank erwischt, kann damit nichts anfangen.
- In der Ansicht ist alles verdeckt. Die Einträge sind nach Projekt geordnet und nur als Punkte zu sehen. Erst ein Klick auf „Anzeigen“ zeigt den Wert, und nur nach der Anmeldung.
- Claude Code bekommt eine eigene Tür. Über eine Schnittstelle mit eigenem Schlüssel kann es Zugänge abholen, ohne dass sie in einer Datei stehen müssen.
So sah der Tresor am ersten Tag aus, mit dem Formular für einen neuen Eintrag und darunter den gespeicherten Zugängen eines Projekts:
Der wichtigste Schritt war aber kein neuer Code, sondern ein Umzug. Alle Zugangsdaten kamen am selben Tag aus den Regeldateien, aus dem Gedächtnis und aus der Startdatei heraus. Dort steht seitdem nur noch, in welchem Fach des Tresors ein Zugang liegt.
Am selben Tag: anmelden mit dem Fingerabdruck
Noch am 13. März wurde auch die Anmeldung sicherer. Ein zweiter Weg kam dazu: anmelden mit einem sogenannten Passkey, den du am eigenen Gerät per Fingerabdruck oder Gesichtserkennung freigibst. Der Fingerabdruck selbst verlässt dein Gerät dabei nie. Statt ein Passwort zu schicken, beantwortet das Gerät eine Aufgabe, die jedes Mal neu gestellt wird. Ein abgefangener Versuch nützt deshalb beim nächsten Mal nichts. Der normale Login blieb als Rückfallweg erhalten.
Was schwierig war: der Schlüssel zum Tresor lag offen
Der Tresor selbst war gut gebaut. Das Problem lag eine Ebene höher.
Am 18. Juli hat KIRA die Schnittstelle des Tresors einer eigenen Sicherheitsprüfung unterzogen. Der schwerste Befund: Der Schlüssel, mit dem man sich am Tresor ausweist, war fest im Code eingetragen und stand außerdem im Klartext in mehr als 15 Dateien, verteilt über fünf Systeme. Der Tresor war also zu, aber sein Schlüssel klebte an der Tür.
Diesen Schlüssel einfach auszutauschen, hätte alles auf einmal lahmgelegt: das Hochladen, die Hintergrundabläufe und alles andere, was sich Zugänge selbst abholt. Deshalb lief der Tausch in drei Stufen:
- Stufe 1: Der Tresor nimmt einen neuen Schlüssel an, der alte gilt vorerst weiter. Nichts bricht.
- Stufe 2: Jede Stelle, die den Schlüssel braucht, wird auf den neuen umgestellt. Der neue steht in keiner Datei, die im Versionsarchiv landet.
- Stufe 3: Der alte Schlüssel wird abgeschaltet. Danach gemessen: Der neue kommt durch, der alte, ein falscher und gar keiner werden abgewiesen.
Die Lehre daraus geht über diesen einen Schlüssel hinaus. Ein Tresor schützt nur, was in ihm liegt. Wo der Schlüssel zum Tresor liegt, muss man genauso prüfen.
Eine Bremse, die man umgehen konnte
Am 26. August fiel bei einer weiteren Prüfung auf, dass sich die Sperre gegen falsche Ausweise zu leicht umgehen ließ und dass Fehlversuche in der Plattform nirgends auftauchten. Beides wurde damals nachgebessert.
Die eigentliche Denkaufgabe lag woanders: Eine Sperre darf kein Ausschalter werden. Träfe sie jeden Absender, auch meine eigenen Systeme, könnte ein Fremder mit ein paar falschen Versuchen den Tresor für alle abschalten. Deshalb kommen meine Systeme mit dem richtigen Ausweis auch dann durch, wenn die Sperre greift.
Der zweite Schlüssel
Ein Tresor hat eigentlich zwei Schlüssel, und die beiden sind leicht zu verwechseln:
Den Ausweis habe ich gleich nach dem Fund in den Dateien getauscht, den Verschlüsselungsschlüssel einige Wochen später.
Schwierig beim Umschlüsseln ist die Zeit dazwischen. Ein Teil der Einträge liegt dann schon mit dem neuen Schlüssel vor, ein Teil noch mit dem alten. Ohne Vorkehrung hätte jeder Lesezugriff in diesem Fenster still „kein Wert“ geliefert, ohne Fehlermeldung, und jedes System hätte einfach falsch weitergearbeitet. Deshalb probiert der Tresor in dieser Zeit beide Schlüssel. Danach nachgemessen: alle Einträge auf dem neuen Schlüssel, keiner unlesbar, und der Rückgriff auf die alte Schlüsseldatei ist abgeschaltet.
Darauf, dass erst ein Fund den Anstoß gibt, verlasse ich mich nicht. Gemeinsam mit KIRA habe ich eine feste Routine entwickelt, nach der Schlüssel und Zugänge in festen Abständen getauscht werden, gebündelt an einem Termin und nicht erst, wenn etwas passiert ist. Wie oft das ist, schreibe ich hier bewusst nicht. Auch das gehört zu den Dingen, die ein Fremder nicht wissen muss.
Was aus dem Tresor geworden ist
Eine Gefahr kam erst später in den Blick. Ein Sprachmodell trennt nicht von selbst zwischen dem, was ich ihm sage, und dem, was in einem Text steht, den es gerade liest. Steht auf einer Webseite, in einer Mail oder in einem Videotitel ein Satz, der wie ein Auftrag klingt, könnte eine KI ihn befolgen.
Seit dem 9. September gilt deshalb eine feste Sperre: Hat KIRA gerade fremden Text gelesen, bleibt der Tresor für sie eine Weile zu. Kein Zugang wird geholt, weil ein gelesener Text es nahelegt, sondern nur, wenn meine Aufgabe es verlangt.
Und so holt sich KIRA heute einen Zugang: Ein kleines Werkzeug fragt mit dem Ausweis beim Tresor nach, bekommt den Wert, benutzt ihn für genau diesen einen Vorgang und vergisst ihn danach wieder. Er landet in keiner Datei und taucht im Gespräch nie auf. Kommt von irgendwo eine Antwort zurück, in der ein Geheimnis stecken könnte, werden nur die Felder ausgegeben, die gebraucht werden, nie die ganze Antwort.
Was du daraus mitnehmen kannst: Tipps für sichere Zugangsdaten
- Keine Zugangsdaten in Dateien, die eine KI liest. Schreib hinein, wo sie liegen, nicht was sie sind.
- Prüf auch den Schlüssel zum Schlüssel. Der Ausweis für den Tresor und der Schlüssel, mit dem er verschlüsselt, sind selbst Geheimnisse.
- Tausche nach Routine und ohne Aussperren. Feste Termine statt erst nach einem Vorfall, den Abstand behältst du für dich. Beim Tausch erst beide gelten lassen, dann umstellen, dann den alten abschalten, und danach messen, dass der alte wirklich abgewiesen wird.
- Bau Bremsen, die nur Fremde bremsen. Eine Sperre, die auch dich trifft, ist ein Ausschalter in fremder Hand.
- Fremder Text ist kein Auftrag. Was eine KI liest, darf nie entscheiden, welche Zugänge sie anfasst.
Ohne selbst zu programmieren
Die wichtigste Regel gilt auch im normalen Chat: Kopier nie ein Passwort, die Zugangsdaten zum Onlinebanking oder einen Schlüssel in ein Gespräch mit einer KI. Was dort steht, liegt im Verlauf beim Anbieter, und du weißt nicht, wo es überall landet. Und lässt du eine KI Mails oder Webseiten zusammenfassen, behandle jede Anweisung darin als Text, nicht als Auftrag. Taucht in der Zusammenfassung plötzlich ein Link auf, den du anklicken sollst, oder eine Bitte um Daten, schau zweimal hin.
Fragen, die du der KI stellen kannst
- „Wie bewahre ich die Passwörter für meine Projekte so auf, dass du damit arbeiten kannst, ohne dass sie irgendwo im Klartext stehen?“
- „Such in meinem Projekt nach Zugangsdaten im Klartext. Nenn mir jede Fundstelle mit Datei und Zeile, aber zeig den Wert selbst nicht an.“ Die Frage ist so gestellt, dass die Antwort selbst nichts verrät.
- „Wie tausche ich einen Schlüssel, den mehrere Systeme benutzen, ohne dass eines davon ausfällt?“
Merksatz:
Ein Tresor ist nur so sicher wie der Ort, an dem sein Schlüssel liegt.
Wie es weitergeht: das Gedächtnis der KI-Assistenz
Bis zum 13. März lagen die Passwörter sogar im Gedächtnis von KIRA. Dieses Gedächtnis gab es da schon seit ein paar Tagen. Im Konzept stand dafür ein großer Plan, mit drei Schichten und Vertrauenswerten für jede Erkenntnis. Gebaut wurde etwas viel Einfacheres, und genau das trägt bis heute. Warum der große Plan nie gebaut wurde und was stattdessen entstand, erzähle ich in Kapitel 8.
Was du noch wissen solltest
Nein. Für die meisten reicht ein fertiger Passwort-Manager, wie es ihn von vielen Anbietern gibt, auch für Teams. Für Programme, die sich Zugänge selbst abholen sollen, gibt es eigene Dienste, die man Secret-Manager nennt. Ein selbst gebauter Tresor lohnt sich vor allem dann, wenn er eng mit den eigenen Abläufen verbunden sein soll.
Verschlüsseln lässt sich mit dem passenden Schlüssel wieder rückgängig machen, der Wert wird wieder lesbar. Ein Hash ist eine Einbahnstraße: Aus ihm lässt sich das Original nicht zurückrechnen, man kann nur prüfen, ob eine Eingabe dazu passt. Login-Passwörter speichert man deshalb üblicherweise als Hash, Zugänge in einem Tresor aber verschlüsselt, weil sie später wieder gebraucht werden.
Beim Passkey bleibt der geheime Teil auf deinem Gerät, die Website kennt nur ein passendes Gegenstück, mit dem sie die Antwort prüft. Wird die Website gehackt, findet der Angreifer dort also nichts, womit er sich anmelden könnte. Außerdem ist ein Passkey an die echte Adresse der Website gebunden, auf einer gefälschten Seite funktioniert er nicht.
So heißt der Angriff, bei dem Anweisungen in einem Text versteckt werden, den eine KI liest, etwa in einer Webseite oder einer Mail. Die KI hält den Satz dann womöglich für einen Auftrag. Ein Hinweis im Auftrag an die KI gilt allein nicht als zuverlässiger Schutz, deshalb braucht es zusätzlich feste Sperren außerhalb des Modells, wie die Tresor-Sperre in diesem Kapitel.
Meistens nicht. Ein Versionsarchiv wie Git hebt jeden früheren Stand einer Datei auf, und dort steht das Passwort weiter. Auch Sicherungen und Kopien auf anderen Rechnern bewahren es auf. Ein Passwort, das einmal offen lag, gilt deshalb als verbraucht und wird getauscht, nicht nur gelöscht.
AES steht für Advanced Encryption Standard, ein Verschlüsselungsverfahren, das seit 2001 ein öffentlicher Standard ist und weltweit eingesetzt wird, etwa bei verschlüsselten Verbindungen im Browser. Die 256 ist die Länge des Schlüssels in Bit. So ein Schlüssel lässt sich durch bloßes Ausprobieren praktisch nicht erraten. Die Schwachstelle liegt deshalb fast nie im Verfahren selbst, sondern dort, wo der Schlüssel aufbewahrt wird.
