Rotate them where the agent cannot see them. The agent's credentials should sit in a secrets manager, be fetched at the moment of each call, and be replaced on a schedule and after any exposure or departure. Issue the new one, let both work briefly, switch, then revoke the old. The agent never rotates its own keys.
What is credential rotation for an agent, and who owns it?
An agent reaches your systems with API keys, client secrets, certificates or database passwords issued to its own identity. Rotation replaces them so that a credential copied, leaked or remembered by someone stops working. For agents it matters more than for most integrations, because agents read untrusted content all day, and any credential that ever reached the agent's context could be repeated back to the wrong person.
The security team owns rotation policy. The platform team runs the secrets manager and the automation. The agent's sponsor is told of every rotation and confirms the agent still works. The agent is a consumer of credentials, never their keeper; how do you keep credentials and keys away from an AI agent? explains why.
What are the steps?
- Person, security: sets the schedule per credential type: shorter for high-privilege and long-lived secrets, longer for low-risk read keys, and as short-lived as possible where systems support tokens issued per session.
- Person, security: lists the events that force rotation: suspected exposure, a person with access leaving, an agent suspended or retired, an incident at the vendor or model provider, or a credential appearing in any log or message.
- Operations agent, depth 1: monitors expiry dates across every agent credential and lists those due.
- Operations agent, depth 2: drafts rotation tickets for credentials the secrets manager cannot rotate automatically.
- Secrets manager automation, configured by a person: issues the new credential to the agent's identity with exactly the same entitlements.
- Platform: runs both credentials in overlap for a short window, then switches all calls to the new one.
- Operations agent, depth 1: runs health checks on each capability after the switch and compares entitlements before and after.
- Person, platform engineer: revokes the old credential and confirms the revocation took effect.
Which permissions apply per action, and at what depth?
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Schedule | Nothing | none | Setting intervals and triggers |
| Monitor expiry | Lists credentials due | 1 | Nothing |
| Draft tickets | Prepares manual rotation tickets | 2 | Approving them |
| Issue new credential | Nothing | none | Automation configured by security |
| Overlap and switch | Nothing | none | Setting the window |
| Health check | Tests each capability, compares access | 1 | Investigating differences |
| Revoke old | Nothing | none | Confirming revocation |
| Rotate its own keys | Never | none | Always security |
The working agent, the one whose credentials are rotated, has no part in the process at all. Its broker fetches whichever credential is current. An operations agent can watch dates and run checks, but issuing and revoking are not tasks for any agent, because an agent able to issue credentials could grant itself access.
What is recorded?
The secrets manager logs each issue, each read by the agent's broker, and each revocation, with time and identity. The health check records each capability tested and the result. The entitlement comparison is stored with the rotation. Event-driven rotations carry the event that caused them, such as an incident reference. Together they show that the credential changed, access did not, and the old one stopped working.
Which controls make it safe?
Same entitlements, every time. Rotation is a chance for access to drift: a new key is issued with a broader role because it was quicker. Compare before and after, and treat any difference as a change needing approval.
Overlap without delay. Without a short overlap, rotation breaks work in flight; with a long one, the old credential lingers. Set the window per system and keep it short.
Revocation verified. Test that the old credential fails. Some systems keep sessions alive after a key is revoked.
Credentials never in context. If a credential appears in a prompt, a document the agent read, a log or a message, rotate it at once and find out how it got there.
Separate credentials per agent. Shared credentials mean rotating one agent's key breaks others, so teams stop rotating. Each agent should have its own; see should AI agents have their own identities and credentials?
What should you measure?
- Credentials past their rotation date. The target is none.
- Long-lived credentials that could be replaced with short-lived tokens.
- Rotations that changed entitlements.
- Rotations that broke a capability, and for how long.
- Time from a triggering event to rotation.
Where does it usually go wrong?
Credentials are in configuration files. They were put in the agent's code or settings for convenience, so rotation means a release. Move them into the secrets manager first; how to store an AI agent's credentials in a secrets manager covers how.
Rotation is skipped because it hurts. Each rotation causes an outage, so it is postponed. Fix the overlap and automation rather than the schedule.
Retired agents keep working keys. The agent is switched off, but its credentials still exist and could be used by anyone who copied them.
Event triggers are forgotten. A developer who had access leaves, and nobody rotates. Link leaver processes to the credential list.
Where Pryme fits
In Pryme, agents act under their own identities and never see raw credentials; the platform presents them at the moment of action, after the action has met all five bounds. That keeps rotation a platform and security task rather than an agent one. See agent governance is a bound, not a model.
Questions people ask
How often should agent credentials be rotated?
Follow your policy for service credentials, and shorten it for high-privilege ones. Where a system supports short-lived tokens issued per session, use them; they make most scheduled rotation unnecessary.
Does rotation require re-certifying the agent?
No. Rotation changes the key, not what the agent may do. If the entitlement comparison shows access changed, that change needs approval, and possibly re-testing, in its own right.
What if a credential leaks through the agent's output?
Rotate it immediately, revoke the old one, then treat the leak as an incident: find how the credential reached the agent, because it should never have been in its context.