Rotating Secrets Your Agents Depend On, Automatically

• Model provider API keys, including any separate keys for different environments.
• Per-tool service credentials, one for each MCP server calling an external system.
• Database credentials any tool queries directly.
• Webhook or callback secrets used to verify that a request into your system actually came from where it claims to.

Without this list in one place, rotation tends to happen for whichever credential someone remembers, not for all of them.

Give each credential in the inventory an owner, a creation date, an expected rotation interval and the systems that read it. The owner answers questions when a rotation fails, and the recorded dates make it possible to spot a credential that is older than its interval suggests. Keep the inventory next to the secrets manager configuration instead of in a separate document, so adding a new MCP server prompts an update to both at once.

A manual rotation reminder gets deprioritized the first time something more urgent comes up, and then again the next time, until it quietly stops happening. Use a secrets manager that supports automatic rotation on a schedule, with your application pulling the current credential at call time rather than having it baked into a config file that needs a deploy to update.

A credential rotation that happens while an agent is mid-task, holding a reference to a now-invalid token, should fail gracefully and retry with the fresh credential, not surface a confusing error to the user or, worse, silently drop the tool call. Test this specific failure mode deliberately before relying on automatic rotation in production.

Standard rotation on a calendar schedule is the baseline; a credential believed to be exposed, through a leaked log, a former employee's access, or a vendor incident, needs a much faster window. Known exploited vulnerabilities involving credentials that were assigned a CVE in 2021 or later carry a 14-day remediation expectation under federal directives, versus 180 days for older ones¹, which is a useful outside benchmark for how urgently a suspected exposure should be treated, even outside a federal context.

Write down who has the authority to trigger an emergency rotation and how fast it needs to happen, before an actual exposure forces the question. Deciding this under pressure, in the middle of an incident, tends to produce a slower and less confident response than having it settled ahead of time.

Say a team moves their per-tool service credentials into a secrets manager with automatic ninety-day rotation, mostly to satisfy a customer's security questionnaire rather than out of any specific concern. A few months later, a routine review of the secrets manager's audit log turns up a credential for a lesser-used internal tool that had, in fact, never successfully rotated, because the tool's code was reading the credential from an old environment variable instead of pulling the current value from the secrets manager at call time.

That credential had effectively been static for months, invisible to the rotation schedule that everyone assumed was working. Finding it wasn't the result of a security incident, it was the routine act of checking that automation was actually doing what it claimed to be doing, which is worth building into the rotation process itself rather than assuming a green dashboard means every credential is covered. The fix was small, updating the tool to read from the secrets manager at call time, but finding it required someone to actually verify the automation rather than trust it by default. Add a periodic check that confirms a credential's actual age against its expected rotation interval, separate from the rotation job itself, so a silent failure like this one doesn't depend on someone happening to look.