What is API key security?
By Identra · Updated
API key security is the practice of protecting API keys, the static bearer credentials that authenticate software to APIs. Because a key grants access to anyone who presents it, with no identity binding and often no expiry, security depends on tight scoping, short rotation cycles, leak detection, and fast revocation.
Key numbers
- 28.65 million new hardcoded secrets were added to public GitHub commits in 2025, a 34% increase year over year (GitGuardian State of Secrets Sprawl, 2026)
- 64% of credentials confirmed valid in 2022 were still valid in January 2026 (GitGuardian State of Secrets Sprawl, 2026)
- Leaked AI service secrets reached 1,275,105 detections in 2025, up 81% year over year (GitGuardian State of Secrets Sprawl, 2026)
Why are API keys a security problem?
An API key is a bearer credential. Whoever presents the string gets the access it grants, whether that is the service the key was issued to, a contractor who copied it into a script, or an attacker who scraped it from a public repository. The API on the receiving end cannot tell the difference, because nothing in the key binds it to a specific workload, machine, or person.
That design has two structural weaknesses. First, there is no identity binding: possession equals authorization, so a stolen key works exactly as well as a legitimate one. Second, most keys have no expiry. An OAuth access token dies in minutes or hours, but an API key issued in 2022 keeps working until someone revokes it. GitGuardian found that 64% of credentials confirmed valid in 2022 were still valid in January 2026, roughly four years after they leaked.
How do API keys leak?
Keys leak because they are plain strings that developers must copy into places where code runs. Every one of those places is a potential exposure point, and the volume keeps climbing: 28.65 million new hardcoded secrets landed in public GitHub commits in 2025 alone, per GitGuardian's 2026 report.
- Source repositories: keys hardcoded in application code, test fixtures, or example configs, then pushed to public or overly shared private repos
- CI/CD pipelines and logs: keys echoed into build output, crash dumps, or debug logs that far more people can read than the original secret store
- AI prompts and agent context: keys pasted into chat prompts, embedded in model context, or committed by AI coding assistants, whose assisted commits GitGuardian found leak secrets at roughly twice the baseline rate of public commits overall
- Collaboration tools: keys shared in tickets, wikis, and chat channels where retention is long and access control is loose
- Client-side code and mobile apps: keys shipped inside JavaScript bundles or app binaries where anyone can extract them
API keys vs. identity-bound credentials
The alternative to a static bearer key is a credential that is short-lived, bound to a verified workload identity, or both. The differences matter most when a credential leaks.
| Property | Static API key | OAuth 2.0 access token | Workload identity (mTLS, SPIFFE) |
|---|---|---|---|
| Lifetime | Indefinite until revoked | Minutes to hours | Short-lived, auto-renewed |
| Bound to a specific workload | No | Partially, via the client | Yes, cryptographically attested |
| Value of a leaked credential | Full access until revocation | Access until expiry | Near zero without the workload's private key |
| Scoping | Often coarse, sometimes all-or-nothing | Scopes and audiences | Per-identity policy |
| Rotation burden | Manual or scripted | Built into the protocol | Built into the platform |
API key security best practices
Where API keys cannot be replaced outright, the goal is to shrink what any single key can do and how long a leaked one stays useful.
- Scope every key to the minimum: one key per service and environment, restricted to the specific endpoints, methods, and IP ranges it needs
- Set expiry and rotate on a schedule: treat any key older than 90 days as a finding, and automate rotation so it does not depend on a human remembering
- Keep keys out of code: inject them at runtime from a secrets manager instead of committing them, and scan repos, pipelines, and images for leaks continuously
- Monitor usage per key: alert on new source IPs, unusual call volumes, or endpoints a key has never touched before
- Revoke fast: maintain a tested, one-step path to kill and reissue any key, because detection is worthless if revocation takes a change ticket and a week
How do AI agents change API key risk?
AI agents concentrate every weakness of the API key model. Agents authenticate to models, tools, and downstream APIs almost entirely with static keys, they copy those keys into prompts and context windows that get logged and cached, and they act at machine speed once credentialed. GitGuardian recorded 1,275,105 leaked AI service secrets in 2025, an 81% jump year over year, driven by keys for LLM providers and agent frameworks.
The deeper issue is delegation. When an agent holds a key, the API sees only the key, not which agent, which task, or which human's intent stands behind the call. A prompt-injected agent and a well-behaved one present identical credentials. That gap between the credential and the actual actor is what modern non-human identity security, including the OWASP Non-Human Identity Top 10, exists to close.
How Identra thinks about it
We frame API key security as a containment strategy, not a destination. Rotation and scoping shrink the blast radius of a static credential, but they never answer the question that matters at request time: which workload or agent is actually making this call, and is that behavior normal for it? Binding credentials to verified runtime identity, human, non-human, or AI agent, turns a leaked string from a master key into a useless artifact, because possession alone no longer equals authorization.
Go deeper: The Non-Human Majority
Frequently asked questions
What is the difference between an API key and an OAuth token?
An API key is a static bearer string with no built-in expiry: whoever holds it gets access until someone revokes it. An OAuth access token is issued through a protocol flow, carries scopes and an audience, and expires on its own, usually within minutes to hours. That expiry bounds the damage of a leak, which is why tokens are generally safer than long-lived keys.
How long should an API key live before rotation?
A common operational bar is to treat any key older than 90 days as a finding, and to rotate immediately after any suspected exposure or the departure of someone who had access. The schedule matters less than automation: rotation that depends on a human remembering will be skipped, so wire it into your secrets manager and deployment pipeline.
What should I do if an API key is leaked?
Revoke it first, then investigate. Reissue a replacement through your normal deployment path, review provider logs for calls made with the leaked key, and check for data access or resource creation you did not initiate. If the key was committed to a repository, assume it was scraped within minutes; scanners harvest public commits continuously, so purging the file from history is not sufficient.
Why do AI coding tools increase API key leaks?
Keys get pasted into prompts, cached in model context, and committed by assistants that reproduce credentials seen elsewhere in the workspace. GitGuardian found AI-assisted commits leak secrets at roughly twice the baseline rate of public commits overall, and leaked AI service secrets reached 1.27 million detections in 2025, up 81% year over year.