Field guide

What that key prefix actually means

You found a string in a log, a screenshot, a commit diff or a support ticket and it looks like a credential. This page tells you which system it belongs to, what someone holding it can do, and what to do first. Written from the 30 detectors behind my Log Redactor — every shape below is one I had to recognise for real.

Cloud & API credentials · JWTs and auth headers · The ones with no prefix · Personal data · It leaked — now what

• ghp_4tR9wXqL2mVnB8sKdA1zYcE6HfJ0uP GitHub personal access token. The prefix is the whole reason you can act in seconds: it names the issuer, so you know whose settings page to open.
• AKIAIOSFODNN7EXAMPLE AWS access key id. Not itself the secret — it is the username half. The secret is the forty-character string that travels beside it, and that one has no prefix at all.
• sk-ant-api03-Hq2vTnE7yUpXm4LdRw0KzB9aCfGsJi Anthropic API key. Vendors keep adding prefixes precisely so that scanners like the one on this site can find them before an attacker does.
• a3f91c07e5b84d2690fe1cb7d842a05e No prefix at all. A database password, a session cookie, an HMAC secret. Nothing in the string says what it opens or who issued it, so nothing can tell you where to revoke it. This is the shape that hurts, and it gets its own section below.

Issuer prefix — the part that tells you who to call. Random tail — the part that is the secret.

Read left to right. If the highlighted part exists, this page can tell you what the key opens and where to kill it. If it does not, skip to the dangerous ones have no prefix.

01Cloud and API credentials

Severity is what an attacker gets by default, assuming the key has not been scoped down. Most of these can be restricted, and most people never restrict them.

02JWTs and auth headers

A string starting eyJ is a JWT. That prefix is not a vendor marker — it is simply what {" looks like in base64, so every JWT starts that way.

Authorization: Bearer <token> tells you how it is being sent, not what it is — the token after it may be a JWT, an opaque session token, or any of the keys above. Authorization: Basic <blob> is worse than it looks: the blob is plain base64 of user:password, so it is a password in transit, not a hash.

03The dangerous ones have no prefix

Every shape above is findable precisely because someone at that vendor chose to make it findable. Prefixes exist so that scanners — GitHub's, mine, yours — can spot the key before an attacker does. Several also carry a checksum, which is how a scanner tells a real token from a plausible-looking string.

The credentials that actually hurt are the ones with no such courtesy:

• An AWS secret access key is 40 characters of base64. There is no prefix. It is indistinguishable from a hash, an ID, or a chunk of minified JavaScript. The AKIA half is the detectable half — which is exactly why finding an AKIA in a log means you should go looking for its partner nearby.
• Database connection strings hide the password between ://user: and @host, where it is easy to miss while skimming.
• Your own service's tokens, unless you gave them a prefix. If you are designing an API today, give your tokens a distinctive prefix and a checksum. It costs you an afternoon and it is the single thing that makes leak-scanning work at all.

This is the honest limit of any pattern-based redactor, including mine: it finds the shapes someone made findable. Read the output; do not trust it blindly.

04Personal data, which is the other half

Logs leak people as often as they leak keys, and this half gets far less attention because nothing about it looks alarming.

• Email addresses — the most common real leak in a pasted stack trace, and the one nobody flags.
• File paths like /Users/jane.doe/ or C:\Users\jdoe\ — a stack trace usually names its author.
• Card numbers — a 16-digit run that passes the Luhn checksum is probably real. One that fails is probably an order ID. That check is the difference between a useful detector and a useless one.
• Public IPs — worth redacting. Private ranges (10., 192.168., 172.16–31.) are not; redacting them destroys the log for no benefit.

05It leaked. What to do, in order

1. Revoke first. Everything else is second. Deleting the message, force-pushing over the commit, or making the repo private does not revoke a key. It only makes it harder for you to find later. Assume anything pushed to a public host was scraped within seconds, because automated scrapers watch the public event firehose and they are faster than you.
2. Rotate, then update whatever was using it. In that order. A brief outage from a revoked key is a much smaller problem than a live key in a stranger's hands, and inverting the order is how "I'll revoke it after the deploy" turns into never.
3. Check the logs for use you did not make. CloudTrail, the GitHub security log, your provider's usage dashboard. This is the step that tells you whether you had a close call or an incident, and it is the one people skip.
4. Then clean up the history. Purging the commit or editing the ticket is hygiene, done after the key is already dead. Worth doing so the next person does not find it and assume it is live.
5. Tell whoever owns this where you work. If your organisation has a security team, this is theirs. Quietly rotating and saying nothing is how a near-miss stays invisible until it happens again.