Replace Static API Keys

GitHub's secret scanning finds leaked credentials in public repositories on the order of one a minute. Most of them are long-lived API keys: a string pasted into a .env, a CI variable, a notebook, a Slack thread. The leak is not the interesting part. The interesting part is that the key still works next month.

Static API keys were a reasonable 2005 design. One service, one integration, one engineer who remembered to rotate. They do not survive a world of 10,000 ephemeral agents, each of which needs scoped access for twelve seconds. The obituary is in Static API Keys. This page is the replacement.

Why a long-lived key is a different bug in 2026

A password at least pretends to belong to a person you can lock out. A static key is a person-shaped secret with no person:

• It is copied, not issued. Every copy is equally valid.
• It is rarely scoped. sk_live_... often means the whole account.
• It does not expire. Rotation is a project, so it does not happen.
• It shows up in crash logs, support tickets, model context windows, and agent traces.
• Revocation is a guess. You do not know how many copies exist.

When the caller is an AI agent or an MCP tool, the key also sits where prompt injection can ask the model to print its configuration. Secure an MCP server has the rule: never put secrets in the model context. Broker them at call time. That rule is impossible if the only credential you have is a year-old string in an environment variable.

What replaces the string

The destination is the same idea as zero trust for machines: authenticate the workload every time, give it the least scope, make the credential die before a pastebin post matters.

You do not have to start with SPIFFE. You do have to stop minting sk_live keys that last until someone remembers.

A migration that does not take a quarter

This week. Inventory. Grep for api_key, sk_, AKIA, xoxb-, ghp_. Turn on secret scanning on every repo and the org. Rotate anything that has ever been in Slack or a laptop .env. Put remaining human-held secrets in a manager, not in the repo. The solo-founder stack already ranks this as an afternoon.

This month. CI and deploys. GitHub Actions talking to AWS should use OIDC federation, not an access key in secrets. Same pattern exists for GCP workload identity and Azure federated credentials. Kill the org-wide admin token the intern checked in in 2023.

This quarter. Customer-facing and agent-facing APIs. Issue OAuth access tokens with a TTL measured in minutes or hours, refresh where you must, scopes that name a single intent. For agents, bind the token to the original user and check it on every tool call. That is the agent identity guide.

Leave static keys only for a break-glass path that is stored offline, alerted on use, and rotated after. If "break-glass" is how your app authenticates in production, it is not break-glass.

What "good" looks like

• No long-lived cloud access keys in CI
• No customer API keys that cannot be scoped and revoked in the UI
• No secrets in LLM context, logs, or traces
• Every machine credential has an owner, a TTL, and a name you can grep
• A leaked key that is 20 minutes old is already useless

If you sell an API and the only credential is a forever key, you will spend the next incident explaining why a paste from a contractor still had write access. Issue tokens. Put a revoke button on the key that remains.

Failure modes

1. Secret scanning as the strategy. Scanning finds copies. Short TTL makes copies boring.
2. One org-wide token "for the agents." You built a master key and handed it to a persuadable model.
3. Rotating annually. Annual is static with extra steps.
4. Putting the new OIDC setup in one repo and leaving 14 jobs on the old key. Inventory first.
5. Customer keys with no scope and no revoke. That is your breach waiting on their intern.