Stop Rotating API Keys. Start Expiring Them.

Your API key rotation policy says every 90 days. The average attacker uses a leaked key within 4 minutes. That gap, 90 days versus 4 minutes, is where breaches live.

These two numbers don’t occupy the same universe. One is a compliance schedule. The other is a threat timeline. They should never have been treated as though they address the same problem.

The 4-Minute Problem

GitGuardian’s research consistently shows that the median time-to-exploit for leaked secrets sits well under 10 minutes. In some datasets, it’s closer to 4. The moment a credential hits a public GitHub repo, a Slack export, a misconfigured S3 bucket, or a paste site, automated scanners pick it up almost instantly. Some of those scanners belong to researchers. A lot of them belong to attackers.

So run the math on rotation. You set a 7-day rotation schedule, which feels aggressive. Seven days is 10,080 minutes. Your exposure window, from the moment a key leaks to the moment rotation replaces it, is up to 10,080 minutes. An attacker needs 4. They win that trade by a factor of 2,500.

The core problem is what rotation assumes. Rotation is designed around the idea that attackers will find your key sometime in the future, and that future rotation will cut them off before they get in. That assumption breaks down when the attacker moves faster than your rotation schedule. Which is always.

Rotation also assumes you know when the key was compromised. In most incidents, you don’t. You find out weeks later, during incident response, that a key leaked six weeks ago and has been quietly exfiltrated ever since. By then, the rotation that “protected” you already happened. The attacker rotated with you.

There’s nothing wrong with rotation as a concept. The problem is treating it as a primary control when the threat it addresses operates on a fundamentally different timescale.

Why We Keep Rotating Anyway

Compliance is the honest answer. SOC 2, PCI-DSS, and most enterprise security frameworks include credential rotation requirements. Auditors check for it. It shows up on vendor security questionnaires. Not doing it is a finding. Doing it is a checkbox.

That’s not entirely cynical. Rotation does provide real value in specific scenarios. Post-incident, rotation terminates an attacker’s access once you’ve identified a compromised credential. It limits the blast radius if credentials are stored somewhere and that storage is later compromised. If an employee leaves and you rotate their service credentials, you close that access path. These are legitimate benefits.

The issue is the narrative that forms around rotation: that a 30-day or 90-day rotation schedule is a meaningful security control against active credential theft. It’s not. Rotation addresses key age. It does nothing about key exposure.

A key that leaked this morning and will be rotated in 47 days is not protected. It’s just scheduled to be replaced eventually. The attacker doesn’t care about your schedule.

The compliance checkbox also creates a false sense of security that can crowd out better controls. Teams that have rotation set up often deprioritize detection, revocation capabilities, and short-lived credentials because “we rotate.” Rotation feels like the job is done. It’s not.

The Two Things Rotation Can’t Do

Rotation has two hard gaps. Both matter.

Gap one: retroactive protection. Once an attacker has used a credential, rotation doesn’t undo that. If your API key was used to read customer records at 2 AM on Tuesday, rotating the key on Wednesday doesn’t un-read those records. Rotation stops future access. It can’t undo past access. By the time you rotate in response to an incident, the damage is already done.

Gap two: targeted revocation without knowing which key was compromised. This one surfaces most clearly in a realistic incident scenario. Imagine your organization has 200 active API keys across various services, CI/CD pipelines, contractors, and AI agents. Someone’s laptop gets stolen. That laptop had credentials on it, but you’re not sure which ones. Your rotation schedule says keys rotate every 60 days.

What do you actually do?

Option A: Rotate all 200 keys immediately. This is a fire drill across your entire stack. Services break. CI/CD pipelines stop. On-call engineers spend the night tracking down every integration that had a hardcoded credential. The recovery cost is enormous.

Option B: Try to figure out which keys were on that laptop, rotate only those. But you don’t have clean inventory. Some keys are in .env files that were synced to cloud storage. Some are in shell history. Some were copy-pasted into configuration panels six months ago by a contractor. This investigation takes days.

Neither option is good. Rotation is a batch operation. Attacks are targeted. When you need surgical precision, batch controls fail you.

Short-Lived Credentials: The Better Math

The security model changes completely when credentials expire on their own.

