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

AI-assisted code leaks secrets at twice the rate of human code. Here is what the data shows.

In 2025, developers pushed 28.65 million new hardcoded secrets into public GitHub repositories. That is a 34% increase over the previous year, the largest single-year jump GitGuardian has recorded since they started tracking the metric.

The number was already bad before AI coding tools became mainstream. It got significantly worse after.

AI-assisted commits leak secrets at a 3.2% rate. The baseline for human-written code runs around 1.6%. The tools that are supposed to help developers write code faster are also helping them leak credentials at roughly double the rate.

This is not a theoretical risk. Moltbook's February 2026 breach started with a Supabase API key sitting in the site's front-end JavaScript, visible to anyone who opened a browser's network inspector. The key had full read and write access to the production database. 1.5 million authentication tokens and 35,000 email addresses were exposed. The founder later said he did not write a single line of code. An AI generated the entire platform, and somewhere in that process, a full-access database key ended up in client-side code that shipped to production.

The forgotten breach that set the pattern

Before the numbers, there is a pattern worth understanding. Secret leaks in AI-generated code are not a new category of attack. Attackers scanning GitHub for exposed credentials is a well-documented technique that predates every current AI coding tool. What changed is the volume, the speed, and the type of credential being leaked.

Credentials for AI platforms carry different value than a typical AWS key. An exposed OpenAI API key does not just cost money in unauthorized usage. It can be used to exfiltrate context from your agent's memory, impersonate your application in calls to the model, or extract data that your agent retrieved from connected systems. The combination of AI-service credentials and the MCP connections those services depend on creates a new attack surface that the 2021-era secrets sprawl playbook was not designed for.

What the numbers actually look like

The GitGuardian State of Secrets Sprawl 2026 report breaks down where the problem is concentrated.

AI-service credentials (API keys for OpenAI, Anthropic, Mistral, and similar platforms) increased 81% year over year, reaching 1.27 million detected leaks in 2025. This is the category growing fastest, for the obvious reason that AI tooling is new and the security practices around it are still being figured out. Developers get an API key, put it somewhere that works, ship the code, and move on. The key ends up in a config file, a .env that got committed, a Docker image layer, or in the case of Moltbook, plain JavaScript served to every visitor.

The MCP configuration problem is newer and underreported. GitGuardian found 24,008 secrets embedded directly in MCP configuration files on public GitHub. MCP setup guides, including some from official sources, routinely recommend putting API keys into config files as a quickstart step, without the caveat that those files should not be committed. Developers follow the guide, get things working, push the code, and the key is now public.

The remediation data is the most alarming part. 64% of secrets leaked on GitHub in 2022 were still active in 2026. Four years after being exposed, nearly two-thirds of those credentials had not been revoked. A leaked key that nobody rotated is an open door that has been sitting unlocked for years.

Why AI coding tools make this specific problem worse

The secrets leakage problem predates AI coding assistants. Developers have been committing API keys by accident for as long as there have been version control systems and API keys. What AI tools change is the rate and the scale.

When a human developer hardcodes a credential, it usually happens by mistake: they were testing something, forgot the key was still there, and committed the file. The context of how it got there is often visible in the git history. The developer knew they were putting a key in the file; they just forgot to remove it.

When an AI coding agent hardcodes a credential, it happens because the model optimizes for working code. If the task is "connect this service to the database," the model produces code that connects to the database. The most direct path to working code often involves a concrete value where an environment variable reference should go. The model is not being careless. It is doing exactly what it was trained to do: generate code that satisfies the requirement.

The developer reviewing the output sees code that works. The credential is there, but it looks like the rest of the generated code: plausible, functional, probably fine. The review step that would catch a hardcoded key requires specifically looking for it rather than just verifying the code does what was asked.

AI coding agents also generate more code, faster. More commits mean more surface area. Research tracking enterprise teams using coding agents found 3 to 4 times more commits per day compared to traditional workflows. If the baseline leak rate for AI-assisted commits is 3.2%, and commit volume triples, the expected number of leaked secrets grows proportionally.

