My regex secret scanner once blocked a commit because a test file contained the string sk_test_EXAMPLE_KEY_DO_NOT_USE. The same week, a colleague on another project committed a real Etherscan API key inside a hardcoded URL, and no scanner caught it because it didn't match any known key format. That pair of failures sums up regex-based secret scanning: loud where it doesn't matter, quiet where it does.
The standard fix is an allowlist file that grows forever, plus developers who learn to type git commit --no-verify from muscle memory. Once people bypass the hook by habit, the scanner is decoration.
So I tried something different: keep the regex scanner, but add a small local LLM as a second opinion. The regex stage decides what's worth looking at. The model decides whether it's actually a secret. Only flagged files ever reach the model, so the hook stays fast, and because the model is Ollama running on my own machine, no staged diff ever leaves my laptop. That last part is non-negotiable for me, sending your possibly-secret-containing diffs to a cloud API to check for secrets is a joke that writes itself.
The architecture in one paragraph
Stage 1 is a deliberately paranoid regex pass over staged changes: high-entropy strings, known key prefixes, PRIVATE KEY blocks, suspicious variable names. Stage 2 sends each flagged hunk, with a few lines of surrounding context, to qwen2.5-coder via Ollama with a classification prompt. Verdict SECRET blocks the commit, FALSE_POSITIVE lets it through. Most commits never trigger stage 1 at all, so most commits pay zero latency.
