Shadow AI coding tools are widening the enterprise governance gap

At a glance

What this is: Shadow AI coding tools are expanding unsanctioned AI use in development, with Knostic arguing that fast adoption is outpacing enterprise visibility and control.

Why it matters: IAM, PAM, and AI security teams need to treat developer-used AI tools as governed access paths because unmonitored prompts, plugins, and agents can move data and actions outside policy boundaries.

By the numbers:

• 75% of developers regularly use AI assistance tools, according to Knostic.
• 92% of U.S.-based developers at large companies report using AI coding tools at work or in their personal time, according to Knostic.

Context

Shadow AI coding tools are unsanctioned AI assistants, plugins, agents, and browser services used inside development workflows without enterprise visibility or governance. The security problem is not simply that developers want faster coding help, but that the resulting prompts, code suggestions, file access, and external tool calls can occur outside approved identity and policy boundaries.

This matters because development environments now behave like a parallel control plane for data and execution. When AI tools are easy to install and hard to inventory, traditional approval workflows, logging, and access review models lose effectiveness, especially where IDE extensions, MCP servers, and browser-based agents can act with broad local privileges.

The result is a familiar governance pattern in a new form: convenience wins, controls lag, and hidden access grows faster than security teams can classify it. In practice, this is most visible in organisations where sanctioned AI paths are slow or incomplete and developer workarounds become the default.

Key questions

Q: What breaks when shadow AI tools are approved without continuous monitoring?

A: Approval without monitoring leaves a gap between the policy on paper and the tool in production. Tools can change data access, gain new integrations, or add agentic features that expand their blast radius after approval. Without ongoing checks, security teams lose visibility into drift and may keep using a policy that no longer matches reality.

Q: Why do AI systems create risk even when an organisation has formal governance and compliance in place?

A: Formal governance reduces legal exposure, but it does not eliminate operational risk. AI systems create danger when sensitive data is over-shared, access is too broad, or employees bypass approved processes. The risk often sits in the interaction between people, data, and tools, which means organisations need continuous control testing, not just policy alignment.

Q: What are the signs that shadow AI is spreading in development teams?

A: Common signals include personal AI accounts in IDEs, unapproved browser extensions, unmanaged MCP servers, repeated use of external assistants in code reviews, and developers bypassing sanctioned tools because they are slower. The pattern often shows up first as convenience-driven workarounds before it appears in formal security telemetry.

Q: Should security teams prioritise approved AI tools or enforcement first?

A: They should do both, but adoption usually improves when approved tools arrive first. If security only blocks shadow usage, developers will route around the controls. A practical programme combines a safe catalog, clear policy boundaries, and enforcement for high-risk tools so the secure path is also the fast path.

Technical breakdown

Why shadow AI tools bypass normal governance

Shadow AI emerges when developers can add assistants, extensions, and agent surfaces faster than security can approve, inventory, or observe them. The technical issue is not only tool sprawl. It is that AI features now sit inside browsers, IDEs, local workstations, and MCP-connected workflows, each with different trust assumptions and no common audit boundary. That breaks conventional software approval models because the control point moves from central procurement to per-user installation and per-session usage. Once an assistant can read files, send prompts, or invoke external services, the enterprise has already lost the assumption that usage is visible by default.

Practical implication: Security teams need governance at the point of installation and execution, not only at procurement or software review.

How unmonitored agents and plugins expand the attack surface

AI agents and plugins are not just content helpers. They can read code, open files, execute commands, call APIs, and chain actions across tools. That means an unverified extension or MCP server can become a high-privilege execution path inside a developer workstation or CI-connected environment. The risk is compounded when the tool can inherit the user’s context and reach into repositories, credentials, and external services without separate approval. In identity terms, the tool becomes a non-human actor operating under human access, which makes ownership, attribution, and revocation much harder once behaviour becomes shared across accounts and environments.

Practical implication: Treat AI assistants, extensions, and agents as identity-bearing execution paths that require scoped permissions and explicit ownership.

Why visibility, logging, and redaction are the control gap

The core governance failure is not just shadow usage. It is the absence of durable evidence about what the tool saw and did. Without logs, teams cannot tell whether prompts contained secrets, whether generated code introduced insecure dependencies, or whether an agent touched files it should not have accessed. Redaction matters because developers routinely paste sensitive material into assistants, and once that data leaves the controlled environment, the enterprise may lose the ability to prove where it went. In practical terms, the technical gap is auditability: if the organisation cannot reconstruct AI-assisted actions, it cannot govern them.

Practical implication: Require prompt logging, secret redaction, and action-level audit trails for every sanctioned AI development tool.

Threat narrative

