# AI API keys leaked on GitHub: what secret scanning catches

URL: https://infro.io/blog/ai-api-keys-github-secret-scanning
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> GitHub secret scanning runs on every public repository and forwards partner-format keys, including OpenAI and Anthropic API keys, to the provider, which can revoke them; push protection blocks many AI key formats before they land. It does not cover Google's Gemini API key format as a partner pattern, private repositories without GitHub Secret Protection, other Git hosts, or keys in images, logs and notebooks outside GitHub. Add a pre-commit scanner such as Gitleaks or TruffleHog and treat every exposed key as compromised.

Key takeaways:
- GitHub scans all public repositories and forwards partner-format secrets, including OpenAI and Anthropic API keys, to the provider, which decides whether to revoke.
- Push protection for users is on by default for public repositories; push protection for repositories needs GitHub Secret Protection and is off by default.
- GitHub's pattern table lists the Google Gemini API key format with neither partner reporting nor push protection, so Gemini key leaks rely on Google's own detection.
- Private repositories, other Git hosts, container images, notebook outputs, CI logs on other platforms and chat transcripts are outside the partner safety net.
- Run a pre-commit scanner such as Gitleaks or TruffleHog, and treat any exposed key as compromised even after the provider revokes it.

**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](https://infro.io/blog/leaked-openai-api-key) or [a leaked Anthropic key](https://infro.io/blog/leaked-anthropic-api-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[1]. 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[1]. 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[2]. 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[2].

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[3]. These partner alerts are reported to the provider and do not appear in the repository's own alerts[2].
- **Public npm packages.** The partner program also covers public npm packages[3].
- **Private repository.** Matches raise alerts for the repository's admins and the committer. They are not sent to the provider[3], 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[4]:

| Key type (GitHub's name) | Partner: sent to provider | Push protection | Validity check |
| --- | --- | --- | --- |
| OpenAI API Key | Yes | Yes | Yes |
| Anthropic API Key | Yes | Yes | Yes |
| Anthropic Admin API Key | Yes | Yes | Yes |
| Anthropic Service Account / User API Key | Yes | Yes | No |
| Google API Key | Yes | No | Yes |
| Google Gemini API Key | No | No | No |
| Google Cloud Service Account Credentials | Yes | Yes | Yes |
| Azure OpenAI Key | Yes | Yes | No |
| Azure AI Services Key | Yes | Yes | Yes |
| Hugging Face User Access Token | Yes | Yes | Yes |
| xAI API Key | Yes | Yes | Yes |
| Groq API Key | Yes | Yes | Yes |
| Mistral AI API Key | No | Yes | Yes |
| DeepSeek API Key | No | Yes | Yes |
| Perplexity API Key | No | Yes | No |
| Cohere API Key | No | Yes | Yes |

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[5]. 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[6]. 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[7].

**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[4]. 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[8]. Restrict every Gemini key to the Gemini API, and see [Google API keys and Gemini exposure](https://infro.io/blog/google-api-keys-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[9]. 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[9].
- **Push protection for repositories** is off by default, needs GitHub Secret Protection, and can be enabled per repository, organization or enterprise[9].

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[9]. 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[9]. 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:

| Where the key is | Why GitHub's partner path misses it |
| --- | --- |
| Private repository without Secret Protection | Not scanned at all[2] |
| Private repository with Secret Protection | Alert only; the provider is not told[3] |
| GitLab, Bitbucket, self-hosted Git | Not GitHub |
| Container images in a registry | Not a repository; a `COPY .env` layer ships the key |
| Notebook outputs on hosted notebook services | Printed `os.environ` values live in output cells outside Git |
| CI logs on other platforms, crash reports, APM traces | Logs are not repositories |
| Packages on registries other than npm | The partner program documentation names only npm |
| Chat threads, tickets, agent transcripts | Text outside GitHub |
| Browser bundles and mobile binaries | Shipped to users by design; see [AI API keys in frontend and mobile apps](https://infro.io/blog/ai-api-keys-frontend-mobile-apps) |

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[10].

```bash
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[10].

**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[11]. 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[11]. In CI, fail the build on verified or unknown results for the changes on a branch:

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

With `--fail`, exit code 183 means results were found[11].

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[2]. Google's order for Gemini keys is generate a new key, deploy it, then disable the leaked one[8].
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](https://infro.io/blog/short-lived-credentials-ai-apis) where the provider supports them, and one tightly held key per service elsewhere.

> **Warning: A revoked key can still have been used**
> Partner revocation happens in seconds to minutes, but automated scraping of public commits is also fast. Assume the key was used, check the provider's usage for the window, and treat any data the key could read — uploaded files, stored responses, fine-tuning datasets — as exposed.

## 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](https://infro.io/docs/features/guardrails) can also detect OpenAI, Anthropic, Google and INFRO key formats in prompts and responses and block or redact them. [Gateway key controls](https://infro.io/blog/gateway-key-controls-environments) covers the setup, and [Authentication](https://infro.io/docs/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.

## Questions

### Does GitHub automatically revoke a leaked OpenAI API key?

GitHub does not revoke keys itself. For partner formats found in public repositories, it sends the key to the provider, and the provider decides what to do. OpenAI has been a partner since 2021, and GitHub's announcement says the issuing service deactivates the key and alerts the owner. Rotate the key yourself anyway and check usage for the exposure window.

### Does secret scanning work on private repositories?

Only if the organization has GitHub Secret Protection (GitHub Team or Enterprise Cloud). Even then, matches in private repositories raise alerts for the repository's admins and the committer; they are not sent to the provider, so nothing is revoked for you.

### Will GitHub catch my Gemini API key?

GitHub's supported patterns table lists the Google Gemini API Key type with no partner reporting and no push protection. The generic Google API Key type is a partner pattern but is not blocked by push protection. Google says its newer auth keys include fast-acting leaked-key enforcement on its side.

### Is deleting the commit enough after a key leaks?

No. Anyone who cloned or scraped the repository has the key, and deleting a commit does not revoke it. Revoke and replace the key at the provider, then review usage. Rewriting history is optional clean-up, not remediation.

## Sources

1. The State of Secrets Sprawl 2026 — GitGuardian. https://gitguardian.com/state-of-secrets-sprawl-report-2026 (accessed 2026-10-21)
2. About secret scanning — GitHub Docs. https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning (accessed 2026-10-21)
3. Secret scanning partner program — GitHub Docs. https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partnership-program/secret-scanning-partner-program (accessed 2026-10-21)
4. Supported secret scanning patterns — GitHub Docs. https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns (accessed 2026-10-21)
5. RubyGems, Adobe and OpenAI are now GitHub secret scanning integrators — GitHub Changelog. https://github.blog/changelog/2021-06-08-rubygems-adobe-and-openai-are-now-github-secret-scanning-integrators (accessed 2026-10-21)
6. API key best practices: keeping your keys safe and secure — Anthropic. https://support.claude.com/en/articles/9767949-api-key-best-practices-keeping-your-keys-safe-and-secure (accessed 2026-10-21)
7. Secret scanning blocks Anthropic keys by default, adds Salesforce — GitHub Changelog. https://github.blog/changelog/2026-10-13-secret-scanning-blocks-anthropic-keys-by-default-adds-salesforce (accessed 2026-10-21)
8. Using Gemini API keys — Google AI for Developers. https://ai.google.dev/gemini-api/docs/api-key (accessed 2026-10-21)
9. About push protection — GitHub Docs. https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection (accessed 2026-10-21)
10. gitleaks/gitleaks — GitHub. https://github.com/gitleaks/gitleaks (accessed 2026-10-21)
11. trufflesecurity/trufflehog — GitHub. https://github.com/trufflesecurity/trufflehog (accessed 2026-10-21)