Key rotation is universally recommended and unevenly practiced. Teams set a policy, rotate once during setup, and then discover eighteen months later that the mechanism no longer works because the system changed around it. The first real attempt happens during an incident, under pressure, which is the worst time to find out that a service caches the old key for six hours.

Agent deployments make this harder than conventional service architectures for reasons worth naming, and they also offer a way out that services traditionally did not.

What Actually Needs Rotating

Enumerate the credential types, because they rotate differently:

  • Signing keys — used to sign tokens, audit entries, webhook payloads, or DID-authenticated messages. Verifiers hold the public half, which is what makes rotation a coordination problem.
  • Provider API keys — the LLM provider keys, third-party SaaS keys. Rotating these is a swap at the holder plus revocation at the issuer, and the issuer's console is often the only interface.
  • Client credentials — the client secret an agent uses to obtain tokens.
  • Encryption keys — for data at rest and for stored secrets. Rotation here means re-encryption or an envelope scheme, which is a different operation entirely.
  • Access and refresh tokens — these should already be short-lived; if they need rotating, they are being used as long-lived credentials and that is the actual finding.

Signing keys are where the interesting failure modes are, because rotation requires every verifier to learn the new key before any signer starts using it.

The Overlap Window

The correct sequence for a signing key, and it is not a swap:

1. Generate and publish the new key. The public half goes into your JWKS endpoint, DID document, or wherever verifiers fetch keys — with a distinct key identifier. Nothing signs with it yet.

2. Wait for verifier propagation. Verifiers cache. Wait at least the maximum cache TTL, plus margin. This is the step that gets skipped, and skipping it produces verification failures the moment signing switches over.

3. Switch signers to the new key. New signatures carry the new key id. Verifiers select the key by id, so both old and new signatures verify.

4. Wait for old signatures to age out. Long enough that no in-flight token or message signed with the old key is still within its validity window.

5. Retire the old key. Remove it from publication. Verification of old signatures now fails, which is the intent.

Two invariants: a verifier must select the key by identifier rather than trying keys until one works, and both keys must be simultaneously valid throughout the middle of the window. Implementations that try every published key in turn accept a compromised key for as long as it remains published, which defeats step 5.

For emergency revocation the sequence collapses — you skip the waiting and accept the breakage — which is why it needs to be a separate, separately-tested path rather than "rotation, but faster."

Where Agent Fleets Break It

Long-running tasks. A task that runs for hours holds credentials obtained at the start. A rotation window shorter than your longest task will kill work in progress. Either the task must be able to refresh mid-flight, or the window must exceed the maximum task duration — and the maximum needs to be a known, enforced number rather than an assumption.

Cached DID documents and JWKS. Cross-organization verification caches aggressively because resolution is expensive. Counterparties you do not control decide their own TTL. Publish key changes with lead time, and where the protocol allows, signal rotation ahead of the switch. On verification failure, revalidate the document once before rejecting — that single behavior absorbs most rotation-timing mismatches. See agent identity spoofing and DID verification.

Credentials copied where nobody tracked them. The reason rotation breaks unexpectedly is almost always a copy: a key pasted into a second service's configuration during debugging, embedded in a container image, in a CI variable, in a notebook. Rotation breaks that copy and nobody knows why. This is the practical argument for provisioning credentials only through a recorded connection — the inventory then exists as a byproduct. See secure agent offboarding and deprovisioning.

Per-tenant keys multiply the operation. Per-tenant signing keys are good isolation practice and they turn one rotation into N, each needing its own window and its own verification. Automate or do not do it — a manual per-tenant rotation across hundreds of tenants will not be completed.

Audit chain continuity. If audit entries are signed, rotation must preserve verifiability of historical entries. That means retired public keys stay available for verification even after they stop being accepted for new signatures, and the chain records which key signed which range. Deleting old public keys makes historical records unverifiable, which is the same as not having them. See tamper-evident audit logs.

Make It Routine

Automate the whole sequence. A scheduled job that generates, publishes, waits, switches, waits, retires — with the waits driven by configured TTLs rather than by someone's judgment.

Rotate frequently enough that it stays exercised. Monthly or quarterly for signing keys. The point is less about limiting key exposure than about ensuring the mechanism works: a rotation that runs every month is a rotation that will work during an incident.

Alert on rotation failure loudly. A silent failure means you believe you rotated and did not. Verify the outcome — check that new signatures carry the new key id and that the old key was actually retired — rather than checking that the job exited zero.

Track key age as a metric. A dashboard showing the oldest active credential per agent and per tenant makes drift visible. Credential age is one of the more useful non-human identity hygiene metrics available.

Test the emergency path separately. Once or twice a year, revoke a credential in a staging environment with no overlap window and confirm the blast radius is what you expect and that recovery works.

The Better Answer: Have Less to Rotate

Rotation is operational overhead that exists because long-lived credentials exist. Reduce the population and the problem shrinks.

Short-lived, audience-restricted access tokens derived from a workload or agent identity rotate continuously by construction — the credential's lifetime is minutes, so there is no rotation event, and revocation is a matter of disabling the identity rather than hunting for copies. Workload attestation removes the bootstrap secret entirely. See mTLS, SPIFFE, and workload identity for agents and token exchange for agent-to-tool authorization.

What remains after that transition is a small set: root signing keys, provider API keys where the provider offers nothing better, and encryption keys. That set is small enough to rotate carefully and often. The credentials you cannot eliminate should be held by a proxy and attached at call time, so exactly one copy exists and rotating it is a single operation. See secrets management for AI agents.

Common questions

How often should agent credentials rotate?

For anything long-lived, quarterly at minimum and monthly if automated, with the caveat that frequency matters less than the mechanism being proven. For access tokens, minutes to an hour, refreshed continuously — at which point the question stops applying. Prefer moving credentials into the second category over rotating them faster in the first.

Does rotation help if the compromise is not detected?

Yes, and it is the main argument for scheduled rotation. Rotation bounds the useful lifetime of a credential that leaked without anyone noticing — which describes most credential leaks, since the median time to detect is long. It does not help against an attacker with ongoing access to the source of the credential, who will simply obtain the new one; for that, the fix is removing the access path, not rotating faster.

What about keys held in a KMS or HSM?

The key material never leaves, which removes the theft risk and most of the distribution problem — a strong reason to use one for root signing keys. Rotation is still required because the key identifier changes and verifiers must learn the new public half. The mechanics are the same; only the custody improves. Per-tenant keys in a KMS are a good pattern precisely because rotation becomes an API call rather than a secret-handling exercise.

How do I rotate a provider API key without dropping traffic?

Most providers allow multiple active keys. Create the second, deploy it, verify traffic is flowing on the new key by checking provider-side usage attribution, then delete the first. The failure mode to avoid is deleting the old key before confirming the new one is actually in use — configuration deploys are not the same as configuration taking effect. Where a provider allows only one key, accept a brief window and schedule it deliberately.

How Praesidia approaches credential lifecycle

Praesidia issues short-lived, audience-restricted tokens per governed connection, so the credentials agents use rotate continuously and revocation takes effect at the next refresh rather than requiring a search for copies. Downstream credentials — provider keys, third-party secrets — are held once at the proxy and attached after policy evaluation, which means one copy to rotate and no credential in an agent's environment or context.

Signing keys are per tenant and can be held in managed key custody rather than as local material, and verification retains historical public keys so rotation does not invalidate past records. See NHI credential lifecycle management and the Praesidia documentation.