Leaks are usually mundane, not malicious
The most common way an API key ends up exposed isn't a sophisticated attack — it's a developer committing a config file to a public repository, pasting a debugging session into an AI chatbot without redacting the key first, or leaving credentials sitting in a log file that gets shared or archived somewhere less carefully controlled than the original system.
Why each provider's key has a recognizable shape
Most API providers issue keys with a distinctive, consistent prefix and format specifically so that automated scanning tools (including GitHub's own secret scanning) can detect them reliably: OpenAI keys start with sk- or sk-proj-, Anthropic keys with sk-ant-, AWS access key IDs with AKIA, GitHub tokens with ghp_, and so on. This consistency is what makes genuine pattern-based scanning — rather than just eyeballing a file — both possible and reliable.
Why pasting into an AI chatbot is a specific, growing risk
A common, easy-to-overlook path: pasting a code snippet or config file into an AI chatbot for debugging help, with a live API key still embedded, because redacting it felt unnecessary in the moment. Once submitted, that key should be treated as compromised, regardless of the platform's stated data retention policy, simply because it was transmitted outside your controlled environment.
Why a matched key should be rotated, not just removed
Deleting a leaked key from a file, or removing a public commit that exposed it, doesn't undo the exposure — if the content was ever public or transmitted anywhere outside your control, even briefly, the safest assumption is that the key has already been seen and should be rotated (revoked and reissued) rather than simply hidden going forward.
What a genuine scan catches that a visual check misses
A long file, a verbose log, or a large diff makes visually scanning for a specific 40-character token impractical and error-prone. A pattern-based regex scan checks every character of the pasted content mechanically against known key formats, catching a leaked credential buried in output a human reader would likely skim past.
Why this needs to run entirely locally
Given that the entire purpose of this tool is scanning text that may contain real, live credentials, sending that text to a server for processing would defeat the point — everything needs to be checked client-side, in your own browser, with nothing transmitted anywhere, which is exactly how a tool handling potentially sensitive credential-adjacent content should work.
Frequently Asked Questions
Rarely through a sophisticated attack — the most common paths are committing a config file containing a real key to a public repository, pasting a debugging session into an AI chatbot without redacting the key first, or leaving credentials in a log file that later gets shared or archived somewhere less controlled.
Providers deliberately issue keys with consistent, distinctive prefixes and formats (like OpenAI's sk- or AWS's AKIA) specifically to make automated secret scanning reliable — both by the provider's own tooling, platforms like GitHub's secret scanning, and dedicated scanning tools.
Treat it as compromised regardless of the platform's stated data retention policy. Once a credential is transmitted outside your controlled environment, even to a reputable AI provider, the safer assumption is that it should be rotated rather than trusted to remain private.
No. If the content was ever public or transmitted anywhere outside your control — even briefly, even in a commit that was later removed — the key should be rotated (revoked and reissued), since deleting the exposed copy doesn't undo whatever access already occurred.
No — the scan runs entirely in your browser using regex pattern matching. Nothing you paste is transmitted anywhere, which matters specifically because the content being scanned may contain real, live credentials.