How Agent Vault Works: Credential Brokering for AI Agents

These are AI agents that run real workloads. One of them, named Iggy, lives in Slack, answers questions about our docs, opens GitHub issues, and posts updates to a channel. We treat it like an intern, and each department is starting to build its own. Others are personal Hermes agents that grind through a GitHub backlog, organize Notion, send email, and read YouTube statistics.

Every one of these agents makes real authenticated calls to services like Notion, GitHub, and Anthropic. The catch is that none of them holds a single API key. The keys live on a separate machine and get added to each request on the way out. The tool doing that is Agent Vault. The agents hold nothing, and every key and all of the control stay on the broker.

Traditional software is deterministic and predictable. Fifty dollars goes in, a billing service runs, and a receipt comes out the other side, the same way every time. AI agents are not built that way. They act on whatever text they read, whether that is a web page, a file, or a GitHub issue, and that is exactly what makes them exploitable. A few lines of malicious text in the wrong place can talk an agent into handing your credentials to an attacker.

This is not hypothetical. Snyk ran a security audit of the agent skills ecosystem, scanning close to 4,000 skills from the marketplaces these agents pull from. Well over a third of them, more than 1,400 skills, carried at least one security flaw, and better than one in eight had a critical issue, including malware or code built specifically to exfiltrate credentials. The research on those skills found prompt injection and leaked secrets among the most common problems. The plugins people install to make their agents more capable are, in a large number of cases, quietly trying to steal their keys.

Giving a non-deterministic agent the keys does not work, and you cannot fix it with a better secrets manager. A secrets manager protects credentials at rest and in transit to the application, which is the right job for deterministic software. Once a non-deterministic agent is the thing holding the credential, that protection no longer suffices.

The fix cannot be operational. It has to be architectural. Do not let the agent hold the secret in the first place. If you want the full threat model and the deeper argument, our credential brokering explainer covers the why in detail.

Agent Vault is an open-source, cloud-agnostic credential broker. It is a proxy that sits between your agents and the APIs they call. It holds the credentials on its own machine and injects them into each request on the way out. The agent holds either a placeholder or nothing at all, and the broker swaps in the real token on the wire.

If you have ever used a man-in-the-middle proxy to inspect traffic, this is the same position, except instead of debugging requests, the broker is injecting credentials. Whether the call comes from an SDK, a CLI, or an MCP server, it all bottoms out in HTTP, so the broker can inject the credential no matter the interface. The agent gets the access, never the secret, and you keep every key and every rule in one place. If you are putting agents into production, especially as a team, this is a pattern worth standardizing on.

Agent Vault is organized around three pieces.

A vault is a boundary, generally one per project or one per team. It holds the credentials and the services you allow, and your agents reach those services through the vault.

Credentials are the real secrets, the actual key-value pairs holding your API keys and tokens. They are encrypted at rest, and the agent never reads them. There is no view in the product and no point on the wire that hands the real values back to the agent.

A service is an allowed destination plus how to authenticate to it. A GitHub service might say "allow calls to `api.github.com` and inject the GitHub token credential as a bearer token." That injection can be a bearer token, an API key header, basic auth, or a placeholder swapped into the path or the body. If there is no service for a given host, the broker will not broker for it, which makes the services list an allow list. Across all three components, the agent holds no secrets.

To make this concrete, here is the problem first, with Claude Code and no broker in the path. Tell Claude to take one credential, a placeholder value of `demo token`, and make a `curl` request to `postman-echo.com/get`, a free endpoint that mirrors back whatever it receives. The request goes out and Postman Echo reports back `Bearer demo token`, the placeholder verbatim. That dead string is everything Claude has, so that is what goes out and that is what comes back. It cannot unlock anything.

Now run the same task wrapped in the Agent Vault CLI, pointed at the demo vault, with the same prompt and the same placeholder. This time the request routes through the broker. The task is identical, but Postman Echo reports back the real credential stored in Agent Vault. The outbound proxy swapped the placeholder for the real value on the wire. The broker terminated TLS, found the placeholder, injected the real value, and re-encrypted the request on its way out, all on the broker's side of the wire. The only thing that ever lived in Claude was the placeholder. The broker is the only thing that changed.

For this demo, Claude Code and Agent Vault run on the same machine, so you can watch the brokering flow end to end. Installing Agent Vault is one command, grabbed from the docs. The CLI installs its own certificate authority and trust, which is how it sees inside HTTPS, and the initial install asks for your password.

Once it reports success, run `agent-vault server -d`. The first run asks for a master password used to encrypt the database that holds your secrets (you can leave it passwordless for a demo). The first admin email and password you create becomes the super admin. With the server started, open `localhost:14321`, log in, and create a vault, for example a demo credential store.

From there, add a credential, give it a value, and add it. In a real environment this would be a real API key, such as a GitHub token. Then add a service, for example one named Postman Echo that says "any call to `postman-echo.com`, inject this credential into the header as a bearer token." This local pattern is useful for giving a desktop agent like Claude Code access without putting real service keys in its configuration. It does not provide isolation, since the agent and the broker sit on the same box, but it solves the immediate problem of handing an agent capability without handing it the keys.

Everything routing through one broker is your control plane, and this is where a production setup differs from the local demo. Locally, Agent Vault and Claude Code share a machine. If you are running multiple long-lived agents for a team, a multi-box setup is better: Agent Vault on one box and the agents somewhere else, such as another server, a worker, or a web service. The broker becomes the boundary every agent has to cross to reach an external service.

This separation also addresses isolation. With the broker off the agents' runtime, the secret material stays on the Agent Vault side of the boundary even though the agents can still make requests. For local agents the cleanest sandbox story is still being worked out, but the brokering pattern already solves the immediate local problem. You can see this run end to end with a specific agent in our Hermes and OpenClaw walkthroughs.

Agents cannot grant themselves access to anything. An agent cannot add a service or a credential. For agents running hands-off, like Hermes or OpenClaw, an agent can request access by opening a proposal, which works like a pull request for access. A human approves it and supplies the actual token, and the change is atomic and logged.

Zoom out to a real company. You might have RevOps, marketing, and solutions engineering agents all doing useful work across different systems. As those agents sprawl, you do not want access decisions living in four places on four machines. You want one place to say what each agent can call, which credential it can use, and when that access should disappear. These are exactly the questions machine identities exist to answer. If you want to cut off an agent entirely, revoke its token and it is gone in that instant.

Every brokered call, every injection, and every proposal lands in the vault's audit logs. Each row is one brokered request: the service it reached, which credential was injected, the agent that made the call, and a timestamp. Read straight down the log and you can see exactly what each agent did and which key it used, even though none of them ever held the key.

That is how Agent Vault works. The agent never holds the secret, egress can be enforced, and access is proposed, approved, and audited. None of this is tied to the agents shown here or to where you run them. Anything that speaks HTTP and respects a proxy works the same way, whether that is Claude Code, Cursor, Codex, Hermes, a script on your laptop, or a step in a CI pipeline.

Agent Vault is open source and quick to get started. The point is simple: your agents should not see your secrets, and with a broker in the loop, they cannot.