Attacker objective: The objective is to gain durable, unobserved access to sensitive development data and execution paths that can be abused for leakage, code manipulation, or supply-chain compromise.

1. Entry occurs through one-click installation of browser assistants, IDE extensions, MCP servers, or personal AI accounts inside the development workflow.
2. Credential and data exposure follow when developers paste secrets, source code, customer information, or architecture details into tools the enterprise does not monitor.
3. Impact appears as invisible code changes, untracked agent actions, ungoverned dependency use, and compliance gaps that security teams may only discover after damage has spread.

Breaches seen in the wild

• JetBrains GitHub plugin token exposure: A flaw in the JetBrains GitHub plugin could send IDE users' GitHub tokens to an attacker via a crafted pull request. Fixed; tokens to be revoked.
• Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.

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

Shadow AI in development is now an identity governance problem: once AI assistants, plugins, and agents sit inside everyday build workflows, the issue is no longer only software approval. It becomes control over who or what can act, what data it can see, and whether those actions are attributable. That makes AI-assisted development a non-human identity governance challenge, not just a tooling preference. Practitioners should treat every sanctioned AI path as an access pathway that needs ownership, scope, and revocation.

Approved AI catalogs are necessary, but cataloguing alone does not solve governance debt: if sanctioned tools do not materially outperform the shadow alternatives in speed and usability, developers will keep bypassing them. The article correctly shows that friction is the enemy of compliance. That means governance has to be designed around developer experience, with clear tiers, logged access, and fast approval pathways that make the secure option the default.

Invisible agent actions create an audit gap that conventional SDLC controls were not built to close: source control, code review, and change management assume the work product is visible and reviewable after the fact. AI agents can generate, edit, and execute inside a single session, leaving little for retrospective review if logging is missing. That is a governance assumption failure, and teams should move controls to issuance time and execution time rather than relying on downstream review.

Shadow AI expands the attack surface by turning local convenience into distributed trust: every unvetted extension, MCP server, or browser assistant becomes part of the enterprise's effective control plane. In practice, this widens the boundary around identity, secrets, and code integrity without formal approval. Security leaders should respond as if the developer workstation has become a policy enforcement zone, because that is where many of these risks now begin.

Shadow AI governance debt: the longer organisations tolerate unapproved AI use, the more the unofficial workflow becomes the real workflow. That creates a second, unmanaged policy layer that eventually outgrows the sanctioned one. Practitioners should prioritise discovery and safe enablement together, otherwise the gap between policy and practice will keep widening.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Shadow AI governance debt: once developer teams build around unsanctioned assistants and extensions, the enterprise inherits a second control plane that lives outside normal review. The longer that shadow layer persists, the harder it becomes to align policy, logging, and ownership with how work actually gets done.

Enterprises should expect AI-assisted development to behave like a discovery problem as much as a policy problem. Security leaders need inventory, redaction, and execution control at the same time, or the organisation will keep finding AI usage only after it has already influenced code, data, or access.

For practitioners

• Build an approved AI catalog Create a tiered inventory of sanctioned assistants, IDE integrations, browser tools, and approved MCP servers so developers can choose safe options without guessing.
• Enforce logging for AI-assisted development Require prompt capture, redaction, and action-level audit trails for every approved assistant, extension, or agent used in code workflows.
• Restrict unverified extensions and MCP servers Block unknown repositories, personal accounts, and unmanaged agent backends from developer environments unless they meet explicit policy and authentication requirements.
• Treat secrets as disallowed prompt content Prevent API keys, source snippets, customer records, and architecture diagrams from being pasted into external AI tools, even when the developer is trying to move quickly.
• Train developers on AI misuse paths Teach teams how prompt leakage, insecure code suggestions, and unsanctioned tool installs create governance and security exposure in everyday workflows.

Key takeaways

• Shadow AI in development is widening the gap between developer behaviour and enterprise governance, especially where tool adoption is fast and controls are slow.
• The main risk is not just productivity loss. It is invisible access, unlogged prompts, unsafe code generation, and unmonitored plugin or agent behaviour.
• Security teams need approved AI options, execution logging, and prompt-level controls so developers can use AI without pushing sensitive activity outside auditable boundaries.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• 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.
• AI-assisted development: A development workflow where an AI system helps generate, refactor, test, or execute code inside the software delivery process. The security issue is not the assistance itself, but that the tool may operate in trusted contexts that also contain credentials, infrastructure access, and other sensitive assets.
• Prompt Leakage: The unintended exposure of user prompts, system prompts, or tool output from an AI runtime. In NHI terms, prompt leakage matters because those strings often carry sensitive instructions, credentials, or business context, and they may be stored in memory, logs, or exported artifacts.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes that must govern AI-assisted workflows.