Credential and Secret Exposure by AI Agents
AI agents leak secrets twice as fast as humans, outpacing security controls built for people.
Credential and secret exposure by AI agents gets described as a developer-negligence problem: someone pasted a key where it shouldn't go, someone forgot to rotate a token. The data says otherwise. GitGuardian's State of Secrets Sprawl Report found that AI-assisted commits leak secrets at roughly twice the rate of human-written ones, and that gap doesn't come from agents being sloppier coders than humans. It comes from the fact that an agent can read an entire project, modify files, call external APIs, and talk to MCP servers in roughly the time it takes one developer to review a single pull request. Review cycles built for human pace cannot catch machine-pace exposure. The infrastructure managing credentials was built for people who log in once, do a task on purpose, and stop when they go home, and agents don't fit that shape.
Secrets sprawl as a lifecycle problem that predates agents
Agents didn't invent secrets sprawl. Long before any coding agent touched a production repository, the same API key was already turning up in a.env file, a CI/CD variable, a Jira ticket pasted in during a failed deployment, and a laptop's local config, with each copy able to authenticate on its own. A credential with no expiry sits valid indefinitely, spreading into more places the longer it lives and extending the window of any compromise. OWASP's Non-Human Identity Top 10 calls this out as its own category, NHI7.
There's a serious objection buried in this history, and it deserves a straight answer rather than a dismissal: AI didn't create secrets sprawl, it's accelerating conditions that already existed. More people can write code now, more of that code ships, more third-party services get wired in, more machine identities get spun up to manage all of it. All true. But accepting that argument doesn't let agents off the hook, it just locates them correctly. Lifecycle negligence, the hardcoded key, the forgotten rotation, the config file nobody audits, is the root cause. Agents are the mechanism that takes root-cause negligence and propagates it across more systems, faster, than any one developer ever could. If you fix the lifecycle problem without accounting for agent behavior, the acceleration keeps running anyway.
The four structural mechanisms by which agents expose credentials
Four mechanisms turn ordinary credential sprawl into agent-scale exposure, and each one follows from what makes an agent useful in the first place, not from any particular agent being badly built.
The first is broad file-context access. Developers routinely leave credentials sitting in.env files and local config, residue from a debugging session nobody cleaned up. A human only opens those files when they're looking for something specific. An agent with project-wide access doesn't discriminate: a config file holding a live production API key is just part of the working environment, and unless someone has explicitly fenced it off, the agent can read it even when the task at hand has nothing to do with it. The developer's laptop used to be safe by obscurity, since only the developer and the applications built to reference a given file would ever touch it. An agent operating across that same machine erases that obscurity by default.
The second mechanism runs through MCP, the protocol that emerged in November 2024 as the standard way to connect large language models to external tools. Setup guides for MCP servers routinely tell developers to paste credentials straight into a configuration file to get the integration working quickly. Those files rarely enter version control, so teams treat them as safe by default. But the credential still sits in plaintext on the developer's machine, often in a spot the agent has permission to read. GitGuardian's 2025 research found 24,008 unique secrets exposed specifically inside MCP configuration files, a surface that barely existed until very recently and has almost no monitoring built around it.
The third mechanism is duplication through multi-system reach. An agent wired into a code repository, a CI/CD pipeline, a ticketing system, and a cloud API isn't reading one copy of a secret, it can encounter and move every copy across all four surfaces in a single operation. In multi-agent setups, an orchestration layer holding the keys for several downstream agents turns one compromised credential into a domino chain, since whatever the orchestrator can reach, an attacker holding its credential can reach too. A careless developer copies a key once, by mistake. An agent with cross-system reach duplicates credentials as a routine part of doing its job, not as an exception.
The fourth mechanism closes the loop: permission accumulation with no offboarding trigger. Agents start with narrow access, and every new integration added to keep a workflow moving tends to widen that access rather than narrow it. If a human employee changes roles or leaves the company, that triggers an access review. No equivalent event exists for an agent, so permissions just accumulate, unreviewed, indefinitely.
Authentication signals agents skip that catch human credential abuse
Speed explains how fast an agent can expose a credential. It doesn't explain why almost nobody notices when it happens. The more dangerous property of agent credential exposure is that it looks, to most monitoring tools, exactly like normal operation.
Human credential misuse throws off signals that security teams have spent two decades learning to watch for: a login from a new country, a request pattern that breaks from someone's usual habits. Agents skip authentication the way employees experience it: they don't use MFA, they reuse the same credential across sessions, and they hold persistent access rather than logging in and out, so there's no login event, no session anomaly, no geographic inconsistency for a monitoring system to flag. If an attacker steals an agent's session token or API key, the resulting network traffic looks identical to a request from a legitimate, valid-credentialed agent account, and Stellar Cyber's threat analysis is blunt about the consequence: there's no signal available to tell the real agent apart from an attacker using its credentials.
The four mechanisms from the previous section feed directly into this blind spot. Broad file access, MCP configuration sprawl, multi-system duplication, and accumulated permissions aren't just ways a credential gets exposed; they're also the reason a compromised agent can move through multiple business-critical systems without tripping the alerts that a stolen human credential would set off. Traditional SIEM and EDR tooling was trained to spot anomalies in human behavior. An agent calling an API correctly, in sequence, hundreds of times in a row looks completely normal to that tooling, even when every one of those calls is executing an attacker's instructions rather than its own task. The Cloud Security Alliance's 2026 survey found that 68% of organizations say they cannot tell agent activity apart from human activity. The detection infrastructure most companies have in place is operating blind across the majority of their actual traffic.
Three concrete cases that show how the mechanisms play out in production
None of this is theoretical.
Security researcher Aonan Guan, working with researchers from Johns Hopkins University, disclosed a vulnerability class affecting three separate AI agents running on GitHub Actions: Claude Code Security Review, Google's Gemini CLI Action, and GitHub Copilot Agent, all found vulnerable to what the researchers named "Comment and Control" attacks. The attack worked through ordinary GitHub surfaces, PR titles, issue bodies, and comments, letting attackers steal API keys and access tokens without standing up any external infrastructure of their own. Base64 encoding was enough to slip past the secret scanner, and three credentials came out exposed, including GITHUB_TOKEN and GITHUB_COPILOT_API_TOKEN. This is the multi-system reach mechanism in its purest form: three different vendors' agents, one shared GitHub surface, and a single injection technique that worked across all of them.
By January 2026, researchers disclosed a chain of vulnerabilities in OpenClaw, CVE-2025-49596 (CVSS 9.4, affecting Anthropic's MCP Inspector rather than OpenClaw itself) and CVE-2026-44115 (CVSS 9.6). Internet-wide scanning turned up more than 900 exposed OpenClaw gateways running with no authentication at all, leaking API keys, OAuth tokens, and full conversation histories stored as plaintext files. Infostealer malware adapted to target those exact storage locations almost immediately, which is the clearest evidence available that once a structural exposure pattern gets established at scale, attackers industrialize around it rather than treating it as a one-off. This is permission accumulation and plaintext storage playing out at internet scale.
The third case belongs to MCP directly. CVE-2026-32211, disclosed in April 2026, hit Azure's MCP Server with a CVSS score of 9.1, exposing API keys and tokens with no credentials required to reach them. Security researcher Simon Willison named the underlying architecture problem a "lethal trifecta": an agent that simultaneously holds access to private data, can be reached by untrusted input, and has a path to exfiltrate data has all three ingredients attackers need, at which point stealing the credential is a matter of timing rather than skill. MCP's position as the standard integration layer connecting agents to everything else turns its authentication model from an isolated bug into a systemic risk surface shared by every agent that depends on it.
A fourth data point sits slightly outside the runtime story, but it belongs in the same frame. In early 2025, security researchers found that training datasets pulled from Common Crawl and similar public web sources contained live credentials that had been swept up into LLM and AI tool training pipelines without anyone intending it. A scanning effort from Truffle Security, analyzed by PointGuard AI, turned up nearly 12,000 live secrets, valid API keys, access tokens, and passwords that successfully authenticated against AWS, Slack, and Mailchimp. The exposure surface doesn't stop at agent runtime behavior. It reaches into the training data itself.
Blast radius: compromised agent credentials versus compromised human credentials
A stolen human credential is bounded by a person's actual job. What that employee could reach during their working hours sets the ceiling on the damage. A stolen agent credential has no comparable ceiling, because the blast radius covers everything the agent was ever granted access to, across every system it's connected to, running continuously rather than during business hours.
The mechanism attackers favor here has a name security researchers borrowed decades ago and still use correctly today: the confused deputy attack. An attacker doesn't need to breach the network directly. All that's required is tricking a trusted agent into acting on the attacker's behalf, and the agent's own valid credentials do the rest of the work, no further hacking needed.
Governance hasn't caught up to this gap. SecureNDs reports that only a small fraction of organizations have put together a formal agent identity strategy, and most of the rest admit their existing identity and access management tools weren't built with this problem in mind. The mechanisms described earlier, broad file access, MCP sprawl, multi-system duplication, accumulated permissions, all assume there's no equivalent of an exit interview for a software agent. There isn't. Nobody revokes an agent's access when it changes jobs, because an agent never had a job in the human sense to begin with, just a growing list of systems it was once convenient to let it touch.
