"Found a key" is not "live leak"
Regex-based secret scanners are good at spotting things that look like keys. They flag old test keys, rotated credentials, example values from documentation and real live secrets all the same way. If you treat every match as an emergency, alert fatigue sets in and the one finding that actually mattered gets buried. The only way to separate signal from noise is to ask the provider whether the key still authenticates.
The safe way to validate a key
The rule is simple: one read-only request, nothing that mutates or costs money. You are checking authentication, not exercising the API. Most providers have a cheap endpoint that returns 200 for a valid key and 401/403 for a dead one.
| Provider | Read-only check | Live signal |
|---|---|---|
| Stripe | Retrieve account / balance | 200 = live key |
| OpenAI | List models | 200 = live key |
| GitHub | Get the authenticated user | 200 = live token |
| Slack | auth.test | ok: true = live token |
| SendGrid | List scopes | 200 = live key |
A live result is also where the real severity shows up: a Stripe key that can read the account, or a token whose scopes let it write, is far more dangerous than a read-limited key. The validation step is what turns "possible secret" into a ranked, proven finding.
Do not leak it again while testing
Never paste a leaked key into a random "check my key" website, never log it, and never store it in your test output. Make the call from a controlled environment, keep the key in memory only, and redact it everywhere. Validating a secret should not create a second exposure.
If the key is live
- Rotate or revoke immediately at the provider — assume it is already compromised.
- Check the audit logs for unauthorized use while it was exposed.
- Purge it from git history, not just the latest commit — old commits keep the secret recoverable.
- Move it to a secret manager or environment variable so it never re-enters the codebase.
Automating it for AI-generated code
When code is written by AI assistants, new secrets land daily — and manual triage cannot keep up. Sintropyc's live-secret validator does this step automatically: it recognises the provider from the key's shape, makes a single read-only call, and reports live, revoked or unsupported — escalating confirmed live keys and quietly de-prioritising dead ones. The raw key never appears in the result or the logs.
Frequently asked questions
How do I know if a leaked API key is still active?
Make one read-only request to the provider — list the account or models endpoint. A 200 means the key is live and must be rotated now; a 401/403 means it is already revoked. Never test with a write or charge endpoint.
Is it safe to test a leaked API key?
Only with a single read-only call that changes nothing, and only on a key you own or are authorized to test. Do not paste it into third-party sites, log it, or store it — that just leaks it again.
What should I do if a leaked key is live?
Rotate or revoke it at the provider immediately, review the provider's audit logs for misuse, and remove the secret from your code and git history.