Stop Your AI Coding Agent Leaking API Keys for €0 With Gitleaks

AI coding agents write fast. They also paste your API key into a file without blinking. You review the diff, you are tired, you hit commit. Now the key is in git history. Forever.

The old way to handle this: read every diff carefully, or pay for a secret-scanning service. The new way costs nothing and takes 15 minutes. A free scanner sits between you and git, and says no.

What Gitleaks is

Gitleaks is an open-source tool that scans for secrets: API keys, passwords, tokens. It is MIT licensed, so you can use it in a business without paying anyone. It is a single binary. No account, no cloud, no data leaves your machine.

It can scan three things: the full git history of a repo, a folder of files, or text you pipe into it. That last option is useful when you want to check a snippet before you paste it anywhere.

One honest note. The project README says Gitleaks is feature complete, and future releases will be security patches only. The author has moved his focus to a new project called Betterleaks. So Gitleaks will not get new features. For this job, that is fine. It already does what you need.

Pricing

• Gitleaks CLI: free, MIT license.
• Pre-commit framework: free, open source.
• GitHub Action (Gitleaks-Action): available for CI. Check the repo for its current licensing terms before you use it at work.

Do the math: say you check agent-written diffs for secrets by hand, 10 minutes a day, 22 working days. That is 220 minutes, about 3.7 hours a month. At €20 an hour (my assumption, use your own rate) that is about €73 a month, €880 a year, spent on a job a machine does better. Gitleaks costs €0, and it does not get tired at 6 pm.

Step by step: set it up in 15 minutes

1. Install Gitleaks. On a Mac: brew install gitleaks. With Docker: docker pull ghcr.io/gitleaks/gitleaks:latest. On other systems, download a binary from the releases page, or build from source with Go using make build.
2. Scan what you already have. Go into your project and run gitleaks git -v. It reads your full git history and prints every secret it finds. Do this first. You may be surprised.
3. Scan files without history. Run gitleaks dir -v path/to/folder for a quick check of a folder, for example one an agent just generated.
4. Check a snippet. Pipe it in: cat some_file | gitleaks -v stdin.
5. Block bad commits. Install the pre-commit framework, then add a file called .pre-commit-config.yaml in the root of your repo with the Gitleaks repo and the gitleaks hook. The README example pins version v8.24.2, which may be old, so run pre-commit autoupdate to pull the latest version.
6. Turn it on. Run pre-commit install. From now on every commit runs through Gitleaks first. If it finds a secret, the commit stops.
7. Add your own rules (optional). Gitleaks reads a config file in this order: the --config flag, the GITLEAKS_CONFIG variable, the GITLEAKS_CONFIG_TOML variable, then a .gitleaks.toml file in the target folder. To keep the default rules and add yours, put useDefault = true under [extend].
8. Run it in CI. Use the Gitleaks GitHub Action so a pull request with a secret fails the check. This catches the case where someone skips the local hook.

If you really must skip the hook once, prepend SKIP=gitleaks to your commit command. Use it rarely. Most of the time the right fix is to remove the secret.

What to do when it finds a secret

This is the part people get wrong. Deleting the line from the file does not remove it from git history. If a real key was committed and pushed, treat it as stolen. Rotate it at the provider first. Then clean the code. Move the value into an environment variable or a secrets manager, and add the file that held it to .gitignore.

For your AI agent, add one line to its instructions: never write real credentials into files, always read them from environment variables. It will not catch everything, which is why the hook exists. Belt and braces.

Real use cases

• Solo founder with an agent writing code. The hook is your safety net while you move fast.
• Agency handing code to clients. Run a full history scan before delivery. A leaked key in a delivered repo is your problem.
• WordPress and automation builders. Config files, Make or n8n exports and plugin code are classic places for tokens. Scan the folder before you zip and share it.
• Old projects. Run the history scan on repos you made a year ago. Those are the ones with forgotten keys.

Limits and weak spots

• It uses rules. It finds known patterns well. A custom secret with an odd format may slip through unless you add a rule.
• False positives happen. Test strings and example keys can trigger it. Use an allowlist in your config for those.
• Feature complete means frozen. No new features are coming. Only security patches.
• It cannot undo damage. It prevents new leaks. Old leaked keys still need rotating.
• Local hooks can be skipped. That is why the CI check matters.

Alternatives

• Betterleaks. The new project from the Gitleaks author. Worth a look if you want something that will keep getting features.
• GitHub’s built-in secret scanning. Check which plans include it for your repositories.
• Manual review. Free, but slow, and people miss things at the end of a long day.

Source: Gitleaks

II

About the author

Ivan Ivanov

Founder ofHawkValue

If it doesn’t save you time or money, you won’t see it here

• Facts, not hypeEvery price and number is checked against the official source
• Always the real priceYou see what it costs before you click
• I say when it’s weakEven when it’s OpenAI or Google

All articles by Ivan →