Gitleaks

Secrets scanning · Any stack · stage: secrets-scan

Catch leaked credentials in agent worktrees before they ever reach a branch.

A secret that reaches your default branch is an incident even after you revert it. Coding agents make this failure mode more likely, not less: they paste example keys, wire up services with inline tokens, and commit fast. The Gitleaks plugin makes every agent session scan its own worktree — uncommitted changes included — before work is called done.

The stage runs Gitleaks in directory mode by default, precisely because agents usually have uncommitted edits at verification time that git-history scanners never see. Pass git as the second stage argument to audit full history instead.

What it installs

A secrets-scan test stage registered in .har/stages.json and added to verificationStages.
A root .gitleaks.toml extending the default ruleset with harness allowlists (skipped if your repo already has one).
A GitHub Actions workflow using the official gitleaks/gitleaks-action (skip with --skip-ci).

Requirements

The gitleaks binary (brew install gitleaks or a release binary) — the stage fails fast with an install hint when missing

Artifacts & evidence

JSON reports land under .har/artifacts/secrets-scan/ with secret values redacted — evidence of the finding, never a second copy of the secret.

Adapting it to your repo

Tune allowlists in .gitleaks.toml for fixtures and test keys; see .har/stages/GITLEAKS.md after install for allowlist and baseline guidance.
The stage exits distinctly for “leaks found” vs “tool error,” so a broken install never masquerades as a clean scan.

CI & compliance

The local stage is your shift-left layer: it keeps secrets from ever reaching the default branch. The CI workflow is the org-level layer — it produces the scanning evidence that compliance platforms such as Vanta or Drata ingest via their GitHub integrations. Keep both: local runs protect the branch, CI runs prove it to auditors.

Gitleaks Plugin install guide