TL;DR: Shadow AI is expanding across engineering teams because 75% of developers now use AI assistants regularly, while 43% of workers admit to plugging sensitive work information into AI tools, according to the source article and Asisonline. The security model breaks when unsanctioned AI use creates unlogged data egress, traceability gaps, and unreviewed code paths that governance never sees.
NHIMG editorial — based on content published by Knostic: Key Findings on Shadow AI Risks
By the numbers:
- A 2024 Stack Overflow Developer Survey shows that 75% of developers now use AI assistants regularly.
- Independent research from Asisonline shows that 43% of workers plug sensitive work information into AI tools.
Questions worth separating out
Q: How should security teams control shadow AI use in development environments?
A: Security teams should control shadow AI by treating it as an unsanctioned data and identity path, not just an app choice.
Q: Why does shadow AI create compliance risk even when developers are trying to be productive?
A: Shadow AI creates compliance risk because prompts can contain regulated data, source code, or architecture details that leave the organisation’s approved processing boundary.
Q: What breaks when AI-assisted code is merged without provenance controls?
A: When AI-assisted code is merged without provenance controls, teams lose attribution, review evidence, and incident reconstruction capability.
Practitioner guidance
- Map unsanctioned AI entry points Inventory where developers are already using external AI tools, browser extensions, IDE plugins, and agents, then classify each route by the data types it can see and move.
- Block sensitive prompt content at the boundary Apply prompt filtering, DLP rules, and monitored gateways so code, credentials, personal data, and architecture details do not leave approved environments unchecked.
- Require provenance for AI-assisted code Tag AI-generated or AI-rewritten changes in commit metadata, enforce signed commits, and make provenance a merge requirement for high-risk repositories.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step controls for detecting shadow AI use in IDEs and CI/CD workflows.
- The article's full risk matrix for mapping governance, technical, and tooling controls to each shadow AI failure mode.
- Specific examples of runtime enforcement for plugins, extensions, and agent permissions.
- The vendor's detail on how Kirin validates MCP servers and inspects developer telemetry for unsafe behaviour.
👉 Read Knostic's analysis of shadow AI risks in development pipelines →
Shadow AI in DevSecOps: what governance gaps teams are missing?
Explore further
Shadow AI is a governance failure before it is a tooling problem. The central issue is that developers can create a parallel approval path outside sanctioned identity, code, and data controls. Traditional IAM sees the developer account, but not the unsanctioned AI system receiving the sensitive context. Practitioners should treat shadow AI as an identity and workflow governance gap, not an isolated productivity choice.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security & ESG.
A question worth separating out:
Q: Who is accountable when shadow AI causes a data leak or insecure deployment?
A: Accountability sits with the organisation that allowed the unapproved tool path, not with the model itself. Security, engineering, and governance teams all need clear ownership for approved tools, sensitive data rules, and code provenance. Without named ownership, shadow AI becomes an unmanaged exception rather than a controllable risk.
👉 Read our full editorial: Shadow AI in development pipelines is breaking governance models