inflightsec/agent-vault-proxyJust-in-time API-Schlüssel für KI-Agenten - und jeden anderen Prozess, den du darüber leitest: Der Aufrufer sieht nur einen Platzhalter.
Just-in-time-API-Schlüssel für KI-Agenten und jeden anderen Prozess, den du darüber leitest: Der Aufrufer sieht immer nur einen Platzhalter.
Früher agent-vault-proxy. Das CLI heißt jetzt kow; der alte Befehl avp funktioniert in dieser Version noch und wird im nächsten Major-Release entfernt (ADR-0045).
Keys on the Wire schützt dich vor Credential-Stealern (Shai-Hulud und ähnlichen) und vor prompt-injizierten Agenten, die deine Geheimnisse preisgeben. Es ist ein lokaler Proxy, der echte Geheimnisse direkt in laufende Requests injiziert, sodass ein kompromittierter oder prompt-injizierter Agent nichts zu stehlen hat.
Im Hintergrund: ein Loopback-HTTPS-Proxy, der Anmeldedaten von Bitwarden Secrets Manager (Cloud oder selbst gehostet) just-in-time abruft und sie in ausgehende Requests injiziert, sodass der aufrufende Prozess die echten Credential-Bytes nie im eigenen Adressraum hält.
Jede Funktion befindet sich in diesem Repository unter Apache-2.0, ohne kostenpflichtige Stufe, Enterprise-Edition, Trusted Cloud oder Telemetrie. Du kannst das Ganze von Anfang bis Ende lesen (ein paar tausend Zeilen) und es für immer ausführen.
Der gesamte Workflow ist ein einziger Schritt: Bitte die mitgelieferte Skill, einen Dienst zu routen, sie nennt dir die eine Zeile, die du in Bitwarden (oder deinen Tresor) einfügst, du fügst sie ein und der Agent ist vermittelt. Fertig. Da jede vermittelte Anmeldeinformation genau eine Bindung ist, ist die Konfiguration die vollständige, prüfbare Liste darüber, welche Secrets genau jeder Agent erreichen kann: nichts Implizites oder Verborgenes.
Das Ziel ist überall weniger echte Schlüssel in KI-Agenten, nicht Lock-in. Wenn Keys on the Wire passt, nutze es; wenn eine der Alternativen besser zu deinem Setup passt, nutze die. Jedes Tool, das das echte Geheimnis aus dem Speicher des Agenten heraushält, ist ein Gewinn.
1. Installieren – Linux pipx, macOS brew:
pipx install 'keys-on-the-wire[bitwarden]' # [bitwarden] adds the Bitwarden backend SDK; drop it for AWS/GSM/env only
# macOS: brew install inflightsec/keys-on-the-wire/keys-on-the-wire
sudo kow setup --bws # paste your Bitwarden token — generates the CA, starts the daemon
2. Skill installieren, damit dein Agent die Bindung für dich schreibt:
/plugin marketplace add inflightsec/agent-vault-proxy
/plugin install avp@agent-vault-proxy
3. Die Skill bitten, einen Dienst zu vermitteln – sag „Route die Stripe-API durch Keys on the Wire." Sie erstellt den Platzhalter und gibt dir den genauen Hinweis zum Einfügen in Bitwarden aus; sie sieht deinen Schlüssel nie.
4. Das Geheimnis in deinen Tresor legen – füge den echten Schlüssel mit diesem Hinweis im Bitwarden Secrets Manager (oder Google Secret Manager) hinzu und route deinen Agenten dann durch den Proxy:
kow env && kow run claude
Fertig: Der Agent sendet immer nur den Platzhalter; Keys on the Wire tauscht den echten Schlüssel während der Übertragung ein.
Statt kow run kannst du die Proxy- und CA-Variablen auch in der ~/.zshrc (oder einer beliebigen Shell-rc) deines Agenten exportieren – siehe Usage für den kanonischen Block. Das ist persistent, routet aber deine gesamte Shell durch Keys on the Wire, nicht nur den davon gestarteten Agenten.
Das Onboarding einer neuen vermittelten Anmeldeinformation sollte nicht bedeuten, Binding-YAML von Hand zu schreiben. Die mitgelieferte avp-Skill lässt dich von einem KI-Assistenten (Claude Code oder jedem Agenten, der Skills lädt) durch den Prozess führen: Du sagst „Route die Acme-API durch Keys on the Wire", sie fragt nach der Auth-Form und dem Host und sagt dir dann genau, was du hinzufügen sollst: den Secret-Namen plus die Annotation, die du in das Notizenfeld des Bitwarden Secrets Managers (oder die avp-binding-Annotation des Google Secret Managers oder die Pro-Secret-Metadaten eines zukünftigen Backends) einfügst. Keine Konfigurationsänderung oder Neubereitstellung, und der Assistent sieht oder speichert das Secret nie; er schlägt vor, du führst aus.
Der Hinweis selbst besteht aus zwei Zeilen, die in das Notizenfeld des Secrets eingefügt werden:
# avp-binding
api.acme.com
Die Markerzeile macht es zu einer Bindung: Ein Hinweis, dessen erste Zeile nicht # avp-binding ist, bleibt das, was er ist – eine menschliche Beschreibung – und wird nie geparst (ADR-0025). (Die Markierung avp-binding und die Pfade auf der Festplatte behalten in dieser Version ihre Namen aus Gründen der Abwärtskompatibilität; im nächsten Major-Release wechseln sie zu kow – siehe ADR-0045.)
Claude Code (empfohlen) – installiere sie als Plugin, damit sie in jedem Projekt verfügbar ist und mit /plugin marketplace update aktualisiert wird:
/plugin marketplace add inflightsec/agent-vault-proxy
/plugin install avp@agent-vault-proxy
Rufe sie als /avp:avp auf oder sag einfach „Route die Acme-API durch Keys on the Wire", und sie wird von selbst ausgelöst. (Das gebündelte Plugin behält vorerst den Namen avp; es wird mit der Marketplace-Migration umbenannt.)
Manuell (jeder Agent, der Anthropic-Format-Skills lädt) – kopiere oder verlinke skills/avp/ in das Skill-Verzeichnis deines Agenten; Claude Code liest ~/.claude/skills/. Ein Symlink hält sie bei git pull aktuell:
ln -s "$PWD/skills/avp" ~/.claude/skills/avp
MCP-Server sind eine schnell wachsende Angriffsfläche für Credential-Leaks: Jeder hält ein langlebiges Upstream-Token (ein GitHub-PAT, einen Slack-/Brave-/Perplexity-Schlüssel) im Klartext in deiner Client-Konfiguration, wo jeder Server, den der Client lädt, es lesen kann. kow mcp install ersetzt dieses dauerhafte Secret durch einen Platzhalter und leitet den ausgehenden Datenverkehr des Servers durch den Proxy, sodass der echte Wert nie in der Konfiguration liegt:
kow mcp install github --host api.github.com --env-var GITHUB_PERSONAL_ACCESS_TOKEN \
--server-cmd "npx -y @modelcontextprotocol/server-github"
Es gibt den Tresor-Hinweis zum Einfügen und den genauen Befehl claude mcp add --env / codex mcp add --env aus (Proxy + CA-Trust pro Laufzeit + Platzhalter-Env): nur Vorschlag für den Tresor, der Secret-Wert wird nie angefasst. Die gebündelte avp-Skill kann Host/Header/Format aus der Dokumentation des Servers ableiten und den Host vorher mit dir bestätigen. Design + Bedrohungsmodell: ADR-0040.
bubblewrap für Dateisystem-SandboxingDer Proxy funkt nie nach Hause. Die einzigen ausgehenden Verbindungen, die er aufbaut, führen zu dem BWS-Endpunkt, den du konfigurierst, und zu den Upstream-APIs, die dein Agent aufruft. Keine Telemetrie. Das Audit-Log unter /var/log/agent-vault-proxy/audit.jsonl ist standardmäßig nur lokal; optionaler Off-Box-Versand leitet es (aus einem separaten Sidecar, nie vom Proxy) nur an einen Collector weiter, den du selbst betreibst und kontrollierst.
Apache-2.0: siehe LICENSE und NOTICE; die ausdrückliche Patenterteilung ist für ein Sicherheitstool bewusst so gewählt (ADR-0037). Jede Funktion wird hier mitgeliefert, ohne Open-Core, Enterprise-Stufe oder gehosteten Dienst. Fork es, lies es vollständig durch, führe es für immer aus. Versionen bis 0.9.0 bleiben unter ihren ursprünglichen MIT-Bedingungen und unter dem Namen agent-vault-proxy verfügbar. Vorangegangene Arbeiten werden in CREDITS.md gewürdigt.
Eine Abhängigkeit ist nicht Open Source, und sie ist optional. Das optionale Bitwarden-Backend zieht bitwarden-sdk nach, das unter Bitwardens eigener proprietärer SDK-Lizenz steht, nicht unter Apache-2.0. Keys on the Wire bündelt es nie; du installierst es selbst (pip install 'keys-on-the-wire[bitwarden]') nur, wenn du dieses Backend nutzt. Die Standardinstallation und die AWS-Secrets-Manager-, Google-Secret-Manager- und Env-Backends sind zu 100 % Open Source.
kow mcp installstatic für die Entwicklung) und wie du ein weiteres hinzufügstop run, superfly/tokenizer, OneCLI und anderen Agent-Credential-Tools (nimm, was passt: Es geht darum, mehr Agenten zu schützen, nicht um Lock-in)