AI Coding Agents Are Leaking Secrets at Twice the Rate of Humans and Expanding Attack Surfaces

AI Coding Agents Leak Secrets at Double the Rate of Human Developers

AI coding agents are fundamentally changing how quickly developers build and ship software, but they're also exposing credentials at an alarming pace. According to GitGuardian's 2026 State of Secrets Sprawl Report, commits identified as AI-assisted are leaking secrets at approximately twice the rate of human-written ones1

1

. Most of the fastest-growing categories of leaked credentials now connect to AI services, meaning the tools designed to advance development are simultaneously accelerating exposure of the keys that development relies on.

This isn't a new vulnerability. What's changed is AI altering the scale and pace at which mistakes happen. A coding agent can read an entire project, modify files, generate configurations and interact with external services in the time a developer might take to review a single pull request. The core issue isn't that AI coding agents sometimes encounter secrets, but that many credentials were never designed for environments where software acts autonomously1

1

.

Security Challenges Introduced by AI: From Detection to Prevention

Secrets sprawl occurs when credentials such as API keys, tokens and service account credentials accumulate across more systems than an organization can reliably inventory and rotate. Security teams historically tried controlling this sprawl by detecting exposed secrets retroactively through scanners watching repositories and pre-commit hooks. Those controls still matter, but AI coding agents expose the limitations of depending on detection alone1

1

.

Organizations should treat secrets sprawl in the agentic AI era as a Non-Human Identity problem, not a model-behavior one. Every useful action an agent takes on another system has an identity behind it. When agents query databases, call APIs and deploy to staging, some credential authorizes that action. Organizations cannot reliably predict every action an autonomous system will take, but they can control what the identity behind that system is allowed to access1

1

.

Researchers Breach OpenAI's Monorepo in Under 72 Hours

It took researchers at security startup Hacktron less than 72 hours to get from a bug in OpenAI's community forum to OpenAI's internal GitHub monorepo2

2

. The team used Anthropic's Claude models to chain two critical vulnerabilities together to compromise OpenAI employee ChatGPT accounts. From there, a compromised employee's Codex environment gave them access to OpenAI's internal GitHub monorepo, where they opened a single harmless pull request and stopped.

Monorepos make it easier to work across a codebase, but they don't isolate projects the way separate repositories do. AI coding agents raise the stakes because they can have broad, persistent access. Independent technology analyst Carmi Levy called the OpenAI incident "something of a warning shot" for the industry, noting that monorepos become a "monolithic target" for attackers looking to get more from a single compromise2

2

.

Compromised Accounts Create Cascading Access Problems

Erik Avakian, technical counselor at Info-Tech Research Group and former CISO for the Commonwealth of Pennsylvania, emphasized that monorepos aren't dangerous on their own—the issue is the concentration of risk. AI coding agents are consequential because they're designed to search code, understand relationships between components, and make changes across a codebase much faster than a human attacker manually trying to determine where important code, dependencies and configurations are located2

2

.

Access should follow least-privilege access principles. GitHub Apps can be limited to selected repositories with installation tokens that expire after an hour, but those permissions still operate at the repository level. In a monorepo, they don't create separate read boundaries between directories2

2

.

Dependency Sprawl Accelerates Software Supply Chain Attacks

AI coding tools are pulling open-source dependencies, libraries and container images into enterprise codebases faster than security teams can review them. The resulting dependency sprawl is widening the attack surface for software supply chain attacks. Malicious packages, typosquatting libraries and compromised transitive dependencies all enter through the same automated pipeline3

3

.

"Velocity has outpaced governance and controls," says Chainguard CISO Quincy Castro. "When you can generate code instantaneously, the traditional request, review, and approve cycle bottlenecks people. Nobody will stand for a world where they get their work done very quickly and all of it stacks up against a legacy, manual, human-led process"3

3

.

Attackers Target Long-Tail Open-Source Packages to Maximize Spread

Bad actors increasingly target obscure projects because popular ones attract more maintainers, contributors reviewing changes, and automated scrutiny. Castro points to a recent attack operation that mass-produced forks of legitimate projects, seeded malware into them, and scattered them widely enough that developers would mistake a fork for the official repository3

3

.

Chainguard's March 2026 State of Trusted Open Source report found that 96.2% of common vulnerabilities and exposures sit outside the top 20 container images, with the June edition raising that number to 97%. "Risk concentration is inverted from where most enterprise attention goes," Castro explains. "Organizations pour resources into hardening a small set of well-known images, while the actual exposure lives in the long tail"3

3

. Organizations need to rethink how they approach AI-driven development security as traditional gates and post-event analysis prove insufficient against the speed of autonomous coding systems.