Hardcoded Secrets in AI-Assisted Code: The Throughput Problem

GitGuardian's State of Secrets Sprawl 2026 documented 29 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-over-year increase and the largest single-year jump ever recorded. That spike maps almost exactly onto the period when GitHub Copilot and Cursor reached mainstream adoption. The standard response to this data is a checklist: use environment variables, run a scanner, add a pre-commit hook. That framing misses the actual failure mode, which is not about what AI writes, but about how fast it writes it and what that speed does to the tooling humans already had in place.

AI-assisted commits carry more than double the baseline secret-leak rate

The raw numbers from GitGuardian are worth sitting with. Across all public commits in 2025, the baseline secret-leak rate was 1.5%. For AI-assisted commits specifically, that rate was 3.2%, more than double. Veracode's 2025 GenAI Code Security Report adds a compatible data point: AI-generated code contained 2.74 times more vulnerabilities than human-written code across a sample of 80 coding tasks, four programming languages, and four vulnerability categories. Only 55% of AI-generated code in that analysis was secure on delivery.

The mechanism is not mysterious. AI coding tools are trained to produce functional code that satisfies an immediate prompt. When a developer asks for a working integration with an external API, the model produces something that runs, which often means filling in credentials inline to get the example working. The model is not malicious; it is optimizing for the wrong signal. Passing a test is not the same as being production-safe, and nothing in the generation loop penalizes a hardcoded API_KEY = "sk-..." if the resulting code executes correctly.

Veracode's analysis also noted that 97% of developers have now used AI tools, citing GitHub's 2024 developer survey. That adoption rate means the 3.2% AI-assisted leak rate is not a niche concern. It is becoming the baseline.

The throughput mismatch is what actually breaks your detection pipeline

Here is where the standard coverage goes wrong: it treats hardcoded secrets as a code quality problem with a scanner-shaped solution. The harder problem is architectural. Pre-commit hooks, PR review cadence, and scanner alert triage were all designed around human coding speed. An experienced developer might open three or four PRs per week. A developer working with an AI coding agent can plausibly generate that many in a single afternoon, and the code surface in each PR is larger because the agent fills in boilerplate that a human would write incrementally.

The result is a throughput mismatch. Your secrets scanner still fires at the same rate, but now it is firing across ten times the code surface in the same calendar window. The human triaging those alerts has not gotten faster. Alert queues lengthen. Validated secrets, meaning credentials the scanner confirms are still active and exploitable, sit unrotated in commit history while the triage backlog grows.

GitGuardian's data makes the consequence concrete: nearly 70% of credentials confirmed as valid in 2022 were still valid in January 2025. When retested in January 2026, the validity rate remained above 64%. The detection was not the failure, since those secrets were found. The failure sits in the remediation pipeline, which was never designed to process secrets at AI-assisted commit velocity. As GitGuardian put it directly in the report: "The difference between success and failure isn't finding more secrets, it's knowing which ones to fix first."

This is a prioritization and workflow problem, not a scanner configuration problem. Adding more rules to your pre-commit hook does not help if the bottleneck is the human reading the output.

Three failure patterns that typical coverage ignores

Most articles on this topic describe AI-generated code as the primary threat surface. In practice, the failures that persist longest tend to cluster in three patterns that do not show up cleanly in a repo scan.

Secrets that spread laterally after the initial commit. GitGuardian found that on average, each live secret appeared in eight different locations on the same compromised machine: .env files, shell history, IDE configs, cached tokens, and build artifacts. Rotating the credential in the repo does not clean the other seven locations. When a developer uses an AI agent to scaffold a project locally, those intermediate files often persist without ever touching a repo.

CI/CD runners as the primary exposure surface. Of the compromised machines GitGuardian analyzed, 59% were CI/CD runners, not developer laptops. AI-assisted development accelerates the path from local scaffold to pipeline execution, which means secrets embedded during rapid prototyping reach CI runners faster than before. Runners often have broad permissions, and their logs are sometimes stored in collaboration tools with wide internal access.

MCP server configuration files as a new blind spot. GitGuardian identified 24,008 unique secrets exposed in MCP-related configuration files across public GitHub, including 2,117 confirmed valid credentials. MCP servers sit at the boundary between AI agents and external services. Configuration files for them are often committed alongside project code by developers who treat them as local tooling rather than production artifacts. This is a category that did not exist at scale two years ago, and current scanner rule sets are only beginning to cover it.

