agent-vault: A Practical Zero-Trust Secret Manager for AI Agents

By Eric Wimsatt 4 min read

Most agent security advice sounds good in a slide deck and collapses the moment you hand a real API key to a real autonomous system.

The problem is simple. Agents need credentials to do useful work. But when you give an agent a raw key, you inherit three ugly failure modes immediately:

  1. The key leaks into logs, prompts, stack traces, or debug output.
  2. You cannot revoke one agent cleanly if several share the same credential.
  3. You lose attribution around who used what and when.

That is exactly the gap agent-vault is designed to close.

What agent-vault is

agent-vault is a zero-trust credential manager for AI agents. It encrypts secrets locally with age encryption, stores only ciphertext in git, and uses per-agent keys for scoped access.

No hosted control plane. No external SaaS dependency. No plaintext secret store living in a random dashboard.

The repo becomes an encrypted blob store plus access manifest. The trust boundary stays with the owner key.

The core model (and why it matters)

The architecture is straightforward, but the implications are strong:

  • Owner key: can decrypt everything. Never committed.
  • Agent key per agent: only decrypts groups it is granted.
  • Escrow: each agent key has an owner-encrypted recovery copy in repo.
  • Git as sync: push, pull, branch, merge work the same way teams already operate.

When you grant or revoke access, agent-vault re-encrypts affected secrets with an updated recipient list. This is the part many teams skip when they claim revocation support.

Revocation is not a boolean flag in a database. Revocation means old ciphertext is no longer decryptable by the removed identity.

Why this is a better fit for agent systems

Most secrets tooling was designed for humans and servers, not autonomous agents with tool chains, memory, and verbose logs.

agent-vault fits agent workflows because it addresses the real operating constraints:

1) Least privilege by default

You grant groups, not god-mode. A content agent can read publishing keys without touching billing credentials. A crawler can access one API namespace without touching production infra.

2) Decryption never needs to hit disk

By design, decrypted material is kept in memory or emitted to stdout. You reduce accidental persistence and postmortem blast radius.

3) Git-native operational behavior

For teams already living in git, this is huge. Secrets versioning, review flow, rollback patterns, and branch workflows can align with existing engineering muscle memory.

4) Strong compromise response

If one agent is compromised, you can revoke that identity and re-encrypt only the affected groups. You do not have to rotate your entire universe immediately.

Useful details that are easy to miss

A few parts of the repo stand out as production-minded:

  • Pre-commit protection that blocks private keys and common key formats.
  • Escrow-backed recovery so lost agent keys are recoverable by owner.
  • SDK coverage for Python and Node so agents can consume secrets directly.
  • MCP server support so tool-using agents can retrieve secrets through a standard interface.

That MCP piece is important. It means you can expose get and list secret tools through a protocol agents already use, without sprinkling secret handling across app-specific wrappers.

Where teams usually get this wrong

The common anti-pattern is “we gave the agent one env var and called it done.”

That works until:

  • logs get shipped to third-party observability tools,
  • multiple agents end up sharing keys,
  • one agent needs to be retired quickly,
  • or audit asks, “which identity pulled this credential?”

By then, the incident response path is rotate everything and pray nothing else leaked.

agent-vault does not magically solve governance. But it gives you a sane primitive set so governance is possible without heroic manual process.

Practical rollout pattern

If you are introducing this into an existing stack, start narrow:

  1. Initialize vault in one project repo.
  2. Add one non-critical agent identity.
  3. Move one secret group (for example, staging APIs).
  4. Validate grant/revoke and recovery workflow.
  5. Expand group by group.

The right goal is not immediate total migration. The right goal is making the “secure path” easier than the shortcut.

Why this matters now

Agent capabilities are expanding faster than most organizations’ security posture. Teams are automating execution before they have reliable identity boundaries for machine actors.

That is backwards.

The next year of agent security will be decided less by flashy model defenses and more by boring operational controls done consistently:

  • identity separation,
  • scoped credential access,
  • recoverability,
  • and revocation that is actually real.

agent-vault is compelling because it is opinionated about those fundamentals and still practical enough to use daily.

If your agents can trigger production actions, they need something stronger than shared .env files and trust-by-vibes.

This is one of the better concrete patterns I have seen for getting there.