Secrets management for AI agents: a practical guide

AI agents change what a secret is exposed to. A traditional service reads a key from an environment variable and uses it in code you wrote. An agent reads untrusted input, decides what to do, logs its reasoning, and keeps context across turns, so a secret in its reach can leak through a path you did not write. This guide covers how to manage secrets for agents built with LangChain, CrewAI, AutoGPT, MCP servers, and hand-rolled loops.

Why the old approach does not fit

Secret managers like Vault or cloud secret stores answer "where is the key stored and who can fetch it." That is still useful, but for an agent the harder question is "what happens once the running process can read the key." For an agent, that process is driven by a model that attackers can influence through content.

• Prompt injection. Content the agent reads can instruct it to use a tool for the attacker's ends, or to reveal its environment. A key in context is then reachable. See how prompt injection steals API keys.
• Logs, traces, and memory. Agent frameworks persist prompts, tool calls, and errors. A secret in context tends to end up in several stores you did not intend as secret stores.
• Broad, long-lived keys. Agents are often handed a broadly scoped key so they can "do their job," which maximizes the blast radius of any single leak.

Four levels, worst to best

1. Hardcoded or in the prompt. Never. It lands in history, logs, and model memory immediately.
2. Environment variable read by the agent. Common and still risky: anything the agent can be convinced to do, the key can do.
3. Fetched from a secret manager at runtime. Better storage, same exposure: once fetched, the plaintext is in the agent's process and reachable the same ways.
4. Brokered: the agent never holds the secret. The agent requests an operation; a broker it cannot read from performs it with a short-lived, scoped credential and returns only the result.

The brokered pattern

Put a broker between the agent and each provider. The agent authenticates with its own identity and asks for a specific operation ("read these DNS records", "open a read-only database session", "create this issue"). The broker checks a default-deny policy, performs the operation with a credential it holds, and returns the result. Where the provider supports it, that credential is minted for the one call and expires in minutes.

This holds across frameworks because it does not depend on the agent's internals. LangChain and CrewAI tools, an MCP server, or a plain function call all become "ask the broker to do X" instead of "use this key to do X."

A checklist

• No provider key in the prompt, the agent's env, or its memory.
• The agent authenticates as itself (a short-lived workload-identity token where possible, not a long-lived bearer key).
• Every operation checked against a default-deny policy; nothing allowed by default.
• Credentials scoped to one operation and short-lived.
• One audit record per request, with no secrets in it.
• An emergency path to freeze access instantly if an agent misbehaves.

Where PastKeys fits

PastKeys is a credential broker built for this. Provider tokens are sealed to a broker you run, so the hosted service cannot decrypt them (zero-access custody). Agents hold only their identity, policies are default-deny, credentials are scoped and short-lived, and every call is audited. If you use MCP, there is a drop-in MCP server so your tools carry no decryptable secret.

Start with the quickstart, or read the whitepaper for the full design.