Secrets for AI agents: .env files vs. secret managers vs. a zero-knowledge vault

The moment an agent does real work — deploys, API calls, database queries — it needs credentials. There are three ways to hand them over, and they differ in one specific place: whether plaintext ever enters the model's context. Anything that enters the context can be logged by the provider, echoed into a transcript, or exfiltrated by a prompt injection. Here's the honest comparison.

Option 1 — .env files and pasting keys into chat

The default today. It works, and for a throwaway key on a toy project it's fine. The problems compound with real credentials:

1. Every process the agent runs can read the whole file — one key leak means rotating all of them.
2. The agent reads the value to use it, so the plaintext lands in the context window and often in provider-side logs and local transcripts, where it outlives the session.
3. A prompt-injected agent can be told to print or send what it holds — and it holds everything.
4. Nothing records which secret was used, when, or why.

Option 2 — a traditional secret manager

Tools built for humans and services solve real problems — encrypted storage, rotation, centralized policy — and if your team runs one, keep it. The gap is at the last step: when the agent fetches a secret through a CLI or API call, the value comes back as tool output, which is context. Storage is encrypted; the agent still ends up holding plaintext at the moment of use, with the same exposure as Option 1 from that point on.

Option 3 — a zero-knowledge vault with runtime injection

The approach Wundervault's MCP server takes: the agent never receives the value at all. It calls tools like vault_exec ("run this deploy with the API key injected") and a local daemon decrypts the secret, injects it into the subprocess environment, and scrubs the output before the agent sees it. Secrets are encrypted client-side, so our server can't read them either — a claim you can verify yourself at your own network boundary.

1. Plaintext never enters the context, the transcript, or provider logs.
2. A prompt-injected agent can't leak what it never held; scope and revocation bound what it can even use.
3. Every use is written to a tamper-evident audit log with a stated purpose.

When we're the wrong choice

Honesty over marketing: if your agents run fully air-gapped, a hosted vault doesn't fit. If your workflow needs the agent to read a secret's value and reason about it (rare, but real), zero-knowledge injection is the wrong shape by design. And a mature self-hosted secret manager your ops team already trusts is a fine backbone — the gap we close is specifically the agent-facing last step.