Agent Vault

What Agent Vault does

Instead of handing an agent keys such as an Anthropic API key or a GitHub token, you store them in Agent Vault and route the agent's HTTP requests through it. The proxy intercepts each request, swaps placeholder values like __anthropic_api_key__ in headers (or replaces auth headers entirely) with the real secret, and forwards the call to the target API. The aim is to limit credential exfiltration when an agent is tricked by prompt injection.

It ships as a single Go binary that works as both server and CLI, and it uses a MITM proxy design set up through HTTPS_PROXY. Egress filtering controls which agents reach which services, and request logging lets you inspect traffic. A vault can use the local encrypted store or an external one such as Infisical. Unmatched hosts pass through by default, and unmatched_host_policy=deny rejects them with a 403. The README advises running it on a separate machine from the agents.

Key features

• Credential brokering by substituting placeholder values in outbound request headers
• Pluggable credential stores, including local encrypted storage and Infisical
• Egress filtering per agent and per service
• Request logging for authenticated traffic
• Strict deny mode for hosts that match no configured service

When to use it

• Running Hermes or OpenClaw as an all-purpose agent without giving it real API keys
• Remote coding agent sessions that need an Anthropic key and a GitHub token
• Ephemeral sandboxes where a backend hands the agent a temporary token

Who it is for: Operators who run agents on servers or in sandboxes and want API keys kept out of the agent's environment.

How it fits with Hermes Agent

The README names Hermes as an example all-purpose agent that can be set up to send its outbound requests through Agent Vault. It is a general tool for many agents.

Note: The README recommends the commercial Infisical Agent Vault for production and enterprise use and presents this open-source version as the simpler, self-contained option.

FAQ