Using gitleaks rules to detect API keys in your own outbound traffic

2026-08-16 · 3 min read

If you’re building any tool that detects secrets in text — a DLP layer for AI agent traffic, a log scrubber, a commit scanner — you will eventually face the same problem: hand-writing regexes for every real-world key format is a losing game. API keys come in dozens of families, each with its own prefix, length, and character set, and they change over time.

The shortcut is gitleaks.

What gitleaks gives you

gitleaks is the standard secret scanner, and its value as a component is the rule set: hundreds of formats for real key types — AWS access keys, JWTs, GitHub tokens, Stripe keys, private key blocks, and a long tail of service-specific formats — each expressed as a regex with metadata.

Reusing that rule set in your own tooling gets you:

  • Battle-tested formats. The rules are refined against real-world findings, not written from documentation.
  • Coverage without effort. Hundreds of key families covered from day one, including ones you’ve never heard of.
  • Maintainability. The community updates the rules; you stay in sync instead of maintaining regex archaeology.

License-wise, gitleaks is MIT — you can bundle the rules with attribution (which, for a Go project, means the NOTICE file gets a bit longer).

The false-positive problem

A raw rule set fires on a lot of legitimate text. Documentation placeholders (<redacted>, YOUR_API_KEY), example configs, and test fixtures all match key formats. Three mitigations, in order of importance:

  1. Entropy filtering. A string that matches a key format must also be high-entropy enough to be a real key. Placeholders and examples are low-entropy; real keys are effectively random. A Shannon entropy threshold (default around 3.5, overridable per rule) kills the majority of false positives.

  2. Keyword pre-filtering. Run a cheap keyword scan (sk-, AKIA, Bearer, eyJ) before the regexes, so the expensive matching only runs on suspicious lines.

  3. Rule disabling. Some rules are inherently noisy — the generic catch-alls. A pattern_disabled list lets you silence specific rule IDs per installation instead of fighting them.

Using it in a DLP layer for agents

For AI agent traffic, the scan has to happen at the egress point: every outbound LLM request passes through a proxy that runs the pattern pipeline (keyword → regex → entropy) and masks matches in place. Because the rule set is bundled, the binary works offline — no rule downloads at runtime.

There’s a subtle design point: the same rule set should power both the live DLP and the retroactive scrubber. If a key family is caught at the egress, it should also be erasable from session databases and logs — one rule set, two enforcement points.

trustless does exactly this: 40 gitleaks-derived rules bundled via go:embed (MIT, attributed), a keyword → RE2 → entropy pipeline, pattern_mode log/mask, per-rule disabling, and hot reload — shared between trustless serve (outbound DLP) and trustless dlp scrub (retroactive). The implementation details are in the command reference.

The rule set is the boring part that everyone gets wrong. Borrowing the battle-tested one leaves you free to focus on the part that matters: what to do when a hit fires.

← Blog