GitHub - inflightsec/agent-vault-proxy: Just-in-time API keys for AI agents - and any other process you route through it: the caller only ever sees a placeholder.

6 min read Original article ↗

Just-in-time API keys for AI agents and any other process you route through it: the caller only ever sees a placeholder.

AVP protects you from credential stealers (Shai-Hulud and similar) and prompt-injected agents leaking your secrets. It's a local proxy that injects real secrets into requests in-flight, so a compromised or prompt-injected agent has nothing to steal.

PyPI License: Apache-2.0 CI

How agent-vault-proxy substitutes secrets on the wire

Under the hood: a loopback HTTPS proxy that fetches credentials from Bitwarden Secrets Manager — cloud or self-hosted — just-in-time and injects them into outbound requests, so the calling process never holds the real credential bytes in its address space.

Fully open source, deliberately simple

Every feature is in this repo under Apache-2.0. There is no paywalled tier, no enterprise edition, no cloud you have to trust, no telemetry — you can read the whole thing end to end (a few thousand lines) and run it forever.

The whole workflow is one move: ask the bundled skill to route a service, it tells you the single line to paste into Bitwarden (or your vault), you paste it, and the agent is brokered. Done. Because every brokered credential is one binding, the config is the complete, auditable list of exactly which secrets each agent can reach — nothing implicit, nothing hidden.

And the point isn't lock-in. The goal is simply that fewer real keys sit inside AI agents, everywhere. If AVP fits, use it; if one of the alternatives fits your setup better, use that. Any tool that keeps the real secret out of the agent's memory is a win.

Try it. 10 seconds.

1. Install — Linux pipx, macOS brew:

pipx install agent-vault-proxy
# macOS: brew install inflightsec/avp/agent-vault-proxy
sudo avp setup --bws        # paste your Bitwarden token — generates the CA, starts the daemon

2. Install the skill so your agent writes the binding for you:

/plugin marketplace add inflightsec/agent-vault-proxy
/plugin install avp@agent-vault-proxy

3. Ask the skill to broker a service — say "route the Stripe API through AVP." It mints the placeholder and prints the exact note to paste into BitWarden; it never sees your key.

4. Put the secret in your vault — add the real key to Bitwarden Secrets Manager (or Google Secret Manager) with that note, then route your agent through the proxy:

avp env && avp run claude

Done — the agent only ever sends the placeholder; AVP swaps in the real key on the wire.

Rather than avp run, you can export the proxy + CA vars in your agent's ~/.zshrc (or any shell rc) — see Usage for the canonical block. It's persistent, but it routes your whole shell through AVP, not just the agent AVP launches.

See it in action

agent-vault-proxy demo: prompt injection vs. credential isolation

Add a secret with your AI agent — no config editing

Onboarding a new brokered credential shouldn't mean hand-writing binding YAML. The bundled avp skill lets an AI assistant (Claude Code, or any agent that loads skills) walk you through it: you say "route the Acme API through AVP," it asks the auth shape and host, then tells you exactly what to add — the secret name plus the annotation to paste into the Bitwarden Secrets Manager Notes field (or the Google Secret Manager avp-binding annotation, or a future backend's per-secret metadata). No AVP config edit, no redeploy — and the assistant never sees or stores the secret; it proposes, you apply.

The note itself is two lines pasted into the secret's Notes field:

# avp-binding
api.acme.com

The marker line is what makes it a binding: a note whose first line isn't # avp-binding stays what it is — a human description, never parsed (ADR-0025).

Install the skill

Claude Code (recommended) — install it as a plugin, so it's available in every project and updates with /plugin marketplace update:

/plugin marketplace add inflightsec/agent-vault-proxy
/plugin install avp@agent-vault-proxy

Invoke it as /avp:avp, or just say "route the Acme API through AVP" and it triggers on its own.

Manual (any agent that loads Anthropic-format skills) — copy or symlink skills/avp/ into your agent's skills directory; Claude Code reads ~/.claude/skills/. A symlink keeps it current on git pull:

ln -s "$PWD/skills/avp" ~/.claude/skills/avp

Broker an MCP server

MCP servers are a fast-growing credential-leak surface: each holds a long-lived upstream token (a GitHub PAT, a Slack/Brave/Perplexity key) in cleartext in your client config, where every server the client loads can read it. avp mcp install replaces that standing secret with a placeholder and routes the server's egress through the proxy, so the real value never lives in the config:

avp mcp install github --host api.github.com --env-var GITHUB_PERSONAL_ACCESS_TOKEN \
  --server-cmd "npx -y @modelcontextprotocol/server-github"

It prints the vault note to paste and the exact claude mcp add --env / codex mcp add --env command (proxy + per-runtime CA-trust + placeholder env) — propose-only for the vault, the secret value is never touched. The bundled avp skill can derive the host/header/format from the server's docs and confirm the host with you first. Design + threat model: ADR-0040.

Docs

  • Is AVP for you? — what it does, what it deliberately does not do, why, and when to reach for it (start here if you're evaluating)
  • Quickstart — 10-minute first run ending in a visible substitution
  • Concepts — placeholder, binding, the CA, fail-closed — in plain terms
  • Prerequisites — Bitwarden Secrets Manager setup (do this first)
  • Linux install · Docker · macOS
  • Usage — pointing your agent at the proxy
  • Linux isolation — composing AVP with bubblewrap for filesystem sandboxing
  • bindings.example.yaml — full config schema
  • avp skill — let an AI assistant author your notes/annotation bindings (propose-only, no config edit, no redeploy)
  • Broker an MCP server — run Claude Code / Codex MCP servers with no plaintext credential (avp mcp install)
  • Architecture — threat model, G1–G9 invariants, hardening, residual risks
  • Adapter architecture — vault backends (Bitwarden, Google Secret Manager, and AWS Secrets Manager ship today, static for dev) and how to add another
  • Google Secret Manager — keep secrets in GSM: setup, keyless auth, and end-to-end testing
  • Comparison — vs. Vault Agent, Doppler, op run, superfly/tokenizer, OneCLI, and other agent credential tools (use whichever fits — the point is more agents protected, not lock-in)
  • CHANGELOG · SECURITY · CONTRIBUTING · CREDITS

The proxy never phones home. The only outbound connections it makes are to the BWS endpoint you configure and the upstream APIs your agent is calling. No telemetry. The audit log under /var/log/agent-vault-proxy/audit.jsonl is local-only by default; optional off-box shipping forwards it — from a separate sidecar, never the proxy — only to a collector you run and control.

License

Apache-2.0 — see LICENSE and NOTICE; the explicit patent grant is deliberate for a security tool (ADR-0037). Every feature ships here: no open-core, no enterprise tier, no hosted service — fork it, read it end to end, run it forever. Releases up to 0.9.0 remain available under their original MIT terms. Prior art acknowledged in CREDITS.md.