Forkbench

Blog

AI-assisted code leaks secrets at twice the rate of human code

GitGuardian's 2026 report reveals that AI-assisted commits leak secrets at roughly double the rate of human-written code, exposing credentials through entirely new surfaces.

· updated 1 October 2026

Quick Answer

According to GitGuardian's State of Secrets Sprawl 2026 report, AI-assisted commits leak secrets at approximately twice the baseline rate of human-written code. Specifically, claude (Claude Code) commits showed a 3.2 percent leak rate compared to a 1.5 percent baseline. This increase is driven by agents exposing credentials in new surfaces like MCP configuration files, session caches, and agent instruction files, which traditional security scanners fail to reach.

The numbers behind the AI secret leak rate

GitGuardian's State of Secrets Sprawl 2026 report analyzed millions of public commits to quantify the impact of AI coding tools on credential exposure. The findings establish a clear baseline: human-written code leaks secrets at a rate of 1.5 percent. When commits are generated or assisted by AI agents, that rate jumps to roughly double the baseline. The data shows that AI infrastructure credentials, such as those for orchestration, RAG pipelines, and vector databases, are leaking five times faster than core model-provider keys.

The researchers specifically measured commits tied to claude (Claude Code), finding a 3.2 percent secret leak rate. This represents a significant deviation from historical norms, contributing to an 81 percent year-over-year increase in leaked secrets tied to AI services. Over 1.27 million such leaks were recorded in 2025 alone. The methodology focused on public repositories, meaning these numbers represent only the visible portion of a much larger problem affecting private codebases.

Why agents leak at scale rather than on purpose

AI agents do not leak secrets maliciously or intentionally. They leak credentials because they operate at scale and often lack contextual awareness of security boundaries. When an agent debugs a complex issue, it might echo environment variables in its logs or outputs to provide a comprehensive trace. If those variables contain production keys like ANTHROPIC_API_KEY or OPENAI_API_KEY, the secret is immediately exposed in the debugging artifact or terminal scrollback.

Agents also frequently pull entire configuration files, including environment files like .env, into their context windows to understand the local setup. When the agent subsequently generates code or writes a commit message, it might inadvertently include those ingested secrets. The automation of the commit process exacerbates this issue. While a human might review a diff and catch a hardcoded token, an autonomous agent committing changes in bulk will push the secret without hesitation.

The blind spots in traditional secret scanning

Traditional secret scanners are designed to monitor source code repositories and standard configuration files. However, AI workflows introduce entirely new surfaces that these tools miss. For instance, researchers found 24,008 unique secrets exposed in public Model Context Protocol configuration files like claude_desktop_config.json. These files often contain live credentials required for agents to connect to local tools, but they are rarely covered by legacy scanning policies (see our deep dive on MCP configuration secrets).

Beyond these configurations, agents leave sensitive traces in session caches located in hidden system directories like ~/.claude/ or ~/.codex/. Developers are also increasingly hardcoding live credentials directly into agent instruction files like .cursorrules and CLAUDE.md to steer the agent's behavior. Because these files are often treated as documentation or local preferences, they bypass standard security checks. Even shell history written by agents executing commands can silently persist sensitive tokens.

Why ignoring files fails to protect secrets

A common misconception is that adding sensitive files to an ignore list like .gitignore is sufficient to protect secrets from AI agents. This assumption fundamentally misunderstands how local agents operate. Ignore files instruct the version control system not to track specific paths, but they do not prevent a local process from reading them. AI agents running on a developer's machine can and will read locally ignored files like .env to gather context, meaning secrets in those files remain fully accessible to the agent (see why .gitignore is not a security boundary).

Security controls that rely on pre-commit hooks are often bypassed in agent workflows. When an agent commits code autonomously, it may skip standard hook execution (such as passing --no-verify), allowing secrets to slip into the repository unhindered. Some integrated development environment settings synchronize local configuration files to the cloud automatically. If an agent writes a secret to a local preferences file, that secret can be synchronized across devices and potentially exposed, regardless of its tracking status.

Implementing the credential brokerage pattern

The only reliable way to prevent secret leaks across all these unmonitored surfaces is to ensure the secrets are never written to disk or exposed to the agent's context in the first place. This is achieved through a credential brokerage pattern. Instead of placing long-lived static keys in .env files or tool configurations, developers use a centralized broker that dynamically injects short-lived, scoped credentials directly into the required processes exactly when they are needed.

Under this architecture, local files never contain actual secrets. They contain references or placeholders. When the agent executes a command or connects to a tool, the broker intercepts the request and provides temporary access. Forkbench's Vault is one approach that implements this pattern, acting as an intermediary to manage and inject credentials safely using local destination-bound proxies and macOS Seatbelt sandboxing. By removing the underlying value from the files themselves, the risk of a leak is eliminated even if an instruction file or session cache is accidentally published (see how to stop coding agents reading your .env file).

The persistent challenge of child process environments

While credential brokerage significantly reduces the attack surface, it is important to acknowledge the inherent limits of any security model. If an AI agent executes a child process that requires access to an unbound secret, that secret must ultimately be present in the child process's environment via setenv() and execvp(). The agent, as the parent process orchestrating the execution, could theoretically inspect the environment of the child process it spawned.

Security tools can restrict how and when secrets are requested, and they can ensure credentials are short-lived, but they cannot completely hide a secret from a process that legitimately needs it to function. If an agent is granted the authority to run a script that connects to a production database, the agent will have access to the temporary token used for that connection. The goal of modern secret management is not to achieve impossible isolation, but to constrain the blast radius and prevent static keys from proliferating across files.

Related: How to stop an agent reading your .env file, Why .gitignore is not a security boundary, 24,000 secrets found in MCP config files

Frequently asked

Keep reading

Sources