If a credential has a 15-minute TTL, the exploit window is 15 minutes, not 90 days. An attacker who intercepts a token at minute zero has until minute 15. After that, the token is worthless. They don’t need to be detected. They don’t need to be rotated out. The credential simply stops working.

Session-scoped tokens take this further. Instead of issuing a long-lived key that some service holds indefinitely, you mint a token at the start of each task and let it expire when the task completes. A token issued for a specific API call, to a specific endpoint, for a specific agent session, carries a naturally limited blast radius. If it leaks, it leaks in context. The attacker gets access to exactly that operation, for exactly that window.

This pattern is particularly important for AI agents. An AI agent calling an external API doesn’t need a persistent credential. It needs a credential for this invocation. The phantom token pattern makes this concrete: the agent never holds the real key. A credential broker intercepts the request, verifies the agent’s identity and authorization, mints a short-lived token scoped to that specific call, and the agent uses that. The real key never touches the agent’s environment.

The security model flips. You stop asking “how fast can we rotate?” and start asking “how short can the TTL be?” Those are different questions with different answers. Rotation is limited by operational overhead. TTL can be as short as the operation itself.

For most applications, 15-minute tokens are operationally trivial. For high-security surfaces like AI agents, CI/CD pipelines, and contractor access, tokens scoped to individual sessions or tasks eliminate the standing credential problem entirely.

Instant Revocation: The Kill Switch You Actually Need

Short-lived credentials solve the passive exposure problem. Instant revocation solves the active threat problem.

Rotation gives you scheduled replacement. Revocation gives you “kill it right now.” Those are not the same thing. When you discover a compromised credential at 3 PM on a Thursday, you don’t want to wait for your rotation schedule to run Friday night. You want a button that invalidates that credential in the next 10 seconds.

The capability that makes instant revocation possible is centralized issuance. If credentials are issued through a central broker, that broker knows about every active credential. It can invalidate any of them on demand. Per-agent, per-session, per-request granularity becomes possible because the broker has the full picture.

Static keys break this. When 50 services share a single hardcoded API key, “revoke the key” means “break 50 services simultaneously.” Nobody wants to do that, so they don’t. The key persists long after it should have been retired, because the cost of revoking it is higher than the perceived risk of leaving it. That calculus is wrong, but it’s a predictable outcome of static key architecture.

Centralized issuance inverts the incentive. If each service has its own short-lived credential, revoking one service’s access doesn’t touch anything else. You can revoke access for a compromised contractor, a misbehaving AI agent, or a specific CI job without any collateral damage. The granularity also makes forensics possible: you can see exactly which credentials were active, when they were used, and what they accessed.

Revocation works at multiple levels. At the key level, you invalidate a specific credential. At the agent level, you invalidate all credentials issued to a specific agent identity. At the session level, you terminate everything associated with a specific execution context. Each level gives you a different tool depending on what you know about the incident.

What the Migration Actually Looks Like

Moving from static keys to short-lived credentials with instant revocation is a migration, not a flag day. Here’s the practical sequence.

Step one: audit your static keys. Most organizations don’t have clean inventory. Start by finding all long-lived credentials in use: environment variables, configuration files, secrets managers, CI/CD pipeline variables, and any hardcoded values in code. This is usually worse than expected. The audit surface includes contractors, third-party integrations, and legacy services that nobody wants to touch.

Step two: identify high-risk surfaces. Not all static keys carry equal risk. AI agents calling external APIs are high risk because they operate autonomously and their credentials can be extracted from memory or logs. CI/CD pipelines are high risk because they run in shared environments with broad access. Contractor credentials are high risk because you have less visibility into their security practices. These surfaces get migrated first.

Step three: introduce a credential broker. A credential broker sits between your services and your credential store. Services authenticate to the broker, the broker issues short-lived tokens with appropriate scopes, and those tokens are used for actual API calls. The broker maintains the audit log. It handles revocation. It enforces scope constraints. Services no longer need to hold long-lived credentials at all.

Step four: keep rotation as hygiene baseline, not primary control. Rotation isn’t obsolete. It’s just demoted. Long-lived credentials that remain in the stack (some always will) should still rotate. Rotation limits exposure for anything that slips through the short-lived credential model. It satisfies compliance requirements. But it’s no longer the last line of defense, because it was never reliable enough to play that role.