The CSA's May 2026 analysis of vibe-coded production applications adds a compatible finding: Escape.tech scanned over 1,400 production apps and found that 58% contained at least one critical vulnerability, with over 400 exposed secrets across the sample. A separate December 2025 study by Tenzai examined 15 production applications built with five major AI coding tools and found 69 vulnerabilities in total. Every single application lacked CSRF protection and had no security headers configured. The secrets problem does not travel alone.

AI services are now the fastest-growing category of leaked secrets

GitGuardian's data on the specific type of secrets leaking is worth calling out separately because it changes which credentials you should prioritize.

In 2025, GitGuardian detected 1,275,105 leaked secrets tied to AI services, up 81% from 2024. Eight of the ten fastest-growing categories of leaked secrets year-over-year are AI service credentials. This creates a specific compounding risk: developers using AI tools to write code are also the most likely to hold AI service API keys, and those keys are increasingly what ends up hardcoded in the output. The tool generating the code and the credentials leaking in the code are often from the same vendor ecosystem.

An OpenAI or Anthropic API key with no rate limit or spend cap attached to it is materially different from a leaked internal database password. It can be used to run inference at the credential owner's expense, or to probe for system prompt content if the key is associated with a deployed assistant. The blast radius is broader than a traditional credential leak.

The fix is not a scanner, it's a workflow gate with teeth

This does not mean scanners are useless. Treating a scanner as a complete solution is the wrong frame. What actually needs to change is the review gate between AI-generated code and the main branch.

A few approaches that address the throughput problem rather than just the detection problem:

• Automated blocking, not just alerting. Pre-commit hooks that warn are easy to bypass under time pressure. Hooks that prevent the commit until the secret is removed function as a hard gate regardless of how many commits per day are being generated.
• Separate triage queues for AI-assisted PRs. If your tooling can tag PRs that include significant AI-generated code, your security team can apply a different review protocol to them without reviewing every PR at the same depth.
• Short secret lifespans by default. If a secret is valid indefinitely until manually rotated, the window of exposure grows with commit velocity. Secrets that expire in 24 or 72 hours limit the damage from the remediation backlog, regardless of how long the alert sits in the queue.
• Scope restrictions on CI tokens. If CI/CD runners are 59% of the compromised machines, limiting what those tokens can actually do is a higher-leverage control than reviewing every build log.

None of these eliminate the underlying tendency of AI-generated code to embed credentials. They address the throughput mismatch that allows those credentials to survive.

FAQ

Does GitHub Copilot actually suggest hardcoded secrets, or is this overstated?

Copilot and similar tools can and do suggest inline credentials, particularly when generating example code for API integrations or when the surrounding context includes similar patterns (such as an existing .env.example file). GitGuardian's finding that AI-assisted commits carry a 3.2% secret-leak rate versus a 1.5% baseline for all commits suggests the tendency is real and measurable at scale, though the exact mechanism per tool has not been independently replicated across controlled studies to my knowledge.

Does scanning commit history retroactively help after a secret has leaked?

Retroactive scanning finds secrets but does not revoke them. A secret in git history, even after being removed from HEAD, remains accessible to anyone who cloned the repo before the removal or who has access to the history. The correct remediation is always to rotate the credential immediately, then clean the history. Tools like git filter-repo can scrub history, but any forks or clones created before the scrub retain the original commits. Rotation is the only action that actually closes the exposure.

Are there categories of projects where this is lower risk?

AI-assisted development on closed-source private repositories with no external collaborators and strong IAM controls does reduce the blast radius compared to public GitHub. However, GitGuardian's finding that 28% of incidents originate in collaboration and productivity tools, not repositories, means private repos do not fully contain the exposure. If a developer pastes a snippet into a shared Slack channel or a Notion doc while debugging, the secret has left the controlled environment.

What is an MCP server and why does it matter for secrets management?

MCP (Model Context Protocol) is an Anthropic-developed standard for connecting AI agents to external tools and services. You can read the full technical specification in Anthropic's documentation. MCP server configuration files typically include API keys and service credentials for the tools the agent is authorized to use. Because these files are often created during local development and treated as configuration rather than code, developers sometimes commit them without applying the same review they would give to application source files. The 24,008 unique secrets GitGuardian found in MCP-related files represent a category that most existing scanner rule sets were not built to catch.

Across the development teams absorbing AI coding tools fastest, the 34% year-over-year increase in hardcoded secrets reflects a review and remediation infrastructure built for a slower world now running at a pace those systems were never designed to handle. The secrets are being found. The gap between finding them and fixing them is widening with every sprint, and commit velocity is what is driving it wider.