How to Find Leaked API Keys (Across Code and Beyond)

To find leaked API keys, you need to look in four places, in order of increasing coverage: your current code, your full git history, the sources outside code where keys actually leak, and — crucially — a verification step that tells you which keys are still live. Searching only your latest code misses the majority of real exposures. Here's a practical walkthrough you can run today.

Step 1 — Search your code and git history

Start with what you can do in seconds. A plain search across your working tree catches the obvious cases:

# Search the current checkout for common key prefixes
git grep -nE 'AKIA[0-9A-Z]{16}|ghp_[0-9A-Za-z]{36}|sk_live_[0-9A-Za-z]+'

# Search across the entire history of every branch
git grep -nE 'sk_live_|AKIA|xoxb-' $(git rev-list --all)

This finds keys that match well-known formats. But it only finds what you can describe with a pattern, and it cannot tell a real key from a placeholder. It is a useful first pass, not a complete answer.

Step 2 — Run a dedicated secret scanner

Purpose-built secret scanning tools go far beyond grep. They combine hundreds of provider-specific patterns with entropy analysis (to catch high-randomness strings that don't match a known shape) and, increasingly, machine learning to reduce noise. Run a scanner across your full repository history, not just the tip, since a key removed from current code usually still lives in old commits.

The catch with pattern-only tooling is false positives — test fixtures, example keys, and documentation samples that look real but aren't. Wading through thousands of low-value alerts is its own failure mode, one we cover in the hidden cost of false positives. Prioritize tools that score and verify findings rather than just listing matches.

Step 3 — Check the sources beyond code

This is the step most teams skip — and where the keys actually are. Research indicates roughly 43% of exposed secrets live outside code repositories. A leaked API key is far more likely to be sitting in a Slack thread, a Jira ticket, a Confluence runbook, a shared Postman collection, an S3 export, a Docker layer, or a CI/CD build log than in your latest commit.

• Chat & tickets — search Slack history and Jira comments for key patterns.
• Wikis — scan Confluence and Notion pages, especially runbooks.
• API tooling — inspect Postman collections and environments.
• Cloud & containers — scan S3 objects, Docker image layers, and pipeline logs.

If you only scan Git, you are auditing the smaller half of your exposure. We dig into each of these surfaces in Secrets Everywhere: Detecting Secrets Beyond Code.

Step 4 — Verify which keys are actually live

A detected key only matters if it still works. The strongest scanners verify a finding by making a harmless, read-only call to the provider — for example, checking whether an AWS key authenticates — so you can separate live, exploitable keys from dead or fake ones. Verification turns a giant list of "maybe" into a short list of "act now."

Verification also feeds prioritization. Once you know a key is live, the next question is what it can reach — its blast radius. A live key with admin access to production is an emergency; a live key for a throwaway sandbox is not. Triaging by impact is how you spend your remediation time well.

What to do when you find one

The moment you confirm a live leaked key, revoke or rotate it first, then clean up every copy. If it's in your repository history, follow our step-by-step guide to what to do when you commit a secret to Git. Then prevent the next one with push protection and continuous scanning.

Where Vooda fits

Doing all four steps by hand, continuously, across a real organization is a lot. Vooda AI runs this whole flow for you: it scans code and full history alongside 30+ non-code sources, applies AI detection that learns to suppress false positives, verifies which keys are live, and maps each one's blast radius — so your team sees the short list of keys that genuinely need action.