An AI agent with a long-lived API key is a credential waiting to leak. The agent reads untrusted input, writes to logs, and keeps context across turns, and each of those is a path for the key to escape. The fix is not a better prompt. It is to stop giving the agent the secret at all.
Why a long-lived key is the wrong thing to hand an agent
- Prompt injection. An agent that can read web pages, issues, emails, or files can be told by that content to reveal its environment or call a tool with attacker-chosen arguments. If a provider key is in context, it can be exfiltrated.
- Logs and traces. Agent frameworks log prompts, tool calls, and errors. A key in the context tends to end up in a log, a trace, or a crash report that outlives the session.
- Model memory and history. Conversation history, vector stores, and caches persist context. A secret placed there is now stored in several systems you did not mean to put secrets in.
- Blast radius. A long-lived key is usually broadly scoped and valid for months. One leak is full provider access until someone notices and rotates it.
The alternative: authorize the operation, not the agent's wallet
Put a broker between the agent and the provider. The agent asks the broker to perform a specific operation. The broker authenticates the agent, checks a default-deny policy, and performs the operation itself using a credential the agent never receives. Where the provider supports it, that credential is minted for this one call and expires in minutes.
This changes what a leak is worth:
- There is no long-lived secret in the agent to steal in the first place.
- An injected instruction can only ask for operations the policy already allows, and every attempt is audited.
- A credential that does leak is scoped to one action and already expiring, so the window and the reach are both small.
What this looks like in practice
With PastKeys, provider tokens stay inside a broker you run, sealed so the hosted control plane cannot decrypt them. The agent holds only its own identity token and sends operations like "read these DNS records" or "open a read-only database session." The broker does the rest and writes an audit record for each call.
See getting started for the five-step setup, or the zero-access custody explainer for how the vendor is kept unable to read your secrets.