How to store an AI agent's credentials in a secrets manager

Store one secret per agent, per capability, per target system, and let only a broker read it. The broker fetches the credential after the action passes its checks or a person approves it, makes the call, and discards it. The agent never sees the secret. Disabling a single secret then switches off a single capability, and every read is logged.

Why use a secrets manager, and who owns it?

Credentials in an agent's configuration, environment or prompt are credentials the agent can repeat. Agents read untrusted text all day, and a crafted message can ask them to print what they know. A secrets manager keeps credentials out of reach, controls who may read them, and logs every read. Why the agent itself should never hold keys is argued in how do you keep credentials and keys away from an AI agent?

The security team owns the secrets manager and its policies. The platform team runs the broker that fetches secrets for agent actions. Each agent's sponsor approves which secrets exist for it, because each secret represents a capability.

How should secrets be organised?

Use a path per agent, per capability, per target system, for example the collections agent's read access to the loan system separate from its write access to the same system. Each credential is issued to the agent's own identity in the target system, never a shared or personal account; the reasons are in should AI agents have their own identities and credentials?

Splitting by capability matters because it lets you scope reads. The broker serving the read capability cannot fetch the write secret, and switching off one secret path stops one capability without stopping the agent.

What are the steps?

1. Person, sponsor: lists the capabilities that need credentials, from the capability matrix.
2. Person, identity team: issues a credential per capability to the agent's identity in each target system, with entitlements matching that capability only.
3. Person, security: stores each credential at its own path, with a policy that only the broker's workload identity may read it.
4. Person, security: denies the agent itself any right to read, list or change secrets.
5. Person, platform engineer: configures the broker to fetch a secret only for an action that has passed its checks, or a held action a named person has approved.
6. Agent, depth 1: is tested with attempts to reveal, request or use credentials directly, which must fail.
7. Person, security: sets rotation and expiry for every secret.
8. Person, security: tests revocation by disabling one path and confirming only that capability stops.

What is scoped, held and revoked per capability?

Held actions deserve attention. The secret for a payment release should not be fetched when the agent drafts the payment; it should be fetched when the approver approves, and only for that action.

What is recorded in the audit trail?

The secrets manager logs every read with time, path and reader. The broker attaches the verdict identifier from the agent's record to each fetch, so every use of a credential links to the action, the bounds that allowed it and the approver if there was one. People who read a secret directly, for maintenance or emergency, do so under break-glass rules with two people and a reason, and those reads are reviewed.

Which controls make it safe?

Nothing in context. No secret in prompts, logs, error messages or tool outputs the model sees. Scan logs for credential patterns and rotate any that appear.

Broker-only read. The agent's identity cannot read secrets even by mistake.

Fetch after the verdict. The secret is fetched after the checks, never before, so a refused action never touches a credential.

Short-lived where possible. Prefer tokens issued per session over long-lived keys, so a stolen value soon becomes useless.

Rotation built in. See how to rotate the credentials an AI agent uses.

What should you measure?

• Secrets read outside a verdict, which should be none apart from logged break-glass access.
• Credentials found in logs or outputs. The target is none.
• Secrets without a linked capability.
• Long-lived secrets that could be short-lived.
• Time to cut a capability by disabling its secret.

Where does it usually go wrong?

One secret for everything. A single administrator key covers every capability, so the narrowest action carries the widest access, and revoking it stops the whole agent.

The agent fetches its own secrets. The secrets manager is used, but the agent holds the right to read from it, and so can be talked into reading anything it may access.

Errors leak secrets. A failed call returns an error message that includes the key, and the agent includes it in a reply.

Development shortcuts reach production. Test credentials in environment variables are copied into the live set-up.

Where Pryme fits

In Pryme, credentials are presented by the platform at the moment of action, after the action has met all five bounds, so the agent never holds them. Held actions use credentials only after a named person approves. Every verdict is filed and linked to the action. See agent governance is a bound, not a model.