Tom Hundley
🤖 Ghostwritten by GPT 5.4 · Fact-checked & edited by Claude Opus 4.6
The best time to catch a leaked API key, token, or password is not after it lands on GitHub. It is the half-second before the commit leaves a developer's laptop. Pre-commit hooks turn secret scanning from cleanup into prevention — and in 2026, with AI-assisted coding accelerating how fast code moves from idea to commit, that shift matters more than ever.
GitGuardian's March 2026 State of Secrets Sprawl report found nearly 29 million secrets on public GitHub and noted that AI-assisted commits leaked secrets at roughly twice the human baseline. Even treating those figures as one vendor's methodology rather than an independent census, the direction is clear: secret exposure is widespread, and AI-assisted coding makes it easier to commit sensitive values by accident.
For developers moving fast with AI tools, the practical lesson is simple. Install a local scanner such as Gitleaks as a pre-commit hook, use TruffleHog in CI for broader coverage, and enable GitHub push protection as a server-side backstop. Prevention is cheaper than cure, and deleting a secret after commit is not a fix.
TL;DR: A pre-commit hook is a small automatic check that runs before Git records a commit, blocking secrets before they ever leave the laptop.
A pre-commit hook is just an automatic check tied to Git. When someone tries to commit code, the hook runs first. If it finds a problem, it stops the commit and shows a message explaining what needs attention.
For secret scanning, the hook examines the exact changes about to be committed and looks for things shaped like credentials:
This is different from scanning a repository days later. Once a secret has been committed, it can already exist in local history, remote history, forks, caches, mirrors, logs, code review tools, and copied patches. A secret that was exposed even briefly should be treated as compromised.
That is the prevention-versus-cure divide.
| Approach | When it happens | What it does | Risk level |
|---|---|---|---|
| Pre-commit hooks | Before commit is created | Blocks the bad commit on the laptop | Lowest |
| Push protection | During push to remote | Blocks or warns before code reaches GitHub | Lower |
| CI secret scanning | After code is pushed | Detects leaks in pipelines or pull requests | Higher |
| Manual cleanup | After exposure is discovered | Rotates keys, rewrites history, investigates impact | Highest |
For developers using AI coding tools, pre-commit hooks are especially useful because AI can generate plausible-looking configuration files, sample code, and environment variable blocks very quickly. Speed helps productivity, but it also increases the odds that a real token gets pasted into the wrong place and committed without a second look.
TL;DR: Gitleaks is a strong local pre-commit choice, while TruffleHog is often used in CI and repository scans to catch what local checks miss.
Two open-source tools show up often in practical secret scanning setups: Gitleaks and TruffleHog. They solve closely related problems but are typically used at different stages.
Gitleaks is widely used as a fast scanner for detecting secrets in code and Git history. In a pre-commit setup, it checks staged changes before the commit is finalized, making it a natural fit for local prevention.
What it looks for includes:
Because it runs locally and quickly, Gitleaks works well as the first gate.
TruffleHog is also a well-known secret scanning tool, but it is often used in CI pipelines or full repository scans. It can verify whether detected secrets are still active in some contexts, which is useful when teams want a second layer beyond local hooks.
| Tool | Best use | Strength | Limitation |
|---|---|---|---|
| Gitleaks | Pre-commit hooks, local scans | Fast local feedback before commit | Depends on local installation and adoption |
| TruffleHog | CI, repo scans, broader checks | Good second-line detection after local checks | Usually catches issues later than a hook |
| GitHub push protection | Server-side backstop | Stops or flags leaks at push time | Happens after the local commit already exists |
GitHub push protection and secret scanning should be treated as complements to local hooks, not replacements. If the first time a secret is caught is during push, the secret has already been committed locally.
That distinction matters operationally. A blocked pre-commit event usually means the secret has not entered Git history yet. A push-protection event often means the commit exists locally and must be handled more carefully.
TL;DR: If a secret was committed even once, deleting the line is not enough — rotate the credential because Git history may still contain it.
The most important operational rule in secret scanning is also the one developers skip under pressure: rotate, do not just delete.
Git is a history system. If a secret appears in a commit, removing it from the latest version of the file does not erase the earlier commit where it first appeared. The secret may still exist in:
That is why a leaked secret must be treated as compromised once committed. History-rewrite tools such as BFG Repo-Cleaner or git-filter-repo can help remove sensitive material from visible history, but history cleanup is remediation work, not proof of safety. The credential still needs rotation.
One path is a brief interruption. The other is an incident response exercise.
For developers using AI tools, this matters because AI assistants often make it easy to generate .env examples, config files, Docker Compose files, and integration snippets. The dangerous moment is not only when a real key is intentionally pasted in — it is also when an AI assistant mirrors a real value from terminal output, shell history, clipboard content, or an MCP config into a file that gets staged without scrutiny.
TL;DR: The minimum modern setup is a local pre-commit scanner, GitHub push protection, and credential rotation as a non-negotiable response to any committed secret.
If the goal is to prevent leaked credentials rather than clean them up later, the setup does not need to be complicated.
A practical baseline is Gitleaks as a pre-commit hook. Many teams use the pre-commit framework to manage hooks consistently across repositories.
A simple .pre-commit-config.yaml looks like this:
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.21.2
hooks:
- id: gitleaksThen install the hook:
pre-commit installVersion numbers change over time, so check the Gitleaks releases page for the current documented release rather than copying an old snippet blindly.
GitHub push protection is the server-side backstop. If a secret gets past the laptop, push protection can still stop or warn on the push before the code lands remotely.
Local hooks and push protection are not duplicates. They protect different moments:
Every developer should know the rule: if the hook fires because a real credential was staged, remove it from the code and rotate the credential if it was ever committed or exposed. Do not assume deleting the line is enough.
Here is a prompt for an AI coding agent that handles both setup and education:
Set up a pre-commit hook in this repository that scans staged changes for secrets using Gitleaks. Use a standard, maintainable setup and explain each file you add or modify. After setup, explain in plain English what happens when the hook detects a possible secret, including the correct response if a real credential was already committed or pushed. Be explicit that the right fix is to rotate the credential, not just delete the line, because Git history may still contain it. Also suggest how to add GitHub push protection as a server-side backstop.
That prompt does two useful things: it asks the agent to implement the control, and it forces the agent to explain the operational response instead of stopping at installation.
A pre-commit hook is a small automatic check that runs when Git is about to create a commit. If it finds a problem — such as a string that looks like an API key or password — it stops the commit before that secret enters Git history. The hook runs entirely on the developer's machine, so no code leaves the laptop until the check passes.
Gitleaks is a strong local baseline for pre-commit hooks because it is fast and works well on staged changes. TruffleHog is commonly added in CI or periodic repository scans as a second layer. The two are complementary rather than interchangeable: Gitleaks catches secrets before commit, while TruffleHog can verify whether detected secrets are still active and scan broader history.
No. If the secret was ever committed, Git history still contains the earlier version of the file with the secret in it. Anyone with access to the repository — or any fork, mirror, or cached copy — could retrieve it. The credential should be treated as compromised and rotated immediately.
Push protection works on the server side when code is pushed to a remote platform such as GitHub. It catches secrets that slipped past local hooks, perhaps because the developer did not have hooks installed. However, by the time push protection fires, the commit already exists in local Git history, which is why pre-commit hooks remain the preferred first line of defense.
AI tools generate large amounts of code, config, and integration scaffolding quickly, which increases the chance that a real token is pasted, echoed, or reused without careful review. They may also pull values from context windows that include terminal output or clipboard content. GitGuardian's March 2026 report found AI-assisted commits leaked secrets at roughly twice the human baseline.
The most effective secret scanning strategy in 2026 starts before the push, before the pull request, and ideally before the commit is even created. Server-side checks are improving, but the decisive control is still the local one: a pre-commit hook that catches the mistake in the instant before it becomes history. As AI-assisted development accelerates software creation, the teams that avoid credential incidents will be the ones that make prevention automatic and treat every committed secret as already compromised.
Discover more content: