Do AI coding agents leak more secrets? GitGuardian's 2026 figures and a 10-minute checklist

According to GitGuardian's State of Secrets Sprawl 2026, commits assisted by Claude Code leaked a secret 3.2% of the time, against a 1.5% baseline across all public GitHub commits. The same write-up counts 24,008 unique secrets in MCP-related configuration files on public GitHub, 2,117 of them valid. These are real measurements, and they have limits: they describe public repositories, they compare against all commits, and GitGuardian itself warns against reading the gap as a tool failure. This guide reports the numbers as the source states them, explains why agents and their configuration files change where secrets end up, and gives a checklist that takes about 10 minutes.

What did GitGuardian report about secrets and AI coding agents?

GitGuardian sells secret detection, so it has data and an interest in the topic. Both are worth keeping in mind. We quote its own publications and add nothing to them: the State of Secrets Sprawl 2026 report page and GitGuardian's write-up of the findings. The figures below come from those two pages, as we read them on 18 October 2026.

A few points on how to read the table.

The 3.2% is a rate per commit. The write-up calls it a "secret-leak rate" and does not define the term further. The natural reading is the share of commits that contain a hardcoded secret, but the source does not spell it out.

The baseline is every public commit. It is not a baseline of careful human commits, and it is not a baseline of commits from people who use other AI tools. A difference between 3.2% and 1.5% can come from the tool, from the kind of project where people use it, from how much of the code gets reviewed, or from all three. The report does not separate them.

GitGuardian does not call this a tool failure. The write-up says the gap should not be read as a simple tool failure: people still decide what to accept, edit, ignore or push, and a user can override a warning or steer a model toward insecure code.

The MCP numbers are about public repositories. The 24,008 figure counts unique secrets found in MCP-related configuration files committed to public GitHub. The write-up adds that popular MCP setup guides often tell readers to put API keys directly in configuration files, command-line arguments or connection strings. We found no sample size, collection method or time window for this figure on either page. Treat it as GitGuardian's count, not as a rate.

Some details appear on only one page. The report page did not show the 3.2% and 1.5% figures when we read it, only the "about twice" summary. The write-up has both, and the 2,117 figure. Where a number appears on one page only, the table names that page.

One more number from the same source changes what you do after a leak. GitGuardian retested credentials that were valid in 2022 and found that more than 64% still worked in January 2026. A leaked key does not expire because nobody noticed it.

Why do coding agents change where secrets end up?

An agent is a program that reads files, runs commands and sends parts of what it sees to a model provider. That is its job. For secrets, three things follow.

Agents read the files where people keep secrets. A .env file is the standard place for local keys, and an agent that explores a project to understand it will often open that file. The values then travel with the rest of the context to the provider. A rule such as .gitignore keeps a file out of a commit, but it is not a promise about what an agent may read, and each agent handles that differently.

Agents write configuration. When an agent adds an MCP server, sets up a test or wires a database, the quickest working change is often a literal value in a file. The next commit includes it. A person might have paused at that point. An agent asked to make the test pass may not, and a person reviewing a long diff may not notice one more line.

MCP configuration puts credentials in a new kind of file. An MCP server has to authenticate to something, and its configuration file is where the settings live. Setup guides that show a key inside the file make that the easy path. These files are also easy to commit: they sit in the project folder, often as .mcp.json, next to the code.

None of this means the tools are careless. A new actor now touches the files where secrets live, at speed, and the older safeguards were designed around a person typing a commit. The safeguards that still work are the ones that do not depend on anyone remembering.

What can you do in 10 minutes?

Each step has a time. If you do only the first two, you have dealt with the exposure that is already real.

1. Find what an agent can reach (2 minutes)

From the folder you work in, run:

npx -y zn-gate reach

It lists the names, never the values, of the secrets in your .env files, the credential files in your home folder, environment variables with a secret-looking name, and findings in MCP servers and agent settings. It is read only and sends nothing. If you prefer not to use a tool for this, search your project for .env, .mcp.json, .cursor/, .codex/ and .claude/ and open each one.

