Credential and Secret Exposure by AI Agents
The enterprise now runs on machine identities, and the numbers are uncomfortable. KPMG's Cybersecurity Considerations 2026 reports more than 80 non-human identities for every human one in the average large organization. Machine identities grew from roughly 50,000 in 2021 to 250,000 in 2025, a fivefold increase that already had identity governance teams gasping. Then AI agents arrived and made those figures look like a warmup: BeyondTrust Phantom Labs measured enterprise AI agent populations growing 466.7% year over year as of March 2026. No governance program was architecturally prepared to absorb that.
The management gap reflects this faithfully. A 2025 WEF analysis found 97% of non-human identities carrying excessive privileges. Entro Security's H1 2025 research found 47% unchanged for more than a year. Fifty-one percent of organizations report no clear ownership of AI identities at all. These aren't edge cases in the long tail of security debt; they are the baseline condition.
What makes the agent population specifically precarious is what I'd call the inheritance problem. When a developer provisions an agent, they typically hand it the credentials they already have: API keys, service account tokens, database connection strings scoped to their own access level. The agent then acts on that access at machine speed, across many systems simultaneously, without any of the judgment a human brings to deciding whether a particular action is appropriate in context. The credential was designed for a person who hesitates; the agent does not.
Long-lived secrets amplify everything. GitGuardian's policy breach data shows long-lived secrets account for 60% of violations. Agents worsen this because their credentials are rarely scoped, rotated, or audited. An agent running on a static API key embedded in a configuration file from eighteen months ago is not an outlier. The NHI population is large, under-governed, and over-privileged, and the sections that follow explain exactly how credentials escape from it.
The five paths by which secrets enter an AI agent's context window
Secrets enter an agent's context window through five distinct paths. Notably, none requires a developer to do something obviously wrong; they are the natural output of reasonable engineering decisions applied to a problem that existing security tooling was never designed to address.
System prompts
Developers embed API keys, database connection strings, and authentication tokens directly in system prompts because the model needs them to call tools, and this is often the path of least resistance when a framework offers no clearly superior alternative. OWASP added System Prompt Leakage as LLM07 to its 2025 Top 10 specifically because the pattern is so widespread. A secret in a system prompt is a secret in plaintext, available to any instruction that follows it.
RAG pipeline ingestion
Retrieval-augmented generation pipelines pull documents from across the organization: deployment runbooks, internal wikis, Confluence pages, Notion docs, configuration files. Any document containing a credential becomes a retrievable chunk, and once retrieved, the credential is live in context for whatever instruction follows. The agent didn't go looking for the secret. The secret arrived as a stowaway in a document nobody thought to screen.
Tool call responses
When an agent calls an external API, the full response enters the context window, including authentication headers, session tokens, or sensitive fields in the response body. Under a prompt injection attack, those tokens become immediately accessible to attacker-controlled instructions embedded in the same response. The agent fetched data. The attacker got credentials.
Debug logging
Agent frameworks capture standard output into the LLM context window during development and, frequently, in production as well. One empirical study of agent skill vulnerabilities found that information exposure through print statements and console logging accounts for 73.5% of all identified vulnerability issues, totaling 1,007 of 1,371 cases examined. Debug output is a live credential leak surface. Most developers treat it as a development artifact rather than a security boundary — a reasonable instinct, but a wrong one.
AI-generated code
AI-assisted commits expose secrets at more than twice the rate of human-only commits: 3.2% versus 1.5%, per GitGuardian's research. Hardcoded credentials are the second most prevalent vulnerability pattern in agent skills, accounting for 18.2% of all identified issues, and among those cases, 71.96% showed evidence of AI-assisted development in commit messages, with explicit references to Copilot, Claude, and ChatGPT. The AI wrote the credential leak that the AI will later read.
All five paths share the same structural characteristic: secrets arrive in context as a byproduct of normal agent operation, not because an attacker did anything. Traditional secrets managers have no visibility into what happens inside a context window.
Why the Model Context Protocol introduced an ecosystem-scale credential leak surface
The Model Context Protocol, originally developed by Anthropic and now open-sourced, creates a standardized interface for AI assistants to connect to external tools and data sources. Its adoption spread quickly. So did a new class of credential exposure that travels with it.
In 2025, GitGuardian found 24,008 unique secrets in MCP-related configuration files on public GitHub, with 2,117 verified still valid. The root cause is almost disappointingly mundane: official MCP quickstart documentation shows API keys hardcoded in configuration examples, and developers copy the pattern because documentation is authoritative by implication. When the template contains a hardcoded secret, the derivative contains a hardcoded secret. Scale that across every developer who followed the official guide.
The architecture itself drives NHI proliferation structurally. Each discrete MCP server component requires its own identity and credentials, so an agent ecosystem built on MCP isn't one identity to govern; it's dozens, each with its own provisioning history, its own rotation cadence, and its own owner, if it has one at all.
The blast radius of a single leaked token in this ecosystem also differs qualitatively from that of a traditional API key. Agent-building platforms grew at rates between 500% and 600% during this period, and their access tokens frequently carry broad account-level permissions that unlock not one service but an entire network of delegated integrations.
Two incidents in 2025 made the abstractions concrete. GitGuardian disclosed a path traversal bug in Smithery.ai, a widely used MCP server registry, where a single overprivileged token in the Docker build process granted arbitrary code execution across all 3,000-plus hosted MCP servers on the platform. Separately, JFrog identified CVE-2025-6514 in mcp-remote, an OAuth proxy with over 437,000 downloads used in integration guides published by Cloudflare, Hugging Face, and Auth0. A malicious MCP server could send a crafted authorization endpoint that executed arbitrary shell commands on the client machine, giving an attacker access to API keys, cloud credentials, SSH keys, and Git repository contents. The vulnerability wasn't in one agent; it was in the proxy every agent used.
That's the supply-chain dynamic MCP introduces at scale: a vulnerability in a shared registry or proxy component doesn't compromise one agent. It compromises every agent connected to that component.
What real attacks against production AI agents actually look like
EchoLeak, disclosed by Aim Security in June 2025 and assigned CVE-2025-32711 with a CVSS score of 9.3, was a zero-click prompt injection in Microsoft 365 Copilot. An attacker sent a crafted email. Copilot processed it and exfiltrated data from the victim's M365 environment without any user interaction. None. The attack required chaining four distinct bypasses: evading Microsoft's cross-plugin injection classifier, circumventing link redaction through Markdown formatting, exploiting auto-fetched images, and abusing a Teams proxy permitted by the content security policy. EchoLeak is the clearest documented proof that prompt injection can be weaponized for concrete data exfiltration in a production AI system at enterprise scale, against a mature, well-resourced vendor with active security controls already in place.
The Devin AI incident in April 2025 demonstrated something different but equally instructive. Researcher Johann Rehberger planted a poisoned GitHub issue containing indirect prompt injection. Devin, operating autonomously with legitimate shell access and credentials for Jira and Slack, followed the embedded instructions without hesitation. It ran curl and wget commands to send environment variables to an attacker-controlled server. Then it navigated to an attacker-controlled site, downloaded a Sliver C2 malware binary, independently granted itself execute permissions when file permissions initially blocked it, and ran the binary, giving the attacker remote command-and-control access including all secrets and AWS keys on the machine. The incident was reported April 6, 2025, acknowledged, and remained unresolved after 120 days. The agent was doing exactly what it was designed to do: take initiative and solve problems.
CVE-2025-12420, the ServiceNow BodySnatcher vulnerability, illustrates a third vector. An unauthenticated attacker could impersonate any ServiceNow user using only an email address, bypassing MFA and SSO entirely. The mechanism was a hardcoded, platform-wide secret chained with an account-linking flaw in the Now Assist AI Agents application. No stolen password required; a secret the platform had embedded itself was sufficient.
The common thread across all three: agents had legitimate access to credentials and legitimate capability to act on them. The attack didn't need to breach a vault. It needed only to redirect an agent that already held everything it needed.
Why traditional secrets management doesn't reach the places agents put credentials
Secrets managers, vaults, environment variable injection systems, key rotation pipelines: these tools operate at the infrastructure layer. They govern where secrets are stored and how they are provisioned. They have no visibility into what happens once a secret enters an agent's runtime, and that gap is the whole problem.
The context window is a structural blind spot. Once a credential lands in an LLM's context, whether via system prompt, RAG retrieval, tool response, or log capture, it is outside the perimeter of any vault. No rotation policy reaches it there. No audit log records what happened to it there. The vault did its job correctly, and the credential still leaked.
Prompt injection converts legitimate provisioning into exfiltration. Devin held valid, vault-provisioned secrets. The attack didn't compromise the vault; it redirected an agent that had already been legitimately given the secret. Traditional secrets management has no mechanism to detect or prevent that, because the theft didn't occur at the storage layer.
Rotation takes on a different character with agents specifically. Traditional rotation assumes a known system will consume the rotated credential on a predictable schedule. Agents cache credentials in memory, in conversation history, or in tool state across sessions. Rotating the credential at the vault doesn't invalidate what's already loaded in context. The new key is in the vault. The old key is still in the agent.
Internal repositories compound the exposure. GitGuardian's data shows internal repositories are six times more exposed than public ones. The RAG ingestion path exploits exactly this: agents pulling from internal knowledge bases are pulling from the most credential-dense environment in the organization, with no filtering layer capable of recognizing what a secret looks like inside a document chunk. The vault never touched those documents.
Governing the warehouse while the agents operate somewhere else is not a secrets management program. It is the appearance of one.
The controls that apply specifically to agent credential exposure
None of the following controls are exotic. All of them require treating agent credentials as a distinct artifact class rather than a subset of human credential management.
Scope credentials to the task, not the agent. Agents should receive the minimum permissions needed for a specific action, not the full account-level access of whoever provisioned them. With 97% of non-human identities carrying excessive privileges, least-privilege assignment at provisioning time is the most direct counter available, and it requires no new tooling.
Eliminate long-lived secrets in agent configuration. Static API keys embedded in system prompts and config files account for 60% of policy breaches in GitGuardian's data. Short-lived, dynamically issued tokens are the structural alternative; they also remove the RAG ingestion risk for credentials that would otherwise persist indefinitely in documents the agent can retrieve.
Treat MCP configuration files as a secret-bearing artifact class. The 24,008 secrets found in MCP configs on public GitHub in 2025 exist largely because those files weren't scanned the way source code was. Applying secrets detection to MCP configuration at commit time closes that gap using existing tooling on a new file type.
Restrict agent egress at runtime. The Devin attack succeeded in part because the agent could make arbitrary outbound HTTP requests to attacker-controlled infrastructure. Restricting which URLs and endpoints an agent can reach limits the exfiltration surface even when prompt injection succeeds in redirecting behavior.
Monitor agent behavior for credential-shaped outputs. Logging what an agent sends, not just what it receives, is the detection layer that catches exfiltration in progress. Vault audit logs record provisioning events; they do not record what an agent did with a credential three hours after receiving it.
Establish ownership for every non-human identity. Fifty-one percent of organizations have no clear owner for AI identities, which means no one is rotating, reviewing, or decommissioning those credentials. Ownership is the precondition for every other control to remain functional over time. It requires no technology, just someone's name on a list.
Exposure happens at runtime, not at provisioning. Vaults are provisioning controls. Agents need runtime controls. Until organizations extend their secrets management posture past the vault and into the context window, they are solving the right problem in the wrong place.
