AI supply chain secret sprawl exposes a new governance gap

At a glance

What this is: This analysis explains how AI-assisted development creates secret sprawl across the software supply chain and why storage-centric secrets management no longer contains the exposure path.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern how credentials enter, move through, and leave AI development workflows, not just where they are stored.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Knostic's analysis of AI supply chain secret sprawl and mitigation patterns

Context

AI supply chain secret sprawl is the uncontrolled spread of credentials across AI-assisted development tools that ingest, transform, and re-share context. The governance gap is that these tools can move secrets into logs, prompts, histories, and generated code even when developers never intended to expose them.

Traditional secrets management assumes the main problem is storage and rotation. In AI-enabled workflows, the harder problem is exposure control across IDEs, MCP servers, coding agents, and browser assistants, where a single secret can be copied into multiple systems before anyone notices.

This is why the topic sits squarely inside NHI governance. The credential may begin as a conventional secret, but once AI tooling consumes it, the identity boundary expands into a multi-hop trust chain that security teams rarely own end to end.

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 coding tools make secret management harder?

A: Because secret management tools mainly control storage and rotation, while AI tools create additional exposure paths. Once a secret is read into context, it can be reused, cached, or echoed by multiple systems, so the organization must govern movement as well as storage.

Q: How do security teams know if secret sprawl is actually under control?

A: Look for fewer plaintext secrets in developer-accessible locations, lower duplication across repositories and transcripts, and faster invalidation of exposed credentials. If secrets remain valid for weeks after discovery, the programme is detecting exposure without reducing operational risk.

Q: Who is accountable when an AI tool leaks a secret into logs or prompts?

A: Accountability should sit with the team that owns the AI workflow, the secret lifecycle, and the downstream systems that store context. If ownership is split across development, platform, and security teams, exposure tends to persist because no one controls the full propagation chain.

Technical breakdown

Why AI development tools create multi-hop secret propagation

Modern AI development tools do more than read code. IDE extensions, coding agents, MCP servers, and browser assistants ingest workspace context, environment variables, logs, and file metadata to improve their output. That context often includes API keys, tokens, certificates, and other secrets. The risk is not just that one tool sees a credential. It is that the credential can be re-encoded into prompts, cached state, logs, generated snippets, and shared transcripts, making the original exposure difficult to trace or revoke. This is a supply chain problem because each tool becomes a propagation point, not a simple consumer of data.

Practical implication: Map every AI-enabled hop that can ingest or emit secrets, then treat each hop as a control point for redaction, logging, and policy enforcement.

Why vaults do not solve AI toolchain exposure

Secrets vaults are designed to issue, store, and rotate credentials. They are not designed to prevent a token from being copied into a prompt, surfaced in an editor buffer, or persisted in an agent transcript. Once a secret leaves the vault and enters AI context, the problem shifts from storage security to exposure governance. That means the primary failure mode is duplicate propagation, not weak vault encryption. The practical distinction matters because rotation after the fact does not remove every copy already embedded in tool outputs, generated files, or remote histories.

Practical implication: Use vaults, but pair them with context filtering and secret scanning that operate before AI systems can duplicate credentials.

How MCP servers and coding agents amplify exposure

MCP servers sit between models and backend tools, which makes them powerful and risky. They often run diagnostics, execute commands, and return structured output that can include environment variables or configuration values. Coding agents then read that output, summarise it, and may reuse embedded secrets when modifying files. This creates a chain where one debugging action can turn into many credential copies. The danger is not only accidental disclosure but also persistence, because every copy expands the cleanup surface and increases the chance of later reuse by other tools or people.

Practical implication: Restrict what MCP servers can echo and what agents can access, especially in error paths, debug modes, and generated artifacts.

Threat narrative

Attacker objective: The objective is to obtain reusable credentials that can be exploited for unauthorized access, data exfiltration, or further supply chain compromise.

1. Entry occurs when a developer pastes a live secret into an AI-enabled editor, MCP workflow, or browser assistant during routine work.
2. Credential access follows when the tool ingests workspace context, stores the value in prompt history, logs, or shared state, and duplicates it across systems.
3. Impact occurs when the replicated secret is reused, exposed, or discovered later in code, logs, or collaboration tools, extending the blast radius beyond the original environment.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret sprawl is now an AI supply chain governance problem, not a vaulting problem. The article shows that secrets are duplicated by tools that ingest context automatically, which means the exposure path extends beyond where credentials are stored. Vaults still matter, but they no longer define the whole control surface. Practitioners should treat every AI tool that can read or write context as part of the identity boundary.

Non-consensual credential duplication is the right named concept for this risk. The important issue is not that a secret exists in one place, but that AI tooling can replicate it into places the owner never intended. That changes cleanup, attribution, and revocation from a single event into a propagation management problem. Security teams should redesign governance around how credentials spread, not just how they are issued.

