Leaked credentials are one of the most common root causes of breaches, and they leak in remarkably mundane ways: a debug log accidentally checked into git, a Slack message with a copy-pasted .env file, a support ticket that includes a full request including its Authorization header. Most credential formats are structured enough to detect with a regex — cloud providers, payment processors, and version-control hosts all use recognizable prefixes specifically so their own tooling (and security scanners) can find them.
AWS access keys start with AKIA (or ASIA for temporary session keys) followed by 16 more characters. GitHub personal access tokens start with ghp_, fine-grained tokens with github_pat_. Stripe keys start with sk_live_ or sk_test_ — the live/test distinction in the prefix itself is exactly why a scanner should treat a leaked sk_live_ key as categorically more urgent than a leaked sk_test_ one. Private key material is even more distinctively shaped: a PEM block starts with a literal -----BEGIN header naming the key type.
Detecting a shaped secret is the easy half of the problem — high-entropy strings without a recognizable prefix (a raw 256-bit key rendered as hex or base64, for instance) require a different technique: measuring Shannon entropy across a sliding window and flagging runs that are 'too random to be English' but also too long to be a coincidental match. This catches secrets that don't announce themselves with a vendor prefix, at the cost of some false positives on things like hash outputs and UUIDs, which is why entropy findings are surfaced as lower-confidence than prefix matches.
This scanner runs automatically on every input — you don't have to select 'secrets' as a mode — because the whole point is to catch a credential before you paste it somewhere it can't be un-pasted from. It checks the input against a maintained set of vendor-prefix patterns plus a sliding-window entropy check, and everything happens in memory in your browser; nothing you paste here is ever transmitted anywhere.
Edge cases worth knowing
- A revoked or clearly fake example key
- AKIAIOSFODNN7EXAMPLE is AWS's own published example access key ID, used throughout their documentation. It matches the AWS key pattern structurally and is flagged the same as a real key — the scanner can't know a key was revoked or was always fictional, so treat every positive match as worth verifying rather than dismissing.
- A JWT or base64 blob containing an embedded secret
- Because decoded output is fed back through every matcher, a base64 string or JWT payload that contains an API key in plaintext gets scanned too — the secret doesn't have to be the literal top-level input to be caught.
- A high-entropy string that isn't a secret
- Hash digests, UUIDs, and compressed data can trip the entropy heuristic since they're also 'too random' to be natural text. Entropy findings are intentionally lower-confidence and worth a manual look rather than an automatic incident.
Common mistakes
- Pasting a full .env file or config block into a chat tool, ticket, or AI assistant without scanning it for credentials first.
- Assuming a masked or partially-redacted key (showing only the last four characters) is safe to share when the prefix alone can sometimes identify the account or environment.
- Rotating a leaked key without also checking access logs for usage during the exposure window.
- Treating test-mode keys (sk_test_, similar sandbox prefixes) as equally low-risk in every context — a test key can still leak information about your integration and account structure.