GitHub catalogued 39 million leaked secrets in 2024 alone — a 67% increase over the previous year. Most of them were API keys. Some were rotated within hours. Most weren’t: GitGuardian’s research found that 70% of secrets leaked in 2022 were still valid in 2024.
The data isn’t an outlier. 84% of security professionals say their organization experienced an API security incident in the past year, according to Akamai’s State of API Security report. Each incident involving compromised credentials costs, on average, $4.88M to resolve, per IBM’s annual Cost of a Data Breach report.
If you’ve worked in software for any length of time, none of this surprises you. Keys leak. They’ve always leaked. The interesting question isn’t “how do we stop them from leaking” — it’s why every attempt to stop the leaks keeps failing.
The Five Ways Keys Get Out
Public source code repos. A developer pushes a .env file with production credentials by accident. Even private repos aren’t immune — credentials end up in commit histories that survive long after the repo is rotated, archived, or audited. GitHub’s secret scanning catches some of this, but only after the secret is already public.
Logs. Errors get logged. Request payloads get logged. Headers get logged. Eventually a key shows up in a log line and lives there in your observability stack — sometimes for years, sometimes searchable by anyone in your organization, sometimes mirrored to a third-party SaaS that you forgot has a copy.
LLM context windows. This is the new frontier. To give an AI agent access to a service, the standard practice is to put the credential in the system prompt or environment variables and let the agent use it via tool calls. Now your Stripe secret key is part of the text being sent to a foreign inference API thousands of times a day. It can be logged, it can be extracted by a prompt injection attack, and it can leak through the model’s responses if a clever attacker asks the right way.
Mobile and desktop applications. Every API key shipped in a mobile app binary is, eventually, decompiled and extracted. Every key in a desktop SDK lives in ~/.config somewhere on a developer’s machine — a machine that gets stolen, ransomwared, or simply borrowed.
Insider and operator exposure. Anyone with access to your secrets store can read them. Anyone with operator access to your hosting platform can intercept them in transit. Anyone with database access to a SaaS’s credential store can dump them. Most credential-related breaches don’t require a hack — they require an account.
Rotation Is Not a Fix
The standard advice is rotation: assume keys will leak, just rotate them often enough that any leaked key becomes stale before an attacker can use it. The math doesn’t work.
GitGuardian’s 70% figure means that the majority of secrets leaked in 2022 — two years before they ran their analysis — were still valid in 2024. Organizations that publish credentials by accident usually don’t notice for weeks or months. Some never notice. Rotation policies sound good on paper; in practice, “rotate quarterly” plus “leak undetected for nine months” equals “your key was hot for nine months.”
And rotation is operationally expensive. Every dependency that holds a copy of the key needs to be updated. Cron jobs, service deployments, third-party integrations, partner systems. The friction of doing this honestly is why most organizations rotate less often than they say they do, and why “we’ll rotate it after this release” becomes “we’ll rotate it next quarter.”
The Real Problem: Keys Are Bearer Tokens
A key isn’t tied to who is using it. Any process holding a copy of the key can use it, and the system on the receiving end has no way to tell the difference between you and an attacker. The key is the authorization.
This is the source of every leakage failure mode. If keys carried information about who was using them, leaks would matter less — a key used in the wrong context could be detected and rejected. But they don’t. A leaked Stripe key is exactly as good as the original, indistinguishable, fully empowered to charge cards until somebody manually disables it.
It’s also why agent breaches are so dangerous. When a traditional service is compromised, the attacker gets the credentials it had. When an AI agent is compromised, the attacker gets the agent’s access. If your customer service agent has the keys to your CRM, your email, your billing system, and your knowledge base, “the agent leaked one credential” is a misnomer — the attacker just inherited the agent’s full operational footprint.
What Changes With Identity-Based Access
The structural fix is to stop authorizing systems by what they hold and start authorizing them by what they are.
In an identity-based model, an agent doesn’t have a key. It has an identity — a cryptographic identity backed by a public/private keypair, where the private half is generated and held in secure infrastructure the agent doesn’t have direct access to. When the agent makes a request, it doesn’t send a credential. It signs the request with its identity. The receiving system verifies the signature, checks whether that identity is authorized for the action, and either approves or denies.
There are several things this changes:
Compromise doesn’t transfer. If the agent is breached, the attacker gets the agent’s session — not a key they can use elsewhere. The signing infrastructure stays out of reach.
Authorization is granular. Identity-based systems can attach fine-grained permissions to each identity: this agent can read but not write, this agent can spend up to $500 a month, this agent can call this endpoint but not that one. None of this is possible with a bearer token.
Revocation is instant. Pull the identity’s grants and the agent can no longer act. No key rotation across dependencies, no waiting for cached credentials to expire — the next request fails authorization at the gateway.
Audit by identity. Every action is logged against the identity that took it, not against an anonymous key. When something goes wrong, you know exactly which agent did what, when, and on whose behalf.
This is the model that infrastructure like Layr8’s Key Shield is built on. Your agents authenticate by identity. Your API keys stay locked in the gateway, never copied into the agent’s context. Even a fully compromised agent ends up with nothing valuable to leak.
The leaks won’t stop. They’ll just stop mattering.
Want to see how it works? Read about the Key Shield or spin up your first agent.