Notifications
Clear all
Topic starter
02/08/2026 11:57 am
TL;DR: Byte-pair encoding token efficiency can filter candidate secrets more effectively than entropy after regex capture, showing higher precision and F1 on CredData while keeping recall at 98.6%, according to Aikido’s analysis. The result suggests secrets scanning teams should rethink rarity signals, not just randomness, when tuning detection pipelines.
NHIMG editorial — based on content published by Aikido: Rare Not Random: Using Token Efficiency for Secrets Scanning
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned".
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams reduce false positives in generic secrets scanning?
A: Start by removing credential types that are public by design, then add contextual checks for keys whose risk depends on platform permissions or surrounding code.
Q: Why do machine identities need different governance than human accounts?
A: Machine identities lack the human anchors that make access reviews reliable, such as managers, HR events, and predictable offboarding.
Q: What do security teams get wrong about entropy-based secrets detection?
A: They often treat entropy as if it measures secrecy, when it really measures unpredictability.
Practitioner guidance
- Tune post-regex thresholds against your own secret corpus Measure token efficiency and entropy on confirmed secrets from your repositories, then set thresholds separately for API keys, passwords, and tokens.
- Layer lexical exclusions after rarity scoring Add word-based filters for obvious non-secrets such as repeated dictionary terms, safe file types, and known benign patterns.
- Treat discovered secrets as identity artefacts Route confirmed findings into credential rotation and offboarding workflows, not just ticket queues.
What's in the full article
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- Exact benchmark methodology for CredData reconstruction and filtering
- Token-efficiency threshold tuning details for short secrets and newline-containing strings
- Full benchmark tables comparing token efficiency, entropy, and word filters
- Code-level implementation notes for the Betterleaks filter
👉 Read Aikido's analysis of token efficiency for secrets scanning →
Token efficiency for secrets scanning: does it beat entropy?
Explore further
02/08/2026 1:05 pm
Token efficiency is best understood as a rarity control, not a secrecy detector. The important shift here is from asking whether a string is random to asking whether it is statistically unusual in real code and language. That distinction matters because many exposed credentials are not perfectly random, and many random-looking strings are harmless. For practitioners, this reinforces the value of layered detection logic rather than reliance on a single numeric threshold.
A question worth separating out:
Q: How can teams decide whether a new secrets-scanning filter is actually better?
A: Compare precision, recall, and false-positive volume on labelled real-world data, then test by secret category. A better filter is one that preserves true positives while reducing triage noise enough for the team to act quickly. If analysts still cannot keep up, the control is not operationally useful.
👉 Read our full editorial: Token efficiency may outperform entropy in secrets scanning
