Secret rotation is a control every security programme has on paper and few execute at the stated frequency. With agents in the environment, the gap between paper and practice widens — because the credential consumer is now a process nobody wants to wake at three in the morning.
Why it breaks more with agents
Three reasons compound. The credential usually sits in an environment variable, which means it is read only at process start — rotating requires a restart. The agent may be mid-way through a long-running task when the key changes. And with a fleet-wide shared identity, rotating one key takes everything down at once.
The predictable result is that rotation gets postponed. And a postponed key is the kind Astrix's audit found in 53% of MCP servers as a static credential, with no expiry, valid since the day it was created.
Your real rotation frequency is not the one in the policy. It is the one the design allows without causing an incident.
The design that makes rotation painless
- Remove the key. Workload identity federation solves the problem by deleting the object that needs rotating. It is the only definitive fix.
- If a key is unavoidable, read it on demand. Fetching from the secrets provider per call, or with a short cache, allows rotation without restarting anything.
- Overlap versions. The new key takes effect while the old one is still accepted for a window. Rotation without an overlap window is scheduled downtime.
- One identity per agent turns rotation into an isolated operation rather than a platform event.
The test that reveals the truth
Pick an agent and rotate its credential right now, during a quiet period. If you hesitated before finishing this sentence, the answer already appeared: the design does not support rotation, and the policy claiming ninety days is documented fiction.
