Agent Vault: Credential Brokering for AI Agents Without Exfiltration Risk

The Credential Exfiltration Problem

Standard secrets management returns credentials to the application that needs them. The application holds the key in memory or in an environment variable and uses it to make API calls. This model breaks when the application is an AI agent, because AI agents can be manipulated through prompt injection attacks into revealing the contents of their context, including secrets they hold.

Agent Vault's approach is to remove credentials from the agent entirely. Instead of giving the agent a real ANTHROPIC_API_KEY or GITHUB_PAT, the agent receives a dummy value. All of the agent's outbound HTTP requests are routed through Agent Vault, which recognises the dummy value in the request headers, replaces it with the real credential from its own encrypted store, and forwards the request to the target API.

The agent never sees the real credential. A successful prompt injection attack that instructs the agent to print its environment variables or echo its API keys produces only the dummy placeholders. The README describes this as eliminating credential exfiltration risk rather than reducing it.

How the MITM Proxy Works

Agent Vault operates as a man-in-the-middle proxy between the agent and the public internet. The architecture in the README shows the agent's outbound HTTPS requests routed through Agent Vault, which re-terminates TLS, inspects and modifies the request headers, and forwards the request to the target host with real credentials attached.

The proxy is transparent in the sense that agents use their existing tools (MCP, CLI, SDK, API) without modification. Agent Vault bootstraps the agent's environment to use HTTPS_PROXY pointing at the local proxy server, so any HTTP library in the agent's runtime routes through it automatically.

By default, requests that do not match any configured service are forwarded as plain proxy traffic. Strict deny mode changes this: setting unmatched_host_policy to deny causes the proxy to return a 403 response for any request to a host that has not been explicitly configured. This provides egress filtering without requiring firewall rules. Authenticated traffic is logged, allowing operators to inspect which API endpoints the agent is calling and diagnose unexpected behaviour.

Installing and Starting Agent Vault

Agent Vault ships as a single binary that acts as both a server and a CLI client. The README states it supports macOS on Intel and Apple Silicon and Linux on x86_64 and ARM64.

A Docker image is also available. The Dockerfile in the repository builds in three stages: a frontend build using Node.js, a Go build stage, and a minimal Alpine runtime. The image exposes port 14321 and starts with the server command by default:

EXPOSE 14321
CMD ["server", "--host", "0.0.0.0", "--port", "14321"]

Configuration is managed through environment variables. Key variables from the .env.example in the repository include:

# Bind port
PORT=14321

# PostgreSQL for production (SQLite used by default)
DATABASE_URL=postgres://user:password@host:5432/agentvault

# Master password to derive the key-encryption key
AGENT_VAULT_MASTER_PASSWORD=

# External base URL the agent side uses to reach the broker
AGENT_VAULT_ADDR=http://localhost:14321

The default storage backend is SQLite, suitable for single-machine deployments. PostgreSQL via DATABASE_URL is available for multi-instance setups. The README specifies that Agent Vault is intended to be deployed on a separate machine from the AI agents to provide the security guarantee that agents cannot access the vault's stored credentials directly.

Integrating an AI Agent Through Agent Vault

The README describes several integration patterns. For remote coding agents such as Claude Code, the setup configures Claude Code to proxy requests through Agent Vault and stores the ANTHROPIC_API_KEY and GITHUB_PAT in the vault. Claude Code interacts with the Anthropic API and GitHub as normal, with Agent Vault injecting the real credentials transparently.

For orchestrators that spin up ephemeral agent sandboxes, the pattern is to mint a temporary token, pass it into the sandbox as AGENT_VAULT_TOKEN, and have the sandboxed agent loop back through the orchestrator's own Agent Vault instance. The README notes this supports sandboxes that make callbacks to the backend that created them, covering use cases like webhook handlers or approval flows within a coding task.

The pluggable credential store feature lets an organisation back Agent Vault with an external secrets manager. The README specifically mentions Infisical as a backend option, which gives access to dynamic secrets that rotate automatically. Credentials stored in Infisical can then be brokered through Agent Vault without ever being copied to a static local store.

Where Agent Vault Has Limits

Agent Vault's security guarantee depends on the proxy being on a separate machine from the agent. If the agent and Agent Vault run on the same host, a compromised agent process can potentially access the vault's SQLite database or environment variables directly. The README explicitly states this separation is required for the security model to hold.

The egress filtering feature controls which hosts an agent can reach, but it is not a substitute for network-level firewall rules in a hardened environment. Agent Vault enforces its policy at the HTTP layer; a sophisticated agent with direct socket access could bypass the proxy entirely.

The open-source binary lacks the session management and access control features of the commercial Infisical Agent Vault product. The README describes the commercial product as offering time-bound sessions, access bundles grouping services together, and permissions governed by Infisical's platform-level controls. For production deployments where compliance, audit trails, or centralised policy management are required, the README recommends the commercial option.

Agent Vault vs. HashiCorp Vault

HashiCorp Vault is a comprehensive secrets management platform that stores, rotates, and audits access to secrets. It provides dynamic secret generation, fine-grained access policies, and audit logging. The key difference in approach is that HashiCorp Vault still returns credentials to the application that requests them. The application holds the lease and uses the credential directly.

Agent Vault does not return credentials to the agent at all. It intercepts the agent's outbound HTTP calls and injects credentials at the network layer. This is a fundamentally different trust model: HashiCorp Vault trusts the application with a short-lived credential, while Agent Vault never gives the agent a usable credential in the first place.

Agent Vault can also be backed by Infisical, which can use HashiCorp Vault-compatible dynamic secrets in its backend, so the two systems are not mutually exclusive. An organisation using HashiCorp Vault for secrets management could add Agent Vault in front of their AI agents to prevent those agents from ever receiving the credentials that HashiCorp Vault issues.

Editorial conclusion

Agent Vault addresses a concrete and growing risk: AI agents that can be manipulated through prompt injection into leaking the API keys they hold. The MITM proxy architecture works with any agent that can route outbound requests through an HTTP proxy, which includes Claude Code, OpenClaw, and custom harnesses. The licence is listed as NOASSERTION in the repository metadata, so legal review is needed before deploying in a commercial environment. For production and enterprise use, the README points to the commercial Infisical Agent Vault product, which adds time-bound sessions and platform-level access controls that the open-source binary does not provide.

Frequently asked questions

Official sources

1. Infisical/agent-vault on GitHub
2. Issues
3. Project website
4. README
5. Releases