Shadow AI risk is outpacing AppSec visibility and governance

At a glance

What this is: This guide explains how shadow AI creates unmanaged AI use across browsers, sanctioned platforms, and code paths, and why AppSec controls miss it when they rely on inventories alone.

Why it matters: It matters because security teams need joined-up visibility across identity, network, and code to govern AI access, especially where personal accounts, API keys, and agent instructions bypass normal review.

By the numbers:

• 80% of workers use AI tools their organization hasn’t approved, according to Unseen Security’s 2026 State of Shadow AI report.
• 86% of organizations say they lack visibility into how data actually flows to and from the AI tools already in use.
• Zscaler’s ThreatLabz team analyzed 536.5 billion AI and machine learning transactions across its cloud and recorded a 3,464.6% year-over-year increase in enterprise AI/ML traffic.

👉 Read Xygeni's analysis of how to detect and eliminate shadow AI

Context

Shadow AI is the use of AI tools, models, agents, or API calls inside an organisation without security or IT review. The primary risk is not just unsanctioned usage, but the fact that modern AI can appear in a browser, inside approved software, or directly in code without leaving the procurement trail that traditional shadow IT controls expect. That makes shadow AI risk a governance problem as much as a technical one, especially where AI touches credentials, datasets, and repository access.

For AppSec and identity teams, the challenge is that visibility must now span three layers at once: who is using the AI, what service or model is being called, and where that call is embedded in the software supply chain. Without that intersection, teams can detect usage but still miss the agent, token, or instruction set behind it. This is now a mainstream enterprise pattern, not an edge case.

Key questions

Q: How should security teams govern Shadow AI in everyday browser use?

A: Security teams should govern Shadow AI by enforcing controls where users actually interact with AI tools, not only at the network edge. That means browser-level inspection, content classification, and policy enforcement for paste, upload, and prompt actions. If users can move sensitive data into an AI tool without a control decision, the governance model is incomplete.

Q: Why do personal accounts and API keys make shadow AI harder to control?

A: Because they bypass the normal identity and procurement signals that most governance processes depend on. A user can interact with an AI tool through a personal login, or a developer can wire in an API key directly from code, and both patterns can create unmanaged access without triggering standard review paths.

Q: What breaks when AI assets are tracked separately from repositories and pipelines?

A: You lose the relationship context that explains real exposure. A model, dataset, or agent may look harmless in isolation, but its risk changes when it can reach a repository, call an external service, or consume sensitive data. Separate tracking turns AI governance into an incomplete inventory exercise.

Q: What should teams do if they discover shadow AI in the business?

A: Teams should first identify who owns the tool, what data it touches, and which identities it uses. Then they should either bring it under policy and lifecycle control or remove access to enterprise data until governance is in place. Discovery without containment simply confirms the scale of the gap.

Technical breakdown

Why shadow AI escapes traditional shadow IT detection

Traditional shadow IT detection depends on signals such as software installs, licenses, endpoint footprints, and procurement records. Shadow AI often bypasses all of them because it can run in a browser, hide inside sanctioned platforms, or be invoked through an API from code. The result is a control gap between what the organisation believes it has approved and what its users actually operate. That gap widens when identity systems, proxies, and repository scanners are not correlated into one view.

Practical implication: treat browser, identity, and code discovery as a single detection problem rather than three separate tools.

How AI agents and MCP servers create a new software supply chain surface

AI-specific assets such as agents, skill files, model endpoints, and MCP servers behave like dependencies, but they are often managed informally. An agent instruction file in a repository can determine which model is called, what data is exposed, and which external server is contacted. That means the risk is not just the model itself but the relationship graph around it. Once those relationships are invisible, teams can no longer tell whether a call is harmless experimentation or a path into sensitive systems.

Practical implication: map AI assets and their relationships into the same inventory as repositories, pipelines, and secrets.

Why enforcement has to sit at the point of install or API call

Policy documents and awareness training do not stop an AI action that is executed directly in code or through an agent workflow. Effective control has to move closer to the event itself, either by blocking an unapproved package during install or by denying a model call when the destination, identity, or payload violates policy. That is the same architectural logic used in high-assurance controls elsewhere in AppSec: prevention must happen where the action occurs, not after the fact.

Practical implication: enforce AI policy at package install, model invocation, and token use, not only in governance workflows.

Threat narrative

Attacker objective: The attacker aims to harvest sensitive data, abuse credentials, or pivot from unmanaged AI use into wider software supply chain access.

