Dein Agent braucht ein Datenbank-Passwort oder einen API-Key. Statt ihn in den Chat zu tippen, gibst du ihn im Browser ein, und er geht direkt an den einen Befehl, den du gesehen hast. Der Agent bekommt das Ergebnis, nie den Wert.
Was du in eine Agenten-Sitzung tippst, bleibt im Verlauf, im Sitzungsprotokoll auf deiner Platte und beim Modellanbieter. Wir haben es bei uns selbst gemessen: 68 von 70 Deployment-Geheimnissen standen im Klartext in Sitzungsprotokollen. Rotieren hilft nichts, solange der nächste Wert denselben Weg nimmt.
Node.js 20 oder neuer, keine weiteren Abhängigkeiten:
npm install -g @erseni/vault-ask Oder direkt aus dem öffentlichen Quellcode, ohne npm:
git clone https://gitlab.erseni.net/open-source/secrets-component.git npm install -g ./secrets-component/cli Der Standard: der Wert existiert nur als Umgebungsvariable dieses einen Kindprozesses. Auf die Platte wird nichts geschrieben.
vault-ask DB_PASSWORD -- psql -h db.example.com -U app Für Werte, die bleiben sollen: in eine .env-Datei mit Rechten 600.
vault-ask STRIPE_KEY SENTRY_DSN --env-file .env Für Schlüssel und Zertifikate: ein Wert in eine Datei, Rechte 600.
vault-ask TLS_KEY --file certs/server.key Einen Weg, der den Wert ausgibt, gibt es bewusst nicht. Mehrere Namen in einem Aufruf ergeben eine Seite mit mehreren Feldern.
Bitte deinen Agenten um ein neues Passwort, und du bekommst einen Einmal-Link statt des Passworts im Chat. vault-ask send erzeugt den Wert auf dem Rechner des Agenten, verschlüsselt ihn dort und schreibt denselben Wert in die .env-Datei oder den Befehl, der ihn braucht, damit dein System und dein Link übereinstimmen.
vault-ask send DB_PASSWORD --env-file .env Der Link zeigt den Wert einmal und ist danach verbraucht. Senden zählt auf dasselbe Tageskontingent wie Anfragen.
All das fängt Versehen ab und macht einen manipulierten Agenten sichtbar. Einen Agenten, der unter deinem eigenen Betriebssystem-Benutzer mit Shell läuft, macht es nicht harmlos: er kann den Speicher von Prozessen lesen, die er gestartet hat. Vollständigen Schutz gibt es nur durch Rechtetrennung, bei der ein Dienst unter einem anderen Benutzer das Geheimnis hält und der Agent nur einen Verweis darauf bekommt. Das steht so in unserem Threat Model, statt mehr zu versprechen, als der Code hält.
vault-ask-mcp bietet dieselben Bausteine als MCP-Werkzeuge: request_secret schreibt einen Wert in eine Datei, run_with_secret startet einen Befehl damit, send_secret schickt dir einen erzeugten Wert als Einmal-Link. Der Server sagt dem Agenten zu Beginn jeder Sitzung, wann welches Werkzeug dran ist, deshalb führt „generier mir ein Passwort für meine Datenbank“ ohne jede Einrichtung zu einem Link.
claude mcp add vault-ask -- vault-ask-mcp export VAULT_ASK_API_KEY=vak_...