Notifications
Clear all
Topic starter
09/07/2026 12:03 pm
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.
NHIMG editorial — based on content published by Knostic: AI supply chain secret sprawl and the governance gap in AI-assisted development
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.
Questions worth separating out
Q: What breaks when secrets are allowed into AI development workflows?
A: Secrets stop behaving like isolated credentials and start behaving like replicated content.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Knostic's analysis of AI supply chain secret sprawl and mitigation patterns →
AI toolchain secret sprawl: what IAM teams need to control?
Explore further
09/07/2026 12:04 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI supply chain secret sprawl exposes a new governance gap
