TL;DR: AI-assisted development tools can duplicate and move secrets across IDEs, MCP servers, coding agents, and browser assistants without developer intent, creating multi-hop exposure that traditional vaulting cannot contain, according to Knostic. The real control problem is exposure governance, not storage hygiene, because once secrets enter AI context they can spread faster than teams can revoke them.
At a glance
What this is: This is an analysis of how AI-assisted development workflows spread secrets across the toolchain, with the key finding that traditional secrets management breaks once credentials enter AI context.
Why it matters: It matters because IAM, PAM, and NHI teams need to govern where secrets can flow, not just where they are stored, or AI tools will multiply exposure faster than revocation can keep up.
Context
AI supply chain secret sprawl is the uncontrolled movement of credentials through development tools that read, copy, and forward more context than developers intend. In this article, Knostic argues that the problem is not limited to vault hygiene. It is a governance gap created when IDEs, MCP servers, coding agents, and browser assistants all become secret-processing layers at once.
The security failure mode is exposure, not storage. Once a token, key, or environment variable enters an AI toolchain, it can be duplicated into logs, prompts, generated code, transcripts, and remote state, which means conventional secrets management sees only the original location and misses the propagation path.
That makes this a cross-functional identity problem for NHI teams, application owners, and developers. The subject is still the credential, but the control boundary now spans the full AI-assisted workflow rather than a single repository or vault.
Key questions
Q: What breaks when secrets are allowed into AI development workflows?
A: Secrets stop behaving like isolated credentials and start behaving like replicated content. AI tools can copy them into prompts, histories, logs, and generated code, which multiplies the cleanup surface and extends exposure beyond the original system. The practical failure is propagation, not just disclosure.
Q: Why do AI observability workflows increase the risk of credential exposure?
A: Because observability data often contains bearer tokens, API keys, and connection strings that were never meant for model processing. Once an agent can read the full diagnostic conversation, the prompt becomes a path for secret transfer rather than a neutral troubleshooting input.
Q: What are the signs that secret sprawl is already happening in an AI toolchain?
A: Warning signs include repeated secrets across repositories, unexpected credentials in logs or generated files, verbose MCP or assistant outputs containing environment data, and developers pasting live values into prompts for convenience. If a secret appears in more than one tool boundary, the exposure model has already expanded beyond the original source.
Q: How should security teams handle secrets for coding agents?
A: Security teams should move from static secret placement to runtime delivery, using just-in-time injection, narrow scoping, and task-specific access. Coding agents should receive only the credentials they need for the current execution path, with separate handling for each environment. That approach reduces persistence, limits reuse, and makes least privilege operational instead of theoretical.
Technical breakdown
How AI toolchains propagate secrets across layers
Modern AI development environments do not treat credentials as isolated values. They ingest workspace structure, configuration files, command history, logs, and environment variables to improve model output and automation quality. When an IDE extension, MCP server, or coding agent reads that context, the secret can be copied into another layer such as a remote assistant state, a transcript, or a generated code snippet. That is why the exposure is multi-hop: one value can become several durable copies without a malicious actor ever touching the original vault. The technical problem is not simply leakage at rest. It is uncontrolled redistribution during context processing.
Practical implication: control what AI tools are allowed to ingest, not just what your vault can issue.
Why vault-centric secrets management misses the real risk
Vaults are built to control storage, issuance, and rotation, but they do not govern every place a secret can appear after retrieval. In AI-assisted workflows, a secret may be pulled into a prompt, echoed in an error response, cached in a browser assistant, or written into generated files. At that point, the credential has left the vault domain and entered an unbounded exposure domain. This is why a single well-managed secret can still create a broad attack surface. The control failure is architectural: the security model assumes the vault is the last place the secret needs protection.
Practical implication: extend governance to prompts, tool outputs, logs, and generated artefacts.
Why MCP servers and coding agents amplify secret sprawl
MCP servers sit between the developer experience and backend services, often with access to environment variables and operational outputs. Coding agents increase the risk further because they can read, rewrite, and replicate values across files and directories as part of routine assistance. If either layer handles verbose diagnostics or broad workspace context, the result is credential propagation disguised as productivity. The risk is not that these tools are inherently malicious. It is that they are designed to move context, and secrets look like context to them. That makes privileged AI-assisted workflows a propagation engine unless tightly bounded.
Practical implication: treat MCP outputs and agent file access as secret-bearing surfaces requiring explicit boundaries.
Threat narrative
Attacker objective: The attacker objective is to obtain reusable credentials that can be exploited across development systems, cloud services, or third-party AI workflows.
- Entry occurs when a developer pastes a live credential into an AI-enabled IDE, MCP workflow, or browser assistant during normal work.
- The credential is then ingested into assistant context, logs, remote state, or generated output, creating multiple copies beyond the original location.
- Propagation continues when downstream tools reuse or forward that context into code, transcripts, or collaboration systems, widening the exposure surface.
- Impact is achieved when the replicated secret becomes available to attackers, third parties, or future workflows that were never meant to receive it.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Exposure governance is now the primary control problem in AI-assisted development. The article shows that secrets no longer fail only at storage or rotation. They fail when AI tooling turns a single credential into a chain of copies across prompts, logs, transcripts, and generated files. That shifts the governance question from where secrets live to where they are allowed to flow, and practitioners should treat that as a distinct control boundary.
Secret management assumptions were built for retrieval, not redistribution. Traditional NHI controls assume a credential can be issued, monitored, and revoked within a bounded system. AI toolchains violate that assumption by copying context across layers that no single team owns. The implication is that credential governance now needs contextual containment across IDEs, MCP servers, agents, and browser assistants, not just a stronger vault policy.
AI-assisted workflows create identity blast radius, not just secret sprawl. Once a secret is ingested by one tool, the downstream copies expand the number of places where the same identity can be abused. That makes blast-radius analysis more useful than counting exposed values in isolation. Practitioners should evaluate every AI integration by how far a credential can travel after first exposure.
Non-human identity governance must extend to context carriers as well as authenticators. The article’s real lesson is that the most dangerous actors are not only service accounts or API keys but the systems that move their context. This is where OWASP-NHI style thinking becomes practical: if an AI layer can copy, persist, or forward a secret, it is part of the identity governance surface and must be treated accordingly.
Secret sprawl in AI development is a supply chain problem with identity consequences. The chain now includes IDEs, assistants, MCP servers, cloud copilots, and browser integrations. That broadens accountability and makes governance across human, NHI, and autonomous-assisted workflows inseparable. Security teams should think in terms of end-to-end exposure paths, not isolated product categories.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
AI supply chain secret sprawl is really a control-boundary problem. Development teams have added assistants faster than they have defined where secrets may travel. The next governance step is to treat prompts, logs, and generated artefacts as part of the credential lifecycle rather than as harmless by-products.
Credential propagation is the better lens than leak detection. Leak detection finds the first exposure, but AI workflows create secondary and tertiary copies that outlive the original event. That means incident response for AI-assisted development needs exposure tracing, not just secret rotation.
Context redaction and scoped ingestion are now architectural controls. If an AI tool can read everything it can reach, then least privilege must apply to context, not only to execution. This is where identity governance, secrets hygiene, and AI workflow design converge for practitioners.
For practitioners
- Eliminate plaintext secrets from AI-reachable paths Remove live credentials from .env files, command history, configuration directories, and copied snippets that AI tools can ingest during routine development.
- Scope tokens to the narrowest possible use Replace long-lived keys with scoped, short-lived credentials so any credential that is duplicated has limited value outside its intended task.
- Redact secrets before prompts and tool outputs Add controls that strip tokens, API keys, and environment variables from prompts, logs, and MCP responses before they reach models or assistants.
- Add secret scanning to AI-assisted development workflows Scan repositories, IDE outputs, and generated files continuously so replicated secrets are caught where propagation occurs, not only where they started.
- Restrict AI tool access to files and contexts on need to know Limit which workspaces, variables, and repositories an assistant or agent can read so one exposed secret cannot traverse the full development surface.
Key takeaways
- AI-assisted development changes secret handling from a vault problem into an exposure governance problem across the full toolchain.
- AI context can duplicate a single credential into multiple systems, which makes propagation harder to contain than the original leak.
- Practitioners need controls that bound ingestion, redact sensitive context, and reduce the value of any secret that does escape.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on secrets moving into AI tools and being exposed across the development supply chain. |
| NHI-05 — Overprivileged NHI | AI assistants, MCP servers, and coding agents often see more context than they need to do their task. | |
| NHI-07 — Long-Lived Secrets | Long-lived keys become high-risk once AI workflows can duplicate them into many persistent locations. | |
| Recommendation — Apply NHI-02 to scan AI-reachable paths and remove exposed secrets before they propagate. Limit AI tool access to the minimum files, variables, and repositories needed for each workflow. Replace long-lived credentials with scoped, short-lived secrets wherever AI tooling can access them. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article describes repeated exposure and reuse of credentials as the central threat pattern. |
| Recommendation — Map AI workflow secret leakage to TA0006 and hunt for paths that expose reusable credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The governance gap is about controlling which AI tools may access which secrets and contexts. |
| Recommendation — Use PR.AA-05 to enforce entitlement boundaries around AI assistants, MCP servers, and developer tooling. | ||
Key terms
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Exposure-led governance: Exposure-led governance is the practice of managing identity by the risk that access creates rather than by the volume of work completed. It shifts executive reporting toward ownership, privilege quality, and revocation speed across human and non-human identities.
- Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org