How to find LLM API keys in code and CI: Scan repos, pipelines and images, then triage

LLM provider API keys leak into repositories, notebooks, pipeline logs and container images faster than most secret scanning programmes were tuned to catch them, and a working key is spent by someone else within hours. This runbook shows how to find OpenAI, Anthropic, Google Gemini, Hugging Face and similar keys across source code, git history and CI/CD, using the recognisable key formats, the open source rule sets in Gitleaks and TruffleHog, and platform scanning such as GitHub secret scanning. It then covers how to triage each finding to an owner and a provider organisation, and the order in which to revoke, rotate and clean up. It is written for application security, platform and DevSecOps engineers. For the wider context of stolen model access, see the LLMjacking Guide.

This is an independent guide from NHI Mgmt Group, based on public documentation from the tool projects and providers named below as of November 2026. It is not sponsored or reviewed by any of them. Key formats and detection rules change, so confirm them against the current upstream sources.

Key takeaways

• Most LLM keys carry a findable marker. OpenAI keys contain T3BlbkFJ and start sk-proj-, sk-svcacct- or sk-admin-; Anthropic keys start sk-ant-api03- or sk-ant-admin01- and end AA; Gemini keys start AIza; Hugging Face tokens start hf_.
• Scan history, not only the current tree. A key deleted in a later commit is still in every clone. Run a full history scan once, then scan only new commits.
• CI is a second source of leaks. Logs, artefacts, Docker build arguments and workflow files hold keys that never reach the default branch.
• Verify before you page someone. TruffleHog can test OpenAI and Anthropic keys against the provider API and report them as verified, which turns thousands of findings into a short live list.
• Revoke first, rewrite history second. Removing a key from git does not stop its use. Rotate or disable at the provider, confirm usage has stopped, then clean up.

When you need this

• A first sweep after AI adoption: teams that started calling model APIs in prototypes, notebooks and internal tools rarely put those keys through the same review as cloud credentials.
• After an unexpected bill or a provider notice: a jump in spend or an email that a key was found in public is usually the first sign. The LLMjacking 2024 to 2026 breach page shows how quickly stolen keys are resold and used.
• After a supply chain incident: malicious packages and plugins harvest model keys from developer machines and CI. The LiteLLM PyPI package breach is a direct example, and the JetBrains Marketplace AI plugin campaign shows the same goal through IDE plugins.
• Before publishing images or open-sourcing a repository: the Docker Hub secrets leak found AI keys among the credentials baked into public images.

Before you start

Build the detection reference first. The table lists the formats used by the default rules in the Gitleaks configuration and the TruffleHog detectors (both read from their GitHub repositories in November 2026), plus GitHub secret scanning where its supported patterns page confirms the provider.

Three practical points follow from the table. First, Google states that every Gemini API key belongs to a Google Cloud project, so an AIza finding may be a Maps or Firebase key that later gained Gemini access; the Google API keys exposure breach page covers that shift. Second, GitHub notes that push protection supports only the most recent token versions, so older Anthropic key formats may not be blocked at push. Third, keys with no prefix need a keyword-anchored custom rule; the Generic API Key Detection Guide explains how to write one without flooding triage.

Agree two things before scanning: where findings will be stored (a report file holds live secrets, so redact output and restrict access), and who can revoke keys at each provider. The scan is only useful if a finding reaches someone with an Admin API key or console role in the right organisation within hours.

Step-by-step

Steps 1 to 5 are read-only. Steps 6 and 7 change credentials and must follow the triage in step 5.

1. Define the scan surface. List every location an LLM key can land, using the table below. Include repositories that look unrelated to AI: evaluation scripts, data science notebooks and internal tools are where prototype keys live.

   Location	Typical leak	How to scan
   Source tree	.env files, config modules, test fixtures, sample code	gitleaks dir on a checkout
   Git history, all branches	Key added then "removed" in a later commit	gitleaks git with --log-opts="--all", or trufflehog git
   Notebooks (.ipynb)	Key pasted into a cell or printed in saved output	Directory scan; notebooks are JSON text, so the same rules match
   CI workflow files	Key written inline in env: instead of referencing a secret	Repository scan covers them; review pull requests that touch workflows
   CI logs and artefacts	Key echoed by a debug step, or written into a test report	Download and scan with trufflehog filesystem or gitleaks dir; see How to find secrets in CI logs and build artefacts
   Container images	Key passed as a build argument or copied in a layer	trufflehog docker --image; see How to find hard-coded secrets in container images
   Issues, pull request comments, wikis	Key pasted while asking for help	trufflehog github with --issue-comments --pr-comments

2. Scan the current tree and full history. Gitleaks scans a repository's history with the git command and passes git log options through, so all branches can be included:

   gitleaks git -v --redact --log-opts="--all" --report-format json --report-path llm-keys.json path/to/repo
   gitleaks dir -v --redact path/to/checkout

   --redact keeps secrets out of stdout and logs; the report format can also be sarif for code scanning tools. To keep the first run focused, filter the JSON report on the rule IDs from the reference table rather than writing a separate configuration. For an organisation-wide sweep, TruffleHog can enumerate repositories itself:

   trufflehog github --org=<your-org> --results=verified,unknown --json
   trufflehog git file://path/to/repo --results=verified,unknown --json