1. Entry occurs when users paste sensitive material into browser-based AI tools, wire up personal API access, or let embedded AI features activate inside sanctioned platforms.
2. Escalation happens when those tools gain access to corporate data, repositories, or service credentials through OAuth grants, hardcoded tokens, or agent instructions.
3. Impact follows when unreviewed AI paths expose sensitive data, expand supply chain exposure, or let agents act beyond intended scope.

NHI Mgmt Group analysis

Shadow AI is now an identity governance problem, not just an AppSec hygiene issue. The article shows that personal logins, OAuth grants, API keys, and embedded AI features all create an identity surface that conventional software inventory tools do not see. That means the control problem spans IAM, secrets governance, and code security at once. Practitioners should treat unmanaged AI use as an identity and access failure mode, not a mere policy exception.

AI asset sprawl creates a new form of governance debt. Once models, agents, datasets, MCP servers, and coding tools are tracked separately, the organisation loses the relationship context that determines real risk. That is the named concept here: AI governance debt. It accumulates when teams can name AI tools but cannot explain who approved them, what they can reach, or which data they touch. Practitioners should collapse those silos into one governable view.

Detection without enforcement is insufficient for shadow AI. Network logs and identity signals can tell you that AI is in use, but they do not stop an unapproved call or an agent action. The operational lesson is that security has to move to the boundary where install and execution happen. Practitioners should pair discovery with control points that can deny use automatically.

The software supply chain now includes AI-mediated execution paths. Agent instructions, skill files, and MCP connections can become as important as packages and libraries because they shape what code reaches outside the repository boundary. That broadens AppSec’s remit into AI runtime governance. Practitioners should audit AI instructions and dependencies with the same discipline applied to third-party code.

Shadow AI will keep outpacing annual review cycles. The article’s central warning is that AI adoption changes too quickly for point-in-time audits to remain reliable. The governance model has to be continuous, with ownership spanning security, engineering, and identity teams. Practitioners should move to ongoing discovery and policy enforcement rather than periodic cleanup.

What this signals

Shadow AI should be treated as a governance control gap that spans identity, application security, and data handling. The practical shift for programmes is from discovering tools after the fact to continuously correlating who used them, what they touched, and which code paths they entered. That is where NIST CSF 2.0 and NIST Cybersecurity Framework 2.0 help frame the control problem without narrowing it to a single technology layer.

AI governance debt: when AI assets, instructions, and dependencies are tracked separately, risk accumulates faster than review cycles can clear it. The only durable response is to bind identity signals to software inventory and make enforcement automatic at the point of install or call. For teams already struggling with secrets sprawl, the overlap with NHI Lifecycle Management Guide is obvious.

For practitioners

• Build a unified AI inventory Track models, datasets, agents, MCP servers, repositories, and developer tools in one inventory so relationship risk is visible, not inferred.
• Correlate identity and network signals Join OAuth grants, personal account sign-ins, proxy logs, and service-account activity so unapproved AI usage can be traced to a person or workload.
• Enforce policy at execution points Block unapproved AI packages during install and deny unauthorised model calls at the API layer rather than relying on policy documents alone.
• Review agent instructions and skill files Scan repository-stored instructions, skill files, and MCP references because they can redirect an agent into data or services no one intended to expose.

Key takeaways

• Shadow AI bypasses the visibility model that shadow IT controls were built for, which leaves browser use, embedded AI features, and code-level API calls under-governed.
• The biggest evidence gap is not whether AI is being used, but whether organisations can trace who used it, what it reached, and where the call originated.
• Continuous discovery plus execution-time enforcement is the control model that matters now, because annual reviews cannot keep pace with AI adoption.

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.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• 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 Asset Inventory: A living register of every AI-related asset in an organisation, including models, agents, datasets, notebooks, endpoints, and embedded AI services. It links technical detail to ownership, data exposure, lifecycle status, and controls so governance can operate on facts rather than assumptions.

What's in the full article

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

• Step-by-step detection logic for identifying shadow AI across browser, identity, and repository signals
• The relationship-graph model used to connect models, agents, datasets, MCP servers, and coding tools
• Operational guidance for blocking unapproved installs and API calls at the point of execution
• How the AI inventory and guardrail workflow maps findings into one risk view

👉 Xygeni's full guide covers the detection signals, enforcement points, and inventory model in more operational depth.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, machine identity security, and secrets management through the industry’s only accredited NHI security programme. It helps practitioners connect identity controls to the operational realities of modern AI and software supply chains.