FAQS
No items found.
Shadow AI detection is the practice of discovering and classifying the unsanctioned AI tools, agents, and embedded AI features that employees use inside an enterprise. It produces an inventory, sorts each entry into sanctioned or unsanctioned, and routes the result to a decision. Detection and enforcement are separate capabilities, so knowing what runs is not the same as controlling it.
Shadow AI detection runs as a pipeline rather than a scan, because discovery has to come before enforcement.
The scope covers AI tools, models, and agents, not just apps. It also includes AI features switched on inside software the company already approved.
An agent is an AI tool that acts on its own. Standalone agents deployed without IT visibility sit in scope, because they can operate autonomously on user devices.
Several names circulate for the same condition, including unsanctioned AI, unapproved AI, unmanaged AI, and shadow agent.
Zscaler's Zpedia also treats shadow artificial intelligence as a documented variant, a term that has come to represent more than hidden algorithms and unapproved AI systems.
One adjacent label worth searching on is AI sprawl.
Shadow IT is the deployment of any software, hardware, or information technology on an enterprise network without an IT department's approval, knowledge, or oversight. Shadow AI is the AI-specific subset of that category, narrowing the focus to AI tools, platforms, and use cases.
Shadow AI is harder to catch than shadow IT because it can run through approved SaaS applications, personal accounts, browser extensions, or direct API connections. The entry point has shifted from a new app, subscription, or device to a feature toggle inside software the company already approved.
Employees turn to unsanctioned AI when approved options feel too slow or insufficient. The adoption is usually good faith rather than malice.
Why shadow AI is a security risk
Shadow AI is a security risk for four reasons, and this is the list Microsoft's own agent-documentation leads with.
Unapproved AI also sidesteps the checks in frameworks like the NIST AI Risk Management Framework, the EU AI Act, or broader data privacy laws. A 2025 peer-reviewed survey frames this as a structural gap, because AI adopted in good faith lands outside the normal governing frameworks. The EU AI Act's Article 4 puts an AI-literacy duty on providers and deployers, and Chapters I and II have applied since February 2, 2025. The AI Act's AI-literacy duty is a duty of care, not a detection mandate, so no regulation requires you to run shadow AI detection.
Agents make the risk harder to bound:
How shadow AI detection works
Shadow AI detection works as a four-stage pipeline, detect, identify, classify, and route. The four-stage model is a synthesis for organizing the practice, not a standard published by any one source. Each stage draws on documented capabilities from real tools, and no stage makes the next one automatic.
As a sanity check rather than a model, Zscaler publishes its own practitioner sequence. The sequence establishes an approved baseline, audits software, browser, and cloud usage, monitors network destinations, reviews access and data movement, interviews teams, and makes review and remediation repeatable. It is a useful cross-check.
Detection is enumeration, not enforcement, which is why the stage comes first. Microsoft's deployment model for shadow AI data leak prevention makes discovery the first step. The goal is to understand which AI apps are used, who uses them, and whether sensitive data is shared. That step focuses on discovery and monitoring before any blocking actions. In practice, detection filters the cloud app catalog by the Generative AI category to see which AI apps are in use. Cloud data posture management then surfaces AI reports and an activity explorer to reveal whether sensitive data is being sent to those apps.
Identification resolves each finding to something concrete. Endpoint-resident agents are found by local artifact discovery rather than by network telemetry. Microsoft Defender for Endpoint automatically discovers supported local AI agents and MCP server configurations on onboarded devices, then surfaces them in its portal. The discovery covers agents that run from the command line, desktop apps, IDEs with agent features built in, VS Code extensions, and local agents built on the Claw framework. Counts only mean something once they are de-duplicated. Defender defines an agent as a user, a device, and an agent type, so the same tool in fifteen project folders on one device is a single entry.
Classification turns sightings into decisions. Defender for Cloud Apps provides a risk assessment for each discovered app to help you decide whether to sanction or unsanction it. You then tag apps as Sanctioned or Unsanctioned based on your organization's policy. NIST expects AI systems to be inventoried and resourced according to organizational risk priorities, so the inventory should be risk-prioritized rather than a flat list.
Routing applies to the decision. Marking an app unsanctioned in Defender for Endpoint can block it across onboarded devices, or your team can choose to warn and educate users instead of blocking. Browser-side enforcement works differently. You configure data loss prevention for the Edge browser and block other browsers, which stops users reaching unmanaged AI apps in any browser you do not manage. Agents are routed through device policy. Blocking a shadow AI agent, such as OpenClaw, creates a new Intune policy that propagates to all managed Windows devices enrolled in Intune. Intune is Microsoft's device management service.
Detection coverage and enforcement coverage are separate capabilities, and one published matrix makes the gap visible. For shadow AI agents in Microsoft 365, OpenClaw has both detection and blocking available. ChatGPT Desktop, Ollama Desktop, Poe Desktop, Claw/ZeroClaw, OpenCode, and Claude Desktop have detection available, but blocking is not available. Blocking applies only to managed Windows devices enrolled in Intune. The feature ships as a public preview under the Frontier preview program, so supported agents and behaviors can change before general availability. How long that takes depends on how Intune is configured in your organization, and the policy update can take anywhere from 15 minutes up to 8 hours to apply. The gap is not vendor-specific, because knowing an agent runs is not the same as being able to stop it.
Detection runs across several surfaces, each with its own signal. The table below lists each surface, what it reports, and what its own field set does not report.
No single surface reports the same field set as another, so your coverage depends on which surfaces you run. The catalog surface reports risk assessments and Sanctioned or Unsanctioned tags. The endpoint surface reports identity triples and MCP server details. The network surface reports destinations and byte counts. Enforcement coverage is a separate question, which is why detection and enforcement never appear as one capability.
A shadow AI finding is actionable only if the record carries the right fields. NIST treats the inventory as a named governance control, resourced according to organizational risk priorities. It also directs you to enumerate generative AI systems and adjust the inventory requirements to account for generative AI risks. Turning those priorities into a score is a separate discipline, and that is where AI risk management begins. A generative AI inventory entry carries data provenance, known issues, human oversight roles and responsibilities, intellectual property and sensitive data rights, and the underlying foundation models and access modes.
Three rules keep the record honest. Any exemptions for generative AI embedded in application software are defined in organizational policy. The traffic, user, and recent-activity fields populate only when Global Secure Access is enabled, so a sparse record can mean missing telemetry rather than missing AI. A finding records human oversight roles and responsibilities, and whether a named person owns the finding is a governance decision rather than a field.
Related terms frame where shadow AI detection sits. Detection produces an inventory, and the AI governance framework decides what the inventory is for.
Shadow AI detection is not a scan; it is the input to governance. Detection produces an inventory, the inventory feeds a governance framework, and the framework decides what is sanctioned. One thing a finding cannot express is the ownership decision. A record shows what ran and who used it, while naming an owner, setting a policy, and choosing a response are governance work.
To act on findings, enterprises fold the inventory into an AI tool management practice rather than a one-off scan. What you cannot govern is what you never found, so the durable takeaway is that detection supplies the record and the decision stays human.
Shadow AI detection is the practice of discovering and classifying the unsanctioned AI tools, agents, and embedded AI features that employees use inside an enterprise. It produces an inventory, sorts each entry into sanctioned or unsanctioned, and routes the result to a decision. Detection and enforcement are separate capabilities, so knowing what runs is not the same as controlling it.
Shadow AI detection works as a four-stage pipeline: detect, identify, classify, and route. The four-stage model is a synthesis for organizing the practice, not a standard published by any one source. Each stage draws on documented capabilities from real tools, and no stage makes the next one automatic.
Shadow IT is the deployment of any software, hardware, or information technology on an enterprise network without an IT department's approval, knowledge, or oversight. Shadow AI is the AI-specific subset of that category, narrowing the focus to AI tools, platforms, and use cases. Shadow AI is harder to catch than shadow IT because it can run through approved SaaS applications, personal accounts, browser extensions, or direct API connections.
Shadow AI is a security risk for four reasons, and this is the list Microsoft's own agent-documentation leads with. Unapproved AI also sidesteps the checks in frameworks like the NIST AI Risk Management Framework, the EU AI Act, or broader data privacy laws.
No single surface reports the same field set as another, so your coverage depends on which surfaces you run. The catalog surface reports risk assessments and Sanctioned or Unsanctioned tags. The endpoint surface reports identity triples and MCP server details. The network surface reports destinations and byte counts.
Any exemptions for generative AI embedded in application software are defined in organizational policy. The traffic, user, and recent-activity fields populate only when Global Secure Access is enabled, so a sparse record can mean missing telemetry rather than missing AI.
A shadow AI finding is actionable only if the record carries the right fields. A generative AI inventory entry carries data provenance, known issues, human oversight roles and responsibilities, intellectual property and sensitive data rights, and the underlying foundation models and access modes. A finding records human oversight roles and responsibilities, and whether a named person owns the finding is a governance decision rather than a field.
The AI Act's AI-literacy duty is a duty of care, not a detection mandate, so no regulation requires you to run shadow AI detection. The EU AI Act's Article 4 puts an AI-literacy duty on providers and deployers, and Chapters I and II have applied since February 2, 2025.
Most teams can spin up an agent. Few can deploy one their security team signs off on. Here's the framework that does both
Give them a Basecamp. Go from AI chaos to AI work, in minutes.