OWASP NHI guidance fits this problem better than traditional secrets hygiene alone. The pattern aligns with overexposure, overprivilege, and lifecycle gaps that show up whenever machine identities are allowed to move through too many tools. The fact that AI systems ingest context makes least privilege an execution-time concern, not just a provisioning-time one. Practitioners should align NHI governance to the AI development path, not only to the secret store.

Secret scanning must move from repository hygiene to workflow enforcement. The article’s failure scenarios show that detection after commit is too late when the secret already entered prompts, logs, or remote assistant state. That creates a governance lag between exposure and response. Teams should assume the first durable copy may be the one created by the AI system, not the original human action.

AI-assisted development collapses the old boundary between developer convenience and identity risk. The more context a tool consumes, the more likely it is to become an ungoverned credential relay. This does not make every AI tool malicious, but it does make the development stack a higher-value target for accidental leakage and later abuse. Practitioners should reclassify AI toolchain exposure as an identity control domain, not just a developer productivity issue.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• That trend reinforces why the Guide to the Secret Sprawl Challenge is the right next resource for teams building operational controls around exposure rather than storage alone.

What this signals

Non-consensual credential duplication: AI development tools are not just consuming context, they are creating additional credential copies that extend your risk window across code, logs, and prompts. For IAM and NHI teams, that means the control objective shifts from preventing storage to preventing replication, with upstream redaction and policy enforcement becoming first-class governance tasks.

With 28% of secrets incidents now originating outside code repositories, according to GitGuardian's 2026 data, the operational boundary has clearly moved into chat, documentation, and AI-assisted workflows. Teams that only scan source control will keep missing the places where secrets now begin their lifecycle.

The programme signal is straightforward: if your secret invalidation workflow cannot keep up with context duplication, then your AI development stack is functioning as a secret amplifier. The right response is to tie scanning, revocation, and AI access boundaries together in the same operating model.

For practitioners

• Eliminate plaintext secrets from AI-accessible paths Remove API keys, tokens, and certificates from .env files, editor buffers, shared snippets, and any repository content that AI tools can ingest. Replace long-lived values with scoped credentials and shorten their usable lifetime wherever practical.
• Redact prompts and tool outputs before model ingestion Apply policy controls that strip secrets from IDE context, MCP responses, logs, and browser-based assistant prompts before they reach an LLM. Redaction has to happen upstream of the model, not after the output is generated.
• Scope MCP and agent access to the minimum context needed Constrain which files, variables, repositories, and environments AI tools can read, and disable verbose debug output in production-like workflows. The goal is to prevent a single diagnostic action from becoming a multi-system propagation event.
• Integrate secret scanning into the development workflow Scan commits, pull requests, build outputs, and generated files continuously so secret exposure is detected at the same point it is created. Pair scanning with revocation automation so exposed credentials are not left valid for weeks.
• Review AI toolchain logging and retention settings Audit where IDE extensions, MCP servers, coding agents, and browser copilots store histories, cached state, and transcripts. If the system retains context by default, assume secrets can persist outside normal security controls.

Key takeaways

• AI-assisted development creates a propagation problem, not just a storage problem, because secrets can be duplicated across tools without developer intent.
• The scale is already material, with millions of hardcoded secrets and long-lived leaked credentials still exploitable long after discovery.
• Practitioners should govern the AI toolchain as part of the identity boundary, using redaction, scoped access, and automated revocation together.

Key terms

• Secret Sprawl: Secret sprawl is the uncontrolled duplication and movement of credentials across tools, logs, prompts, and repositories. In AI-assisted development, the problem is not only where secrets are stored, but how quickly they are copied into new places that normal vaulting and rotation workflows do not see.
• Context Window Exposure: Context window exposure is the risk created when sensitive data enters the input context of an AI system and can later appear in outputs, logs, or persisted history. It matters because the model may not be the only place the data exists once the workflow starts processing it.
• Credential Propagation: Credential propagation is the spread of a secret from one system into multiple downstream systems through automation, logging, caching, or re-use. For AI workflows, propagation is the real control problem because a single secret can become many copies before anyone knows it was exposed.
• Mcp Server: An MCP server is a backend component that exposes tools and data sources to AI systems through the Model Context Protocol. In practice, it can become a high-risk relay point if it returns environment variables, debug data, or other sensitive context that a model can ingest and persist.

What's in the full article

Knostic's full article covers the operational detail this post intentionally leaves for the source:

• Real-world failure scenarios showing how secrets propagate through Cursor, MCP servers, and AI assistants
• Implementation guidance for eliminating plaintext secrets from AI-accessible development paths
• Practical mitigation patterns for scoped tokens, redaction boundaries, and workflow-integrated secret scanning
• Product-specific handling of live prompt, output, and history filtering in the AI development stack

👉 The full Knostic article covers the failure scenarios, propagation paths, and mitigation details behind AI supply chain secret sprawl.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.