AI API keys leaked on GitHub: what secret scanning catches

What happens when an AI API key is leaked on GitHub? If the repository is public and the key is in a format GitHub's partner program knows, GitHub sends it to the provider within seconds, and the provider can deactivate it. OpenAI and Anthropic API keys are partner formats; Anthropic says it deactivates exposed keys automatically and emails the owner. Push protection can also stop many AI key formats before the push lands. Everything outside that path — private repositories without GitHub's paid feature, other Git hosts, container images, notebook outputs, logs — is not covered, and Google's Gemini key format is not a partner pattern at all.

Treat secret scanning as a backstop, not a control you depend on. This guide sets out what GitHub covers for each major AI key type, where the gaps are, and the pre-commit and provider-side checks that close them. If a key has already leaked, start with what to do about a leaked OpenAI key or a leaked Anthropic key and come back here afterwards.

Why AI keys are a common leak

AI keys sit in the same places as every other secret — .env files, notebooks, CI variables — but they spend money and expose data the moment they work. GitGuardian's State of Secrets Sprawl 2026 counts 28,649,024 new secrets in public GitHub commits in 2025 and 1,275,105 secrets for AI services, which it reports grew 81% year over year¹. The same report says 32.2% of internal repositories contain at least one secret against 5.6% of public ones, that commits co-authored by Claude Code leak secrets at roughly twice the baseline rate, and that 64% of valid secrets it detected in 2022 were still valid four years later¹. That last number is the one to remember: a leaked key that nobody revokes stays useful for years.

How GitHub secret scanning works

Secret scanning runs automatically, at no cost, on every public repository. For organization-owned private and internal repositories it needs GitHub Secret Protection on GitHub Team or Enterprise Cloud². When it runs, it covers the whole Git history on all branches, plus issue descriptions and comments, pull request titles, descriptions and comments, discussions, wikis and secret gists².

What happens to a match depends on two things: whether the key format belongs to a partner, and whether the repository is public.

• Partner format, public repository. GitHub sends the token, its type and the URL where it was found to the provider's endpoint. The provider decides how to revoke and notify; GitHub recommends providers treat every reported secret as public and compromised³. These partner alerts are reported to the provider and do not appear in the repository's own alerts².
• Public npm packages. The partner program also covers public npm packages³.
• Private repository. Matches raise alerts for the repository's admins and the committer. They are not sent to the provider³, so nothing is revoked for you.

What GitHub covers, key by key

GitHub's supported patterns table is the authority here; it changes, so check it before relying on a row. As read on 2026-10-21⁴:

Three rows deserve attention.

OpenAI. GitHub began scanning public commits for OpenAI keys in June 2021; its announcement says the issuing service deactivates a found key and alerts the owner, in seconds⁵. That is GitHub's description; confirm in your own organization's notifications what OpenAI did with a specific key.

Anthropic. Anthropic says that when GitHub finds a Claude API key in a public repository, it notifies Anthropic, which deactivates the key and emails the affected user⁶. On 2026-10-13 GitHub added Anthropic's service and user key detectors to push protection by default, blocking matching commits in repositories with secret scanning enabled, including free public ones⁷.

Google Gemini. The Gemini key type has neither partner reporting nor push protection in GitHub's table; the generic Google API Key type is a partner pattern but is not blocked at push time⁴. Google's own side has changed this year: since 2026-05-28 new keys created in Google AI Studio are auth keys bound to a service account, with what Google calls "fast-acting leaked key enforcement", and the Gemini API rejects unrestricted standard keys⁸. Restrict every Gemini key to the Gemini API, and see Google API keys and Gemini exposure for the older Maps and Firebase keys that gained Gemini access.

Push protection: blocking the push itself

Push protection stops a push that contains a supported secret before it reaches the repository⁹. It comes in two forms:

• Push protection for users is on by default, only on GitHub.com, and stops you pushing secrets to public repositories⁹.
• Push protection for repositories is off by default, needs GitHub Secret Protection, and can be enabled per repository, organization or enterprise⁹.

