The State of API Key Security: What the Data Says

In its State of Secrets Sprawl 2025 report, GitGuardian counted about 23.8 million new secrets in public GitHub commits during 2024, up from about 12.8 million the year before.

Source for all three: GitGuardian, The State of Secrets Sprawl 2025.

That count covers only public GitHub. It doesn't include private repositories, internal tooling, chat and ticketing systems, or CI logs, where secrets also leak, so the real exposure is larger.

And leaks last: GitGuardian found that about 70% of the secrets it saw leak in 2022 were still valid when it checked again for the 2025 report. Rotation after a leak is the exception, not the rule.

GitGuardian's 2025 report found that public repositories with GitHub Copilot enabled leaked secrets more often: about 6.4% of them, against about 4.6% of public repositories overall. That's a correlation, not proof of cause.

Plausible mechanisms aren't hard to find. AI tools generate code faster, which means developers push more commits per day. The suggestion–accept loop in AI-assisted coding reduces code review friction. When an AI completes a code block that happens to use an environment variable, it sometimes suggests inline examples using real-looking key formats - and developers accept the suggestion without noticing the example became real.

There is also a subtler factor: AI tools read context from open editor windows. A developer with a .env file open in a split pane may inadvertently allow the AI tool to reference that context in generated code.

The solution is not to stop using AI tools. The solution is to ensure that the credentials being committed are safe to commit by design - not by discipline.

Researchers who plant decoy keys in public repositories consistently report them being found and tried within minutes. This is not humans manually watching GitHub. Automated scraping infrastructure monitors the GitHub event stream via the public API, applies regex patterns for known secret formats, and immediately submits them to trial-request bots. The entire pipeline is automated and operates at scale.

The implication is that “I'll rotate it immediately” is not a viable plan on its own. Rotate immediately, every time, but assume the key may already have been tested by the time you act.

GitGuardian's reports consistently show a large share of leaks are generic secrets (passwords, connection strings, unbranded API keys) that pattern-based scanners struggle to recognise, alongside provider keys for cloud platforms, AI providers, source control and payments. The provider keys are the ones attackers can monetise fastest:

The tooling ecosystem for secret security has expanded substantially since 2020. GitHub's native secret scanning, Gitleaks, TruffleHog, HashiCorp Vault, Doppler, AWS Secrets Manager - the gap is not from a lack of tools.

The gap is architectural. Every existing tool operates in one of two modes:

Neither category makes the credential safe to commit. Neither category eliminates the real key from the deployment surface. Both require perfect operational discipline from every engineer, every time.

One architecture that keeps the plain-text credential out of the developer's environment is a host-bound token proxy. Instead of the real key, your deployment holds a signed, encrypted token that the edge proxy only honours for requests from the hosts you list.

# The real key is gone from your environment
KVE_TOKEN=kvt_...your_token

# Requests go to https://proxy.keyvaultedge.com/v1/... with
#   X-KV-Token: $KVE_TOKEN
#   X-KV-Target: https://api.openai.com

The real OpenAI key is encrypted with AES-256-GCM. The edge proxy verifies the token, decrypts it in Worker memory, checks the request origin, and forwards to OpenAI. Your deployment never holds the plain-text credential.

You keep your provider's SDK: point its base URL at the proxy and add two headers. It does not require a backend rewrite.