Can You Prove a Leaked API Key Was Sold?
A public leak, a valid key, and evidence of misuse are different findings. Here is how to investigate each without claiming a sale you cannot prove.
On this page(4)
Table of Contents
A leaked API key is a security incident. It is not, by itself, evidence that the key was sold on a marketplace or used by an attacker. The earlier version of this article blurred those claims and labeled a designed title card as a marketplace screenshot. We removed that image and rewrote the article on October 4, 2026.
What each piece of evidence can tell you
Exposure: a key appears in a public repository, deployed JavaScript, a log, or another accessible source. Record the exact location, first observed time, owner, and key type. Preserve only the minimum evidence needed for investigation; do not paste the credential into a ticket or screenshot.
Validity: a provider-supported check may tell you whether a credential is active. GitHub lists which secret types support validity checks; generic patterns do not. A valid result increases urgency, but does not prove anyone else saw or used the key.
Permissions and use: ask the issuer what the key could access, then inspect the relevant audit logs and usage metrics. For AWS, CloudTrail event history can be searched by access key ID for recent management events in a Region. Its default event history does not include data events. No matching event is not proof that the key was never used: check the logging scope, retention, Regions, and service-specific records.
Sale: a marketplace listing, transaction record, or independently verified intelligence would need its own provenance and a defensible match to the credential. A public leak, valid key, or suspicious API call alone does not establish a sale. We have no evidence here that the keys discussed in the earlier article were traded.
What to do when a key is exposed
1. Identify the issuer and owner. Restrict access to the investigation record. Treat a potentially active key as compromised while you determine the scope.
2. Revoke or rotate it through the issuer, then update dependent services and check for failed calls. Removing a secret from a Git commit does not undo exposure; GitHub advises revoking or rotating first.
3. Search copies in repositories, build artifacts, deployed bundles, logs, and other approved sources. Review permissions and activity from the exposure window. Keep observed facts, assumptions, and unknowns separate in the incident record.
4. Restrict replacement keys to the applications and APIs that need them. For Google Cloud API keys, use application and API restrictions where supported, and rotate keys as part of ongoing management.
Where Cremit fits
Cremit helps teams find exposed credentials in supported sources and approved external assets, check supported credential types, and route findings to owners. Its AWS access key and Google Cloud API key analysis helps prioritize review. It does not monitor dark-web marketplaces, prove a sale, or automatically rotate a key. Issuer logs and incident evidence remain necessary to establish what happened.
Primary references
GitHub Docs — Supported secret scanning patterns and validity checks
GitHub Docs — Removing sensitive data from a repository
AWS CloudTrail — Viewing event history with the CLI
Read next
Orphaned API keys after offboarding: what the evidence shows
An active key linked to an inactive author is a lead. Check the directory, source, issuer, and current service owner before deciding what happened.
The machine access behind an exposed API key
An exposed key is a lead. Connect it to its issuer, principal, permissions, workload, and owner before closing the access path.
The "Out of Scope" Loophole: Why Bug Bounties Look Away From Credential Exposure
An organization's core credentials sat in public repositories for years. The security industry's answer: "Out of scope."
Get the next one in your inbox
Monthly NHI security brief from Cremit. One email, high signal.