It covers command-line pushes, commits in the web interface, file uploads, REST API requests and, for public repositories, interactions through GitHub's MCP server — relevant now that coding agents push code⁹. By default anyone with write access can bypass it by giving a reason; a bypass is recorded in the audit log, raises an alert and emails owners and security managers, and "I'll fix it later" leaves an open alert⁹. Use delegated bypass so a bypass needs a reviewer.

What secret scanning does not see

The partner path is narrow: public GitHub repositories and public npm packages. A key in any of the following is outside it:

A key in a Gemini format leaked even to a public repository relies on Google's detection, not GitHub's partner path.

Add your own scanning before the push

A pre-commit hook catches the key on the developer's machine, before it reaches any host. Two widely used open-source scanners:

Gitleaks detects secrets in Git repositories, directories and standard input, and ships a pre-commit hook; its README notes the project is now feature complete and receiving security patches only, with the maintainer's focus moving to a successor project, Betterleaks¹⁰.

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Run pre-commit autoupdate to move to the latest tag and pre-commit install to activate it¹⁰.

TruffleHog classifies over 800 secret types and can verify whether a found credential is live by calling the issuer's API, labelling each result verified, unverified or unknown¹¹. It scans Git, GitHub and GitLab organizations, Hugging Face, Docker images, S3 and GCS buckets, filesystems, Postman workspaces and CI systems — useful for the places in the table above¹¹. In CI, fail the build on verified or unknown results for the changes on a branch:

trufflehog git file://. --since-commit main --branch "$BRANCH" \
  --results=verified,unknown --fail

With --fail, exit code 183 means results were found¹¹.

Scanners also run on the history you already have. Scan every repository once, including archived and forked ones, then rotate whatever is live.

When a scanner fires

The steps are the same whoever found the key:

1. Revoke and replace at the provider first. Removing the commit does not revoke anything; GitHub's own guidance is to rotate immediately and treats history rewriting as optional². Google's order for Gemini keys is generate a new key, deploy it, then disable the leaked one⁸.
2. Check usage for the exposure window in the provider's console, per key or project.
3. Find every copy. Forks, clones, CI caches, images built from that commit.
4. Ask why the key was in a file that could be committed. A key that only exists in a secret manager and is injected at runtime cannot be committed.

The deeper fix is to have fewer long-lived provider keys in developer hands at all: short-lived credentials where the provider supports them, and one tightly held key per service elsewhere.

How INFRO handles keys that leak

INFRO is a control plane in front of the provider accounts you own, so two different keys can leak, and they behave differently.

A provider key you connected to INFRO is not in your repositories at all: it is sealed when you save it (AES-256-GCM, the key held outside the database), never shown again, and replaced through the console or the management API when you rotate it at the provider. But be plain about the limit: INFRO's budgets, allowlists and caps govern traffic that goes through INFRO. A provider key stolen from anywhere — a repository, a laptop, or a platform such as INFRO that also holds it — can be used directly against the provider, and none of INFRO's controls see that call. The backstops are at the provider: scoped keys, provider spend limits and revocation there. On the Business plan, reconciliation compares INFRO's records with OpenAI's and Anthropic's own cost data each day, and with usage access on it reports which usage on a provider key did not go through INFRO.

An INFRO gateway key (sk_infro_) is what your applications hold instead. It is not in GitHub's partner program, so nothing revokes it for you if it is pushed. What limits it is how you issued it: one key per service and environment, an IP allowlist so a copy used from elsewhere is refused with 403 ip_not_allowed before any provider call, a spend limit checked before the provider is called, an expiry, and rotation with an overlap window. On the Business plan, INFRO's guardrails can also detect OpenAI, Anthropic, Google and INFRO key formats in prompts and responses and block or redact them. Gateway key controls covers the setup, and Authentication the key format.

Summary

GitHub's secret scanning gives public repositories a fast, free safety net: OpenAI and Anthropic keys are forwarded to the provider, and push protection blocks most AI key formats at the push. It does not cover Gemini's key format as a partner pattern, private repositories without the paid feature, other hosts, images, notebooks or logs. Add a pre-commit scanner, scan your existing history, rotate at the provider whenever a key is exposed, and reduce how many long-lived provider keys exist in the first place.