Secrets and Credential Leakage Risks in AI Coding Assistants
Secrets sprawl was already a serious problem before AI entered the developer workflow. Credentials get hardcoded to make something work, committed in haste, and then forgotten in version history while remaining active in production. Public repositories have always been the most visible exposure surface, but internal repositories carry a higher concentration of hardcoded secrets precisely because developers assume "internal" means "safe." It does not.
Then the AI tools arrived, and the baseline shifted in ways that should embarrass the industry.
GitGuardian's State of Secrets Sprawl report found that repositories where GitHub Copilot is active show a higher secret leak rate than the cross-repository baseline. Commits co-authored by Claude Code leaked secrets at roughly double that baseline rate. AI-service credentials, specifically API keys for LLM providers, embedding services, and AI platforms, are now the fastest-growing category of leaked secrets, rising sharply year-over-year in direct proportion to adoption. The pattern holds across providers and tools, which tells you this is a systemic relationship, not an artifact of any one assistant's quirks.
The causal mechanism is genuinely contested. Are leak rates higher because AI writes more code faster, producing more surface area for error? Because AI generates less secure code by default? Because early adopters of AI coding tools skew toward developers who are already less attentive to security hygiene? The honest answer is probably some combination of all three, which is exactly what makes this hard to fix with any single intervention.
Why AI coding assistants structurally encourage hardcoding credentials
The first driver is scaffolding velocity. AI assistants let developers build working integrations fast. The credential gets hardcoded to make the demo run; the prototype looks production-ready before it actually is; the cleanup never happens because the next feature is already in flight. This is not a new failure mode. It is an old one running at a much higher clock speed.
A second driver is subtler and more troubling. AI-generated code mirrors patterns from its training data, and the historically common pattern in public code for handling API keys has been the insecure one: inline, plaintext, close to the call site. Researchers scanning large public web-crawl datasets have found valid, live secrets embedded in the HTML and JavaScript that forms part of LLM training corpora. The model learns from code containing real credentials and has no mechanism to distinguish "this was a key someone forgot to remove" from "this is the correct way to call this API." So it reproduces the pattern. Reliably.
The Cursor.env exposure incident illustrates a third driver: the boundary between "local credential" and "model input" is more permeable than developers assume. In that case, the assistant sent environment file contents, including secrets, to its servers for tab completion even when those files were nominally excluded from the context window. Developers who believe their.env files are safe are operating under a false assumption, often a confidently held one.
"Vibe coding" compounds all of this. Developers using AI to generate code they do not fully read are also less likely to catch a hardcoded credential the model inserted. The proliferating ecosystem of new AI vendors continuously produces new credential formats, and secrets-scanning tooling lags behind, so novel key types go undetected even when sitting in plain sight. Fast generation combined with low review is the worst possible environment for catching secrets before commit.
These drivers compound each other. Individually, any one of them would nudge leak rates upward; together, they explain the magnitude of the gap the data shows, and why "remind developers to use environment variables" is not a serious governance strategy at this scale.
Prompt injection as an active exfiltration vector, not just a passive leak risk
The mechanisms above are passive: the assistant leaks a secret as a byproduct of code generation. Prompt injection is a different category of problem entirely, one where an adversary uses the assistant itself as the exfiltration mechanism. That distinction matters more than it initially appears.
In 2025, Embrace the Red documented a DNS-based exfiltration attack against Claude Code. Through an indirect prompt injection, the assistant was manipulated into reading sensitive local files, encoding their contents into DNS queries, and resolving those queries against attacker-controlled infrastructure. The assistant became the data pipe. No malware was installed. No unusual process spawned. The AI simply did what the injected instructions told it to do, helpfully and efficiently.
HiddenLayer demonstrated a comparable attack against Cursor: hidden instructions embedded in README files or other repository artifacts could redirect the assistant to leak secrets or perform unsafe operations. The attack surface is any text the assistant reads as context, which, by design, is most of the repository.
The structural problem is inescapable. AI coding assistants require broad local file access to be useful. That same access, when redirected by injected instructions, becomes precisely the capability an attacker needs for exfiltration. A developer's machine running an AI coding assistant is a potential lateral movement vector. Compromise the assistant's context through a malicious dependency, a poisoned issue, or a crafted README, and you reach every secret the developer has stored locally.
The supply chain attack known as Shai-Hulud made this concrete. AI-powered malware hijacked local CLI AI tools to identify and exfiltrate tokens from developer machines, then used those tokens to republish malicious packages. The attacker did not need to compromise a server. They needed to compromise the context the AI was reading, which turned out to be considerably easier.
MCP servers multiply the credential exposure surface for agentic workflows
Model Context Protocol was designed to solve a genuine integration problem: standardized, composable connections between AI agents and external tools, databases, and APIs. It was not designed with enterprise secrets management as a foundational requirement, and that omission is now plainly visible in how the ecosystem has developed.
The original MCP specification shipped without mandatory authentication. Adoption outpaced security review; tens of thousands of MCP servers were deployed across enterprise environments before the security community had adequately characterized the attack surface. The credential posture of that ecosystem, as analyzed by Astrix Security across thousands of open-source MCP server implementations, is not reassuring. The large majority of servers require credentials to function. More than half rely on long-lived static secrets, API keys and personal access tokens, rather than short-lived or scoped credentials. OAuth adoption remains a small minority of implementations despite being the more defensible option. The ecosystem essentially reproduced every credential anti-pattern the industry had spent a decade trying to retire.
The "confused deputy" problem is endemic to poorly implemented MCP servers. When a server acts on a user's behalf, there is no guarantee that action is scoped to the user's actual permissions. The server executes with its own broad credentials, violating least-privilege and potentially granting users access to resources they should not reach.
CVE-2025-6514, affecting a widely used OAuth proxy with hundreds of thousands of downloads, demonstrated the severity of this attack surface concretely. The vulnerability was an OS command injection flaw; a malicious MCP endpoint could achieve remote code execution on the client machine and reach API keys, cloud credentials, and SSH keys stored locally. GitHub personal access tokens represent a systemic risk of similar character: developers routinely grant AI assistants broad PAT access covering all repositories, and a single poisoned GitHub Issue is sufficient to coerce an agent into exfiltrating data from private ones.
The audit gap makes all of this worse. A large share of enterprise AI deployments have no structured audit trail of agent tool access, which means forensic reconstruction after an incident is slow, incomplete, and expensive.
Why enterprise-scale AI adoption makes centralized secrets governance unavoidable
A single developer running Claude Code with a hardcoded AWS key is a manageable incident. A thousand developers doing the same thing is a systemic exposure that no security training program will resolve. At a certain scale, the problem stops being behavioral and becomes architectural. That transition is uncomfortable for organizations that prefer to address security problems through mandatory trainings and strongly worded internal memos.
AI tools are already inside enterprise environments whether security teams have inventoried them or not. Shadow AI follows the same adoption curve as shadow IT: tools spread team by team, use case by use case, well before any governance framework exists. The security team finds out later, usually during an audit or after an incident.
The infrastructure secrets problem is disproportionately concentrated at the integration layer. Per GitGuardian's research, secrets tied to AI-adjacent infrastructure, including orchestration tools, RAG pipelines, and vector databases, are leaked at a higher rate than secrets for core LLM providers. The governance gap is widest precisely where most enterprise AI development work is actually happening, which reflects the fact that integration code is written fast, often by developers who are simultaneously learning the tool they are integrating.
Rotation and revocation at scale expose a further dimension of the problem. Even when a leaked secret is detected, acting on it requires knowing which systems use the secret, who provisioned it, and whether any agent workflows depend on it. That information does not exist without a centralized inventory. Without it, the response to a leaked secret is educated guesswork, executed under time pressure, with incomplete information.
Compliance pressure is accelerating the urgency. EU AI Act readiness, SOC 2 scope expansion to cover AI systems, and internal audit requirements are creating formal obligations around AI observability and access control that individual teams cannot satisfy independently. The unit of governance cannot be the individual developer or the individual tool. It has to be a layer that sits across all AI access, enforces policy consistently, and produces the audit trail that incident response and compliance both require.
What a governed AI layer needs to do to actually contain secrets leakage
Credential custody belongs at the platform layer. AI assistants and agents should hold no API keys to LLM providers or downstream services directly. The governed layer holds those keys and proxies requests, so no individual developer or agent has a secret to leak in the first place. This single architectural decision eliminates the most common failure mode before it can occur. The difficulty is organizational rather than technical: it requires the organization to actually commit to the architecture rather than carving out exceptions every time a team finds it inconvenient, which is where most enterprises quietly abandon the effort.
Real-time secrets detection needs to operate at the AI traffic layer, not just at the code commit layer. Scanning model inputs and outputs for credentials in transit catches cases where an assistant is being fed a secret through context or is about to emit one in a code suggestion. Traditional secrets scanning in CI/CD is necessary but not sufficient; by the time code reaches the pipeline, the secret has already been transmitted to a model endpoint.
Prompt injection detection has to be a first-class capability, not a feature retrofitted after the architecture is already in production. Because active exfiltration vectors operate through injected instructions, detection must happen at inference time. Post-hoc analysis of what an agent did is useful for forensics; it does not stop the exfiltration that already occurred.
For MCP and agentic workflows, identity-scoped tool access is the structural answer to the confused-deputy problem. Agent actions should be authorized against the identity of the human user who initiated the session, not the broad permissions of the MCP server. RBAC tied to existing identity providers, Okta and Entra ID being the practical path for most enterprises, expresses who should reach what using role and group definitions the organization already maintains. Short-lived, scoped credentials per session replace long-lived static secrets; rotation happens at the platform layer, invisibly, without requiring developers to manage it.
Full audit trails for agent tool access are mandatory if incident response is to be feasible. Every tool call, every credential use, every policy decision should be durable and queryable. The audit gap documented across enterprise AI deployments today is what converts a contained incident into a weeks-long forensic reconstruction exercise.
Shadow AI and shadow MCP discovery close the final gap. Governed deployment is only as effective as the coverage of the governed layer; ungoverned access is the hole that policy and audit cannot close from inside the perimeter. The platform has to surface what is operating outside it, or the governance is cosmetic — worse than no governance at all because it produces false confidence.
Speakeasy's AI control plane addresses these requirements as a unified governed layer: credential custody, RBAC through existing identity providers, real-time threat detection covering both prompt injection and secrets in transit, MCP server governance, and full observability across agent workflows. The design premise is that enterprises should be able to extend AI access across the workforce without requiring every team to independently solve the same secrets problem, and without discovering they failed to solve it during a breach.