3. Add rules for keys without prefixes. For Azure OpenAI, Mistral, internal gateway keys and similar, write a custom rule anchored on the variable or header name your code actually uses (for example the environment variable your SDK reads), and point Gitleaks at it with --config or the GITLEAKS_CONFIG environment variable. Extend the default configuration rather than replacing it, so the vendor rules still run.
4. Scan CI separately from code. Pull recent job logs and build artefacts for each pipeline that calls a model API and scan them as files. Remember the limits of masking: GitHub redacts values stored as secrets, but a key that reaches the log by another route is only masked if the workflow registers it with ::add-mask::, and GitHub states it does not redact values handled through its large-secret workaround. For images, Docker states that build arguments and environment variables are inappropriate for passing secrets because they end up in the final image; any LLM key passed with --build-arg should be treated as exposed to everyone who can pull the image.
5. Triage each finding to a live key, an owner and an organisation. Work in this order:
   • Live or dead: TruffleHog reports a result as verified when it has confirmed the credential against the service's API. Treat verified keys as an incident; treat unknown results as live until proven otherwise.
   • Which organisation: match the leaked value to a key record without handling the full secret twice. Anthropic's Admin API returns a partial_key_hint such as sk-ant-api03-R2D...igAA for every key, and OpenAI's key objects return a redacted_value. Compare the start and end of the finding with these. The How to audit OpenAI and Anthropic organisation API keys runbook shows the listing calls.
   • Who owns it: the commit author is a lead, not an owner. Use the key's owner or creator field at the provider, then the repository's code owners.
   • How exposed: public repository, internal repository, log retained for 90 days, published image. Public exposure means assume use.
6. Revoke or rotate at the provider. Issue a replacement, deploy it from a secret manager, confirm the application works, then disable or delete the leaked key. OpenAI's guidance is to issue a replacement, update the workload, verify it works, and then revoke the old key. For Anthropic, the Admin API can set a key's status to inactive. If the key is verified live and publicly exposed, disable it immediately and accept the outage; the AI model provider API keys leak response guide covers the full sequence.
7. Clean up the source. Remove the key from the current tree, then decide whether to rewrite history. Rewriting does not un-leak a key that was public, but it stops the same finding reappearing in every future scan and fork. See How to Remove Secrets From Git History. Purge CI logs and delete artefacts or image tags that contain the key.

Verify it worked

• Re-scan with the same command and configuration. The finding should be gone from the current tree; if history was rewritten, it should be gone from the history scan too. If history was not rewritten, record the finding's fingerprint in .gitleaksignore with a note that the key is revoked, so the noise does not hide new leaks.
• Confirm the key is dead. A TruffleHog re-run should no longer report it as verified. At the provider, the key should show as inactive, archived or deleted.
• Check usage after revocation. For Anthropic, query the usage report filtered by api_key_ids[]; for OpenAI, query the completions usage endpoint filtered by api_key_ids. Usage should drop to zero after the revocation time.
• Confirm the replacement is stored properly. The new key should appear only in the secret manager and the CI secret store, never in a file a scan can see.

Rollback and common errors

Hardening afterwards

• Turn on push protection where your platform supports it, so supported provider keys are blocked before they reach the remote. See How to enable GitHub secret scanning push protection.
• Scan every pull request with a pinned rule set and a baseline, and fail the build on verified results.
• Remove the reason keys get pasted. Give developers a documented way to get a personal, expiring, low-limit key, and give deployed workloads service account keys or federation. OpenAI describes user-owned project keys for local development and service account keys for deployed applications and CI; Anthropic supports workload identity federation so no static sk-ant-api secret exists. See the Anthropic API Keys Security Guide and the OpenAI API Keys Security Guide.
• Put a gateway in front of providers so applications hold a gateway credential with its own limits instead of a provider key. See the AI Gateway and LLM Gateway Guide.
• Cap the damage of the next leak with per-project or per-workspace spend limits. See How to set spend limits on LLM API keys.
• Cover developer tools. AI coding assistants and MCP clients keep keys in local configuration files that never reach git. See How to Audit AI coding assistant tokens and config files.

Small team or large organisation

Small teams get most of the value from three things: platform secret scanning with push protection on every repository, one full history scan with TruffleHog verification, and a rule that production keys come from a secret manager. Large organisations should run organisation-wide scans on a schedule, route verified findings into the incident queue with the provider and project already resolved, maintain custom rules for gateway and prefix-less keys centrally, and include CI log and image registries in scope. The Secret Scanner Rule Coverage Comparison Guide helps decide whether one scanner is enough.

Metrics

• Verified LLM keys open: count of verified, unrevoked findings. Target zero.
• Time to revoke: median time from detection to provider-side revocation for verified keys. Aim for hours, not days.
• Scan coverage: percentage of repositories, pipelines and image repositories scanned in the last 30 days.
• Push protection blocks and bypasses: blocks show prevention working; bypasses show where review is needed.
• Repeat leakers: repositories with more than one LLM key finding in a quarter, which point to a missing secret-manager pattern.

Framework mapping

Practitioner checklist

• Build a key format reference for every model provider your organisation uses, including prefix-less keys.
• Run one full-history scan of every repository with redaction on and verification enabled.
• Add custom keyword-anchored rules for Azure OpenAI, Mistral and gateway keys.
• Scan CI logs, artefacts and container images, not only source.
• Triage each verified key to provider, organisation, project and owner using the key hint or redacted value.
• Rotate or disable at the provider before rewriting history.
• Confirm usage of the leaked key has dropped to zero.
• Turn on push protection and pull request scanning with a baseline.
• Move deployed workloads to service account keys, federation or a gateway credential.

Standards and references

• Gitleaks: project documentation and default configuration
• TruffleHog: project documentation and detectors
• GitHub Docs: Supported secret scanning patterns
• GitHub Docs: Using secrets in GitHub Actions
• Docker Docs: Build secrets
• Google AI for Developers: Using Gemini API keys
• OpenAI: API keys guide
• Anthropic: List API Keys (Admin API reference)

Related NHI Mgmt Group resources: Git Secret Scanning Guide · Developer Secret Scanning Triage · LLMjacking Response Playbook · LLM-Powered Malware Guide