Ein Einfacher Secret Vault für CLI-Agenten

Was ich gebaut habe und wo die Sicherheitsgrenze verläuft

Bis September 2026 hatte ich für meine eigenen CLI-Agenten einen einfachen Secret Vault gebaut. In meinem Medium-Artikel über die Entwicklung eines Secret Managers beschrieb ich das Projekt und den Grund für seine Entstehung. Es ist kein Versuch, ausgereifte Secret Stores zu ersetzen, sondern eine praktische Antwort auf eine unangenehme Frage: Was genau erhält ein Agent, wenn er Zugriff auf ein Token bekommt?

Das Grundprinzip ist einfach: Ein Geheimnis darf nicht im Prompt, in Anweisungen oder im Repository landen. Sieht ein Agent einen API-Schlüssel als gewöhnlichen Text, können Prompt Injection oder ein fehlgeschlagener Tool-Aufruf lokale Automatisierung in einen Datenabflusskanal verwandeln. Sicherer ist es, eine undurchsichtige Referenz zu speichern und den echten Wert nur während der Ausführung eines Befehls einzufügen.

Für eine lokale CLI ist der geschützte Zugangsdaten-Speicher des Betriebssystems eine sinnvolle Grundlage. Die Dokumentation von Keeper Secrets Manager CLI beschreibt das Speichern der Konfiguration über macOS Keychain, Windows Credential Manager und Linux Secret Service. Die Python-Bibliothek keyring bietet eine einheitliche Schnittstelle zu diesen Systemmechanismen, sodass ein selbst gebauter Vault keine eigene Schlüsselablage erfinden muss.

Für den Produktionseinsatz ist es sinnvoller, die CLI vollständig von dauerhaften Geheimnissen zu trennen. Google Secret Manager und AWS Secrets Manager dokumentieren das Speichern und Abrufen von API-Schlüsseln, Passwörtern und anderen sensiblen Werten; AWS dokumentiert außerdem die Rotation. Die CLI wird in diesem Modell zum Vermittler statt zum Tresor.

Ein Vault löst jedoch nur die Speicherung. Die nächste Schicht muss kurzlebige Zugangsdaten für eine einzelne Aufgabe oder Sitzung ausgeben, den Datei- und Netzwerkzugriff des Agenten beschränken und Tool-Anfragen protokollieren. Andernfalls haben wir lediglich einen zu mächtigen Schlüssel besser versteckt.

Warum ein Vault allein nicht genügt

Der größte Gewinn ist kein neues Speicherformat, sondern die Trennung von Modell und Geheimnis. Der Agent kann das Recht behalten, eine Operation anzufordern, ohne den Wert zu sehen, der sie signiert oder autorisiert.

Für lokale Experimente ist selbst ein primitiver Vault besser als ein Token in einer Datei neben dem Projekt. Für autonome Agenten reicht das nicht aus: Least Privilege, Sandboxing, Zugriffs-Widerruf, Rotation und ein Aktionsprotokoll sind erforderlich. Am schlechtesten schneidet weiterhin das vertraute Muster eines dauerhaften Universalschlüssels in den Umgebungsvariablen jedes Prozesses ab.

Ich würde zuerst nicht die Verschlüsselung des Speichers prüfen, sondern den Weg des Geheimnisses nach dem Abruf. Besonders gefährlich sind Befehlszeilenargumente, Logs, Fehlerdumps und der Modellkontext. Ohne Kontrolle der letzten Meile wird selbst ein gutes Backend zu einer teuren Methode, ein Geheimnis an die falsche Stelle zu senden.

Deshalb ist mein primitiver Vault eher als Ausgangspunkt für die richtige Architektur interessant. Die tatsächliche Sicherheitsgrenze verläuft nicht um eine Datei mit Schlüsseln, sondern um jede Operation, die ein Agent im Namen des Nutzers ausführen kann.

Wir haben bereits untersucht, wie Secret Storage in Obsidian die Sicherheit von Plugins und KI-Automatisierung beeinflusst. Diese Grundsätze sind auch beim Entwurf eines Secret Vaults nützlich, auf den Agenten zugreifen.