How to Detect Shadow AI: 8 Signals Beyond URL Blocklists

Last reviewed: 12 September 2026

Shadow AI detection sounds simple until you try to distinguish an AI interaction from ordinary business traffic. A list of ChatGPT, Claude, Gemini, and Perplexity domains will catch the obvious cases. It will miss AI features embedded inside applications employees already use every day.

Quick answer: To detect Shadow AI reliably, combine known AI endpoints with request and response characteristics, browser context, user and account identity, and policy status. Score those signals together. Use deterministic rules for clear cases and reserve an AI classifier for ambiguous events.

GitHub illustrates the problem. Visiting a repository is normal development activity; invoking an AI coding assistant may send source code to a model. Similar ambiguity appears in Microsoft 365, Gmail, Slack, Notion, IDE extensions, browser extensions, and SaaS products that add copilots without moving users to a separate domain.

The useful question is therefore not simply, “Is this an AI domain?” It is, “Does this interaction send organizational data to an AI system, under which identity and policy?”

Why URL Blocklists Miss Shadow AI

Domain intelligence gives security teams a fast, explainable first layer. It works well when traffic goes directly to a known model provider or standalone AI application. Coverage weakens when the same host supports both conventional and AI-powered workflows, an application changes its endpoints, or an employee reaches a model through an extension, API, agent, proxy, or embedded feature.

Catalog-based discovery also depends on catalog coverage. Microsoft, for example, documents application-level Shadow AI discovery alongside deeper inspection for prompt and MCP activity, describing them as complementary layers rather than interchangeable controls. That distinction supports a broader principle: application discovery can tell you where AI may be used, while interaction-level signals help establish what happened.

A production detector should therefore treat a domain match as evidence, not a verdict.

The Eight Signals for Detecting Shadow AI Traffic

1. Known AI Domains and Inference Endpoints

Maintain intelligence for known AI domains, inference endpoints, model-provider APIs, AI-specific subdomains, SaaS copilot paths, and agent or MCP services. A direct request to a well-known inference API can carry high confidence. A request to a broad productivity domain should carry much less.

Keep this intelligence versioned and record why an endpoint was classified. Endpoint evidence is valuable because it is fast, cheap, and auditable, but it should rarely be the only signal used to classify embedded AI.

2. Request Characteristics

Inspect the parts of a request that policy and privacy constraints allow you to process. Useful indicators can include:

• POST or WebSocket traffic to an application endpoint
• JSON fields associated with messages, prompts, roles, models, tools, temperature, or token limits
• Conversation history or structured tool calls
• Documents, images, or code attached to a generation request
• Payload sizes and timing consistent with interactive prompting

No single characteristic proves AI use. A large POST request might be a file upload or form submission. Confidence rises when prompt-like structure appears with an AI-associated endpoint, browser action, or model parameter.

3. Response Characteristics

Responses provide an independent set of clues. Many LLM applications use Server-Sent Events, WebSockets, or chunked delivery to display generated content incrementally. Sustained output after a prompt-shaped request can strengthen the classification.

Streaming alone is not an AI signature. Collaboration tools, analytics dashboards, and media services also stream. A detector should correlate response behavior with the request, destination, and user action rather than applying a binary rule.

4. Browser and Application Context

The browser can distinguish events that look identical at the network layer. It may know which page is active, which UI control initiated the call, whether a copilot panel is open, whether text or files are being submitted, and whether the user switched into an AI feature.

This context helps separate normal GitHub activity from a coding-assistant interaction, or ordinary document editing from a request to summarize the document with an embedded model. It is one reason comprehensive Shadow AI detection benefits from both network and endpoint context.

5. User, Device, and Department Identity

Traffic becomes actionable when it can be attributed. Correlate the event with the user, managed device, department, role, location, and applicable policy. The same AI tool may be approved for a product team using public data and prohibited for a legal team handling privileged material.

Identity also lets security teams move from a raw list of connections to questions about adoption, exposure, and policy exceptions.

6. Account and Tenant Context

Finding an AI service is not enough. An approved enterprise account can have contractual, retention, access, and administrative controls that a personal account lacks. The hostname may be the same in both cases.

Where supported, correlate session and tenant context with the organization’s approved-application inventory. Treat unknown account status as uncertainty rather than silently assuming that all access to an approved vendor is sanctioned.

7. Approval and Policy Context

Shadow AI is a governance classification, not merely a technical protocol classification. The detector needs to know which application, account, use case, data type, and user group are approved. That policy context determines whether a confirmed AI interaction is sanctioned, monitored, restricted, or blocked.

Maintain an inventory that covers browser tools, desktop applications, IDE extensions, APIs, agents, MCP servers, and AI features inside SaaS products. Assign owners and expiry dates to exceptions so yesterday’s approval does not become a permanent blind spot.

