So gibst du einem KI-Coding-Agenten einen API-Key, ohne dass er den Wert je sieht

Coding-Agenten wie Claude Code, Cursor oder Codex brauchen Datenbank-Passwörter und API-Keys, um zu deployen, zu migrieren und zu testen. Die üblichen Wege, sie zu übergeben, bringen den Wert in den Kontext des Agenten und von dort in die Sitzungsprotokolle auf der Platte und in die Anfragen an den Modellanbieter. Dieser Ratgeber zeigt, wo der Wert durchsickert, welche Regeln ihn tatsächlich draußen halten und wie du das in wenigen Minuten einrichtest.

Kurz gesagt

Was ein Werkzeug ausgibt, liest der Agent, und was der Agent liest, bleibt in seinem Sitzungsprotokoll.
Aus dem Kontext bleibt ein Secret nur, wenn es direkt an den Prozess geht, der es braucht, und nie an die Standardausgabe.
vault-ask erledigt das für jeden Agenten mit Shell oder MCP: Du gibst den Wert im Browser ein, er erreicht genau einen Befehl oder eine Datei, und die Ausgabe ist maskiert.

Warum der Kontext der falsche Ort für ein Secret ist

Ein Agent arbeitet, indem er Werkzeuge ausführt und ihre Ausgabe liest. Diese Ausgabe wird Teil des Gesprächs: Sie geht mit jeder folgenden Anfrage an das Modell und landet im Sitzungsprotokoll auf deinem Rechner. Ein Wert, der dort einmal auftaucht, bleibt dort, lange nachdem die Aufgabe erledigt ist. In unserer eigenen Messung standen nach vier Wochen 68 von 70 Deployment-Secrets im Klartext in den Sitzungsprotokollen eines Coding-Agenten, und keines davon war in den Chat getippt worden.

Wie die 68 von 70 gemessen wurden

Vier übliche Wege und wo jeder davon leckt

Den Key in den Chat einfügen: Der Wert steht ab der ersten Sekunde im Gespräch, im Protokoll und in jeder späteren Anfrage an das Modell.
Eine .env-Datei im Projekt: Früher oder später liest der Agent sie beim Debuggen, mit cat, grep oder einer Suche über das Projekt, und der Dateiinhalt steht in der Ausgabe.
Die Variable vor dem Start des Agenten in der Shell exportieren: Der Agent erbt sie, und env, printenv, ein Debug-Log oder ein Stacktrace gibt sie aus.
Den Wert mit der CLI eines Secret-Managers holen, etwa op read oder vault kv get: Der Befehl schreibt den Wert auf die Standardausgabe, also genau dorthin, wo der Agent liest.

Das Muster ist immer dasselbe: Der Agent macht nichts falsch, ein Werkzeug gibt den Wert aus, und der Agent liest, was Werkzeuge ausgeben.

Drei Regeln, die den Wert tatsächlich draußen halten

Der Wert geht an den Prozess, nicht an die Ausgabe. Er steckt in der Umgebung genau eines Kindprozesses oder in einer Datei mit engen Rechten, und kein Schritt gibt ihn aus.
Die Ausgabe ist maskiert. Gibt der Befehl den Wert selbst aus, etwa in einer Fehlermeldung, wird er ersetzt, bevor der Agent ihn sieht, auch in kodierten Formen wie Base64.
Der Wert ist an seinen Zweck gebunden. Du siehst vor der Eingabe, für welchen Befehl oder welche Datei er bestimmt ist, und er lässt sich danach nicht an einen anderen Befehl umleiten.

Wenn du schon einen Secret-Manager nutzt

Run-Befehle wie op run von 1Password oder doppler run halten die erste Regel schon ein: Sie geben den Wert einem Prozess mit, statt ihn auszugeben, und op run maskiert ihn zusätzlich in der Ausgabe. Nimm diese statt read- oder get-Befehlen. Nicht abgedeckt ist der Moment, in dem der Wert fehlt: Ohne Chat kann der Agent dich nicht danach fragen, und nichts bindet den Wert an den Befehl, für den er gedacht war.

Einrichten mit vault-ask

vault-ask ist ein kleines Open-Source-Kommandozeilenwerkzeug mit MCP-Server für Node.js 20 oder neuer, ohne Abhängigkeiten.

npm install -g @erseni/vault-ask

Der Agent fordert den Wert für genau einen Befehl an:

vault-ask DB_PASSWORD -- psql -h db.example.com -U app

vault-ask gibt einen Link aus. Du öffnest ihn im Browser, siehst den Befehl, für den der Wert gedacht ist, und gibst den Wert ein. Er kommt Ende-zu-Ende verschlüsselt an, geht nur in die Umgebung dieses Befehls, und der Agent sieht nur eine Zeile wie „DB_PASSWORD received, 32 characters, passed to the command“.

Für Werkzeuge, die eine Datei lesen, landet der Wert in einer .env-Datei oder in einer einzelnen Datei mit den Rechten 600:

vault-ask STRIPE_KEY SENTRY_DSN --env-file .env vault-ask TLS_KEY --file certs/server.key

In Claude Code fügst du den MCP-Server einmal hinzu. Danach fragt der Agent von selbst nach Secrets, statt dich zu bitten, sie einzufügen:

claude mcp add vault-ask -- npx -y @erseni/vault-ask mcp

In Cursor oder einem anderen MCP-Client trägst du den Server in die MCP-Konfiguration ein (bei Cursor in ~/.cursor/mcp.json):

{ "mcpServers": { "vault-ask": { "command": "npx", "args": ["-y", "@erseni/vault-ask", "mcp"] } } }

Ein Wächter gegen das spätere Lesen der Datei

Ein Wert in einer Datei lässt sich später trotzdem lesen. Für Claude Code bringt vault-ask deshalb vault-ask-guard mit, einen PreToolUse-Hook, der das Lesen der von vault-ask geschriebenen Dateien ablehnt und Befehle wie env oder echo als Ziel verweigert. Trag ihn in .claude/settings.json ein:

{ "hooks": { "PreToolUse": [ { "matcher": "Bash|Read|Edit|MultiEdit|Write|Grep|Glob|NotebookEdit|mcp__vault-ask__run_with_secret|mcp__vault-ask__send_secret", "hooks": [{ "type": "command", "command": "vault-ask-guard" }] } ] } }

Wo der Schutz aufhört

Diese Regeln fangen Versehen ab, und sie machen einen manipulierten Agenten sichtbar, weil er dich für jeden neuen Befehl erneut fragen müsste. Sie halten keinen Agenten auf, der unter deinem eigenen Betriebssystem-Nutzer mit einer Shell läuft und gezielt Speicher oder Umgebung eines Prozesses liest, den er selbst gestartet hat. Vollständiger Schutz braucht Rechtetrennung: Das Secret hält ein Dienst unter einem anderen Nutzer, der Agent nur einen Verweis darauf.