2. Rotate anything that was exposed (3 minutes)

If a real key was ever in a committed file, a pushed branch, a chat, or a configuration you shared, treat it as exposed. Create a new key at the provider, update the places that use it, and revoke the old one. Do this even if the repository is private: GitGuardian reports that internal repositories are roughly six times more likely than public ones to hold hardcoded secrets, and a private repository can become public or be copied.

Rotate first and tidy afterwards. Deleting the file or rewriting git history does not help if someone already has a copy of the key.

3. Move secrets out of MCP configuration files (2 minutes)

Replace each literal value in an MCP configuration with a reference to something outside the file. Which form works depends on your client, so check its documentation. Many clients let you pass a variable by name or expand an environment variable in the entry, and a vault or a secret manager can supply the value at launch. The goal is that the file in your repository contains no value that works on its own.

This is the shape of the change, with an example name and no real value:

{
  "mcpServers": {
    "example-service": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"],
      "env": { "EXAMPLE_API_KEY": "<set in your environment, not here>" }
    }
  }
}

If a key was already in the file and the file left your machine, go back to step 2.

4. Add a secret scanner before commits (2 minutes)

A scanner that runs on every commit catches the mistake that gets past everything else. Two common options are ggshield, from GitGuardian, and gitleaks, which is open source. Both can run as a pre-commit hook. Their installation commands change between versions, so follow the current instructions in each project's README. Pick one, run it once over your existing history, and turn it on for new commits.

This does not replace the other steps. A commit scanner sees what you commit. It does not see what an agent reads from your disk and sends to a model.

5. Restrict what the agent can read (1 minute, plus the prompts)

Use the agent's own settings first: permission rules and ignore files exist in most agents, and the exact behavior differs. Then, if you want a layer that works across agents, zn-gate is one option. It is open source (MIT), runs on your machine and needs no account.

npx -y zn-gate init
npx -y zn-gate env shadow .env
npx -y zn-gate check

init finds Claude Code, Codex CLI, Cursor and OpenCode, shows the setup for each one and asks before each change. env shadow .env moves the real values into a local encrypted vault and leaves markers such as __ZN_STRIPE_KEY__ in the file. The first time, run npx -y zn-gate unlock to create the vault. check tests the setup with a fake secret in a temporary folder and tells you if an agent is not protected. Run init in your own terminal: when an agent or a script runs it, it only prints the steps.

Then review what this project configures your agents to trust:

npx -y zn-gate audit
npx -y zn-gate scan .

npx -y zn-gate audit reviews .claude/, .mcp.json, .codex/, .cursor/, hooks, AGENTS.md and CLAUDE.md, plugins and skills. Add --include-home to check the settings in your home folder too. zn-gate scan looks in configuration files for leaked secrets and reports them with the next step. The same checks can run in CI as a GitHub Action.

What do these steps not cover?

• Keys outside your machine. A key saved in a third party's console, a CI variable or a chat is outside what a local tool can protect. Limit those keys with spend caps and short lifetimes.
• Secrets your tools do not recognize. Scanners match known formats and names. A custom token with no recognizable shape can slip past any of them, zn-gate included. Naming variables clearly helps.
• Agents and editors that zn-gate supports only in part. Support differs by agent. The compatibility table lists what each one allows. In some editors zn-gate works only as an MCP server that the agent chooses to call, which is not automatic protection.
• What the numbers mean for you. The GitGuardian figures describe public GitHub. Your private repositories may look different, in either direction.

zn-gate is one of several ways to do step 5, and it is the one we build. The other steps do not depend on it. Rotation and scanning are what close the exposure that already exists.

Where can you read more?

The two GitGuardian pages cited above are the primary sources. For zn-gate details, see the docs on reach and on the scrubber and secrets vault. For the basics of keeping a .env away from an agent, read how to stop Claude Code, Codex CLI, Cursor and OpenCode from reading your .env with one command. To see how a hook can be bypassed and how that was fixed, read how a coding agent could read your .env file indirectly. zn-gate is MIT-licensed, runs locally and needs no account: GitHub and Install.