The configuration file problem

The Moltbook key was in JavaScript delivered to the browser. That particular failure is obvious in retrospect but not unusual. AI-generated code frequently puts credentials in places where they become visible because the model is generating the layer that works, without modeling how that layer relates to what gets exposed.

Front-end JavaScript is the most visible case. Any key in a React component, a Next.js page, or a client-side fetch call is accessible to anyone who views the page source or watches the network traffic. AI models generating front-end code will sometimes put API keys there because the immediate task, calling an authenticated API from the browser, can be solved that way. The problem is that the solution is also a credential exposure.

Docker images are a less obvious case. A key used during a build step may end up in a layer of the final image even if it was not intentionally included. AI-generated Dockerfiles often do not include multi-stage build patterns or explicit layer management for secrets, because the working Dockerfile that builds the image is what the model was asked for.

MCP config files are the newest case. As teams adopt more AI tooling and connect it to more services, the number of places a key needs to live multiplies. Official quickstarts that put keys in config files normalize the practice, and when the config files get committed to keep the setup reproducible, the key goes with them.

What actually works

Secret scanning before commit is the clearest intervention. Tools like GitGuardian, TruffleHog, and GitHub's own secret scanning can be added to a pre-commit hook or CI pipeline to catch hardcoded credentials before they reach a repository. The check takes seconds and runs automatically on every commit. The majority of secrets that end up in public repositories were committed by developers who would have removed them if something had flagged them first.

Environment variables are the right pattern for credentials in any code that goes to production, but the gap is in how AI-generated code gets set up. When a model generates code that needs a credential, adding an explicit instruction in the prompt that credentials should always be read from environment variables, never hardcoded, pushes the model toward the correct pattern. It does not always work, which is why the automated check matters, but it reduces how often the problem appears in the first place.

For MCP configurations specifically, the fix is treating config files the same as code: secrets belong in environment variables referenced by the config, not in the config itself. A config file committed to a repository should contain no credentials. A config file that requires credentials to function should read them from environment variables at runtime.

Key rotation is the part that most teams skip. The 64% figure, meaning 64% of secrets leaked in 2022 were still active four years later, reflects how rarely organizations revoke compromised credentials once the initial incident is resolved. A leaked key that is not rotated stays useful to anyone who has it. Rotation should happen immediately on detection, not as part of a quarterly security review.

Code review for AI-generated output needs a specific secrets pass. Looking at whether the code does what was asked is a different review than looking for what should not be there. Both checks matter, but they need to be treated separately. A reviewer who verified the feature works may not have looked for the API key that the model slipped into line 47.

Dependency review matters here too. AI models that generate code with MCP configurations or third-party integrations will sometimes include direct API endpoint calls with credentials baked into the URL or request headers. These are easy to miss during a logic-focused review because the networking code looks correct. A secrets scanner catches them; a human reviewer focused on the feature specification often does not.

The .gitignore file is the oldest defense and still gets skipped. AI-generated projects may not include .env in .gitignore by default, particularly when the model generates a minimal project scaffold rather than copying from a security-conscious template. Checking that .env and any credential files are excluded from the repository before the first commit is a two-second task that prevents a common class of incidents.

Least-privilege API keys reduce the damage when a key does leak. A key that can only read from a single table causes less damage than one with full database access. The Moltbook key had full read and write access to the entire production database. A narrow-scope key for the same integration would have limited what the attacker could do even after finding it. AI coding agents request whatever scope gets the code working, which is usually more than the feature actually needs. Tightening permissions after the fact is tedious, but it is a meaningful backstop.

The 28.65 million number from 2025 is going to be higher in 2026. AI coding adoption keeps growing, commit velocity keeps increasing, and the practices for handling credentials in AI-generated code are still catching up to the tooling. The gap between generating code that works and generating code that does not leak credentials is not closing by itself. The automation that makes AI coding fast is the same automation that removes the pause where a developer might catch the problem. Adding the check back into that pipeline, at the commit hook or the PR gate, is the delta between where the number goes and where it could go instead.