Live Secret Verification: Are Detected Credentials Still Active?
How 2MNY live-verifies detected API keys and tokens against their issuing provider with read-only checks — escalating confirmed-active credentials to critical and marking provider-rejected ones as rotated.
When 2MNY detects a credential (API key, bot token, service key) on a website you own, the finding used to end there: "a key-shaped secret was found." But the question that decides your response is whether the credential still works. A rotated key is cleanup debt; a live key is an active incident. The Live Secret Verification layer answers exactly that question — safely — during the scan.
How it works
After a secret-detection scanner (gitleaks battery, JavaScript secret extraction, open-directory secret scan) confirms a reportable secret, the engine checks the credential against the issuing provider's read-only authentication endpoint — the same call you would make to test your own token.
The raw secret value exists only in scanner memory for the duration of the check. It is never stored: findings keep the masked preview (first characters + asterisks). Provider responses are never stored either — only the verdict and HTTP status.
Verdict labels
| Label | Meaning | Effect on the finding |
|---|---|---|
| LIVE CREDENTIAL CONFIRMED | Provider accepted the credential | Severity escalated to critical |
| INACTIVE / ROTATED (PROVIDER-CONFIRMED) | Provider rejected it (401-class) | Severity lowered to low (hygiene debt) |
| UNREACHABLE AT CHECK | Provider API unavailable/rate-limited | Severity unchanged; re-checked later |
| (no label) | No safe check exists for this credential family | Original severity; reason documented in evidence |
Supported providers
Credentials from these families are live-checked: GitHub (classic + fine-grained PATs), Stripe (live/test/restricted keys), Slack, Telegram bots, OpenAI, Anthropic, Google/Firebase API keys, SendGrid, Mailgun (US + EU), npm, Discord, and Cloudflare API tokens.
Some families are deliberately not live-checked, with the reason recorded in the finding evidence:
- AWS access key IDs — cannot authenticate without the paired secret access key, which we never capture.
- Grafana API keys — instance-scoped; the issuing host is unknown.
- GitLab tokens rejected by gitlab.com — may belong to a self-hosted instance; a rejection is not definitive, so no "rotated" label is emitted.
- JWTs, private keys, generic secrets — no safe global verification endpoint.
Safety guarantees
- Read-only endpoints only — documented identity-introspection calls; nothing is sent, created, or modified on your account.
- Ownership-verified targets only — live checks run inside scanners that require proof of site ownership.
- The credential only travels to its own issuer, over verified TLS, from the scan engine.
- No secret storage — masked previews only, before and after verification.
- No false "invalid" verdicts — when a provider rejection is not definitive for a credential family, the platform reports "check not available" instead of guessing.
- Bounded — at most 5 live checks per scan, per-provider rate intervals, and a 10-minute verdict cache.
Where the labels appear
- Per-finding badges in customer and technical reports (PDF and HTML)
- The Evidence Verification summary band in report headers (live-credential and rotated-credential counts)
- Admin finding detail (provider, endpoint, HTTP status of the check)
- Admin scan pages and findings lists (LIVE CREDENTIAL / ROTATED chips)
Related capabilities
- Evidence-Verified Findings — post-scan re-checks of evidence URLs
- Scan Depth Tiers Explained — quick, deep and super-deep scanner mapping
- Secrets-manager exposure checks — HashiCorp Vault and Infisical instance detection (scanner
vault_secrets_exposure)