8. Behavioral Correlation Across the Session

The strongest detections often come from sequence rather than content: a user opens an AI panel, attaches a document, sends a prompt-shaped request, and receives incremental generated output. Each event may be ambiguous by itself. Together they form a much stronger explanation.

Correlate events within a bounded session and preserve the supporting evidence for every classification. Security analysts should be able to see which signals produced the result instead of receiving an unexplained score.

Build a Confidence Score Instead of a Binary Rule

A practical classifier can combine the signals into a weighted score:

Endpoint + Request + Response + Browser + Identity + Account + Policy + Behavior = AI interaction confidence

Weights should reflect evidentiary value. A verified inference endpoint and an explicit model identifier may contribute more than payload size. A copilot button click followed by a prompt-shaped request may contribute more than streaming by itself.

Do not force every event into an AI or non-AI bucket. An explicit unknown state reduces false confidence and gives engineering teams a measurable queue for improving detection.

Use an LLM Classifier Only for Ambiguous Events

Sending every interaction to another model can add cost, latency, compute load, privacy exposure, and a new dependency in the enforcement path. It can also make decisions harder to reproduce.

A more efficient pipeline is:

Deterministic rules → confidence scoring → constrained AI judge for the ambiguous middle

Pass the minimum features needed for classification, avoid sending raw sensitive content where metadata or locally derived features suffice, and log the judge version and rationale. As the deterministic library improves, the percentage of events requiring model-based classification should fall.

Privacy and Security Constraints for Traffic Inspection

Deeper inspection creates its own governance obligations. Prompt bodies and attachments may contain personal data, credentials, source code, health information, or legal material. Before inspecting content, define the lawful and authorized basis, employee notice, regional boundaries, access controls, retention, and redaction strategy.

Prefer metadata and locally computed features when they provide enough confidence. When payload inspection is required, minimize collection, protect telemetry, separate duties, and record exactly which components can access raw content. Detection should not create a second uncontrolled repository of sensitive prompts.

From Detection to Shadow AI Governance

Once an interaction is classified, security teams can answer questions that a blocklist cannot:

• Which AI applications and embedded features are employees using?
• Which accounts, tenants, and use cases are approved?
• Which departments are adopting new AI tools?
• Is sensitive information being submitted?
• Which providers receive organizational data?
• What was allowed, masked, monitored, escalated, or blocked?

Feed those events into a governance dashboard that preserves application, identity, policy, and enforcement context. The objective is a usable inventory and decision trail, not thousands of disconnected network alerts.

A Reference Architecture for Shadow AI Detection

The architecture can be summarized in one line:

Known intelligence → network signals → request and response patterns → browser context → identity and tenant → confidence score → AI fallback → policy action → audit evidence

Start with a representative traffic set and label it with security and application owners. Measure precision, recall, unknown rates, latency, and bypass paths separately. Include embedded copilots, personal accounts, extensions, APIs, agents, and encrypted or unmanaged routes in the test plan.

The hardest case is not a direct visit to a famous chatbot. It is AI functionality inside an otherwise legitimate application. A layered, evidence-based detector can identify those interactions without classifying every visit to the host application as Shadow AI.

Frequently Asked Questions

What is Shadow AI detection?

Shadow AI detection is the process of discovering AI applications and identifying AI interactions that occur without sufficient organizational visibility, approval, or policy control. Useful systems correlate the application with the user, account, data, and applicable policy.

Can a firewall detect Shadow AI?

A firewall or secure web gateway can identify traffic to known AI services and may contribute user and volume signals. It can miss embedded AI features, personal-versus-enterprise account differences, extensions, agents, and routes outside its visibility. Endpoint, browser, identity, and application context improve coverage.

Why are AI domain blocklists insufficient?

Many applications host ordinary workflows and AI features on the same domain. Domain lists also lag new products and endpoint changes. Blocking the whole service can disrupt legitimate work, while allowing the domain can leave embedded AI use invisible.

Should Shadow AI detection inspect every prompt?

No. Start with endpoint, metadata, identity, and behavioral features. Inspect content only when it is authorized and necessary, then minimize, protect, and limit retention of the resulting telemetry.

How should organizations reduce false positives?

Combine independent signals, preserve an unknown state, tune thresholds against representative traffic, and let analysts see the evidence behind each decision. Evaluate embedded AI and normal activity within the same application.

See WalledAI Shadow AI Detection

WalledAI combines layered discovery with identity and policy context to help enterprises find AI use across supported applications and turn detections into governance decisions. Explore Shadow AI Detection, see how events roll up in the Governance Dashboard, or request a technical walkthrough.