Truffle Security announced the Secrets Revocation Program on November 4, 2026. It is a free initiative in which issuers revoke customer secrets that Truffle finds exposed in public code, packages, container images and AI datasets. Those secrets include API keys, tokens and other credentials. The program is available now in early access to any organization that issues credentials. Everything below about the program's results comes from Truffle Security's own research and announcements. None of it has been independently audited.
How the program works
Truffle's research team scans GitHub, GitLab, Docker Hub, npm, PyPI, Hugging Face, Android apps and Firefox add-ons. The company says it has scanned more than 20 petabytes so far this year. TruffleHog tests every key it finds, so participants are only notified when a finding is live.
Issuers can take part in one of two ways:
- Webhook delivery. The issuer gets exposed customer secrets through a webhook as they are found. Its own team manages revocation and any customer follow-up.
- Revocation endpoint. The issuer provides an endpoint, and Truffle Security automatically revokes exposed secrets as it finds them.
Both options require participants to revoke disclosed secrets within 14 days of disclosure. That deadline matters most for the webhook route, because the issuer is the one doing the revoking.
BleepingComputer reports that sixteen issuers have already joined, including Hugging Face, Notion, Vercel, Resend, RubyGems and Twilio. Truffle's blog also notes how this fits with existing programs. Some sources sit outside GitHub's secret-scanning partner program, which covers public GitHub repositories and npm. For issuers already partnered with GitHub, this program adds another route to exposed customer keys.
Why Truffle says notification fails
The company's central claim is that notifying owners doesn't work well. In its words, 81% of the keys it reported last year still worked six months later. Separately, in August 2026 it re-verified 64,024 leaked AWS keys and found that 88% remained active. The press release adds that the median live key was about five years old. It also says 768 keys granted full administrative control of a corporate AWS account. Another 929 had already been flagged under AWS's compromised-key quarantine policy, in some cases more than three years earlier, and were still live.
Truffle also points to AI coding tools. BleepingComputer quotes the researchers as saying they have found 2,655 working keys in AI coding tools' config files since January 2025. They describe this as a non-existent problem the year before. That is a company finding, not an industry-wide measurement.
The Google Cloud comparison
Truffle's strongest evidence for revocation over notification is Google Cloud. Google's own announcement confirms the policy change. Starting June 16, 2024, exposed service account keys detected in places like public repos are automatically disabled by default. Customers can opt out. Google's documented settings are:
DISABLE_KEY: the key is disabled automatically and project owners and security contacts are notified.WAIT_FOR_ABUSE: Google doesn't proactively disable the key, though it may still do so if the key is used in ways that harm Google Cloud.
Under the second setting, Google still sends the notification email either way.
Truffle's outcome numbers come from its July 2026 analysis of The Stack v3, a public snapshot of GitHub. It says 72% of keys committed in the year before the change still authenticated, against 11% of keys committed in the year after. Google's documentation supports the date and the options, but not Truffle's percentages. This is also an observational comparison. It doesn't prove the policy alone caused the whole gap. The 11% residue is consistent with opt-outs and with leaks Google never detected.
Truffle also says issuers that revoke on report, such as Hugging Face, GitHub, Anthropic, OpenAI and Slack, had no more than 2.2% of their exposed keys still valid. Read that as a rate within Truffle's dataset, not a measure of each issuer overall.
What this means for developers and IT teams
The practical lesson holds whatever you think of Truffle's marketing. Deleting a secret from a repository doesn't invalidate it. Copies persist in Git history, container layers, package archives and datasets. Only the issuer, or you, can make a leaked credential stop working.
For teams that ship code, a sensible checklist looks like this:
- Treat any credential that reached a public repo, image, package or app as compromised, and rotate it. Don't just delete it.
- Scan Git history, container images and CI logs, not only the current branch.
- Check AI coding assistants' local settings files. Truffle says it found a working GitLab token in a published Docker image's
.claude/settings.local.json. - Keep security contact details current with your cloud and SaaS providers. Google notes that it notifies project owners and listed security contacts.
- Where Google Cloud is in use, check whether your organization policy
constraints/iam.serviceAccountKeyExposureResponseis set to opt out. - Prefer short-lived credentials or federated authentication over long-lived keys wherever the platform allows.
Caveats
- Truffle sells TruffleHog Enterprise, so the program also showcases its commercial scanning and verification capability. The free tier is real, but the framing is the company's.
- The program only covers credentials Truffle's scans find. Google likewise cautions that its own detection isn't guaranteed.
- Automatic revocation can break production workloads. Google acknowledged that risk when it introduced default disabling.
- The announcement doesn't say how many of the 1.4 million credentials have actually been revoked so far.
Bottom line
The shift from notifying key owners to revoking the keys is sound, and the Google Cloud policy date and options are documented. The headline numbers, though, are Truffle's. Watch how many more issuers join, and whether Truffle ever publishes revocation counts that others can check.