Detecting shadow AI requires more than a one-time discovery scan. It requires a framework that continuously answers four questions:
- What AI tools are in use?
- What constitutes normal use?
- Which interactions carry elevated risk?
- What response is proportional to that risk?
DTEX’s approach to this framework is built on DMAP+, correlating data, metadata, activity, and provenance signals at the endpoint into a single forensic timeline. The five steps below translate DMAP+ into an operational program security teams can stand up and mature over time.
Step 1: Endpoint-level AI tool discovery
The first step is establishing ground truth: what AI tools are actually in use across the organization, right now, at the endpoint, not what network logs suggest might be in use.
DMAP+ passively observes browser activity, application launches, and process trees directly on the endpoint, without requiring invasive content inspection. This means security teams can see when an employee opens a generative AI site in a browser tab, launches a locally-installed AI application, or triggers an AI-powered plugin inside an IDE, all correlated to a specific user, device, and time, regardless of which network the endpoint is connected to.
This is a structurally different vantage point than network-only discovery. DNS and proxy logs can confirm that traffic reached a known AI domain, but they go dark the moment a device leaves the corporate network, the moment traffic is encrypted end-to-end, or the moment the “tool” is a locally-run model with no recurring network footprint at all. Proxy-based discovery also cannot distinguish a five-second visit from a 45-minute session involving repeated document uploads. It sees a domain hit, not a behavior.
The output of endpoint-level discovery is a living inventory of every AI tool touching the enterprise (sanctioned and unsanctioned, cloud-based and local), updated continuously rather than refreshed on a quarterly audit cycle.
What DTEX discovers that proxies miss.
- Locally-run open-source LLMs (e.g., Ollama, LM Studio) with no persistent network signature
- Unvetted browser extensions that route content to AI backends
- IDE-embedded AI plugins (GitHub Copilot, Cursor, Tabnine) invoked inside developer environments
- AI tool usage on off-network or remote endpoints, including BYOD and contractor machines
- AI features embedded inside sanctioned SaaS platforms (e.g., an AI summarization feature quietly enabled inside a CRM)
Step 2: Usage pattern baselining
Discovery tells you an AI tool was used. Baselining tells you whether that use was normal. Without this layer, every AI interaction looks equally suspicious, which is precisely why rule-based DLP tools generate so much alert noise.
DTEX establishes behavioral baselines per individual, per role, and per peer group, typically over a 30–90 day observation window. This baseline captures the rhythm of legitimate AI use: which tools a role typically touches, at what frequency, during what hours, and in what volume. A software engineering peer group that shows daily Copilot usage during working hours establishes a baseline where that behavior is expected and low-risk. A finance peer group with no historical AI tool usage that suddenly shows PDF uploads to a public chatbot at 11 p.m. represents a sharp deviation from both the individual’s own history and their peer group’s norm.
This peer-group comparison model is what separates behavioral baselining from static rules. A rule that says “flag all uploads to ChatGPT” cannot account for role context and will either over-alert on legitimate use or under-alert on a genuine anomaly buried in normal-looking traffic. A baseline that accounts for who the user is, what their peers normally do, and when the activity occurs turns a single data point into a contextualized signal, and materially reduces the false-positive rate that causes analysts to tune out DLP alerts altogether.
Step 3: Risk-scoring AI interactions
Not every AI interaction carries the same risk, and treating them uniformly wastes analyst attention on low-risk activity while under-prioritizing genuine exposure. Step 3 converts a baselined anomaly into a scored, actionable signal.
DTEX’s risk-scoring model weighs multiple DMAP-derived factors together rather than evaluating any single signal in isolation:
- Data sensitivity: was the content accessed immediately before the AI session tagged confidential, regulated, or classified?
- User role and access level: does this user routinely handle sensitive data as part of their job, or is this an unusual reach beyond their normal access footprint?
- Time and location anomalies: is the interaction occurring off-hours, off-network, or from an unmanaged device?
- Volume of content transferred: is this a single sentence pasted for clarification, or a bulk copy-paste spanning multiple documents?
- Destination tool’s data handling posture: does the AI tool in question retain submitted data for training, or is it an enterprise-tier tool with contractual data protections?
Correlating these factors, rather than firing a siloed alert on any single one, produces a unified risk score that reflects the actual likelihood and severity of exposure. This is also where shadow AI detection intersects with broader insider risk management: a high-risk AI interaction rarely occurs in isolation. It often co-occurs with other early warning indicators (resignation activity, access anomalies, off-hours file access), and DTEX’s correlation model is built to surface those combinations rather than treat shadow AI as a standalone alert category.
Step 4: Policy enforcement and response playbooks
Detection without a proportional response either does nothing or does too much. DTEX supports a graduated enforcement spectrum: monitor-only for low-risk, baseline-consistent activity; warn the user with an in-the-moment coaching prompt for moderate-risk deviations; block the action for high-risk, policy-violating attempts; and escalate to HR or legal when the pattern indicates deliberate exfiltration or repeated policy circumvention.
Proportionality matters operationally, not just philosophically. Over-blocking is a self-defeating strategy: employees who are blocked from a productivity tool they’ve come to rely on don’t stop using AI. They move to personal devices, personal accounts, and unmanaged channels, pushing the exact behavior you’re trying to govern further outside your visibility. A response framework that escalates in proportion to actual risk keeps the organization’s line of sight intact while still enforcing hard stops where warranted.
Critically, DTEX enables this enforcement without requiring invasive, agent-based content inspection of every keystroke or document. Policy triggers are built on metadata, activity sequence, and provenance (the pattern of behavior) rather than continuous content scanning, preserving employee privacy while still catching the sequences that matter.
Sample policy trigger: Alert when a user copies content from a file tagged “Confidential” and pastes it into a public AI tool within the same session.
Step 5: Continuous monitoring and program maturation
Shadow AI isn’t a problem that gets solved with a single audit. New tools, browser extensions, and AI-embedded SaaS features emerge weekly, and any framework that relies on a static inventory or a fixed rule set is obsolete within a quarter.
DTEX treats discovery, baselining, and risk scoring as a continuous feedback loop: the tool inventory updates automatically as new AI domains and applications are observed at the endpoint, baselines re-calibrate as roles and adoption patterns shift, and risk models adjust as new tools’ data-retention postures become known.
For CISOs, this program should produce ongoing, board-ready metrics:
- AI tool sprawl index: the number of distinct AI tools/vendors in active use across the enterprise
- High-risk interaction rate: the volume and trend of interactions crossing the high-risk threshold
- Policy trigger frequency: how often enforcement actions fire, and at which tier of the response spectrum
This continuous record also becomes the organization’s compliance backbone. A running, timestamped log of AI tool usage, risk scoring, and enforcement actions provides the audit trail regulators expect under GDPR’s breach-notification requirements, HIPAA’s access-accounting obligations, and the EU AI Act’s documentation mandates, turning shadow AI monitoring from a security control into demonstrable governance evidence.
Endpoint vs. network detection: a direct comparison
| Detection Capability | Network-Only Approach | DTEX Endpoint Behavioral Approach |
| AI tool discovery | Sees traffic to known AI domains only; blind once traffic leaves the corporate network | Discovers all AI tool activity at the endpoint, on- or off-network |
| Data content visibility | Cannot inspect encrypted, free-text prompt content | Correlates data sensitivity and provenance without invasive content scanning |
| Behavioral context | No visibility into pre/post-event user activity | Full activity sequence: file access, copy-paste, app switches surrounding AI use |
| False positive rate | High: flags all traffic to AI domains regardless of context | Low: anomalies scored against individual and peer-group baselines |
| Locally-run AI models | Undetectable: no consistent network signature | Detected via endpoint process and application telemetry |
| Browser extension detection | Not visible unless extension generates flagged network traffic | Directly observed at the endpoint, including install and usage correlation |
| Insider risk correlation | Siloed from other insider risk indicators | Unified risk scoring alongside access, resignation, and behavioral signals |
| Compliance evidence | Limited to domain/traffic logs | Continuous, timestamped audit trail supporting GDPR, HIPAA, and AI Act readiness |
A framework is only as strong as the tooling that supports it, and the shadow AI detection market spans several distinct architectural approaches, each with different strengths and blind spots. The comparison in part 3 of this series evaluates the leading options practitioners are weighing in 2026.
Frequently asked questions: shadow AI detection
Traditional DLP tools generally cannot reliably detect shadow AI usage because they are built to inspect content against known data patterns, not to recognize AI-specific behaviors like prompt submission, model inference, or agentic task execution. DLP and CASB tools may flag traffic to a known AI domain, but they miss AI features embedded inside sanctioned apps, locally-run models, browser-based AI plugins, and non-human identities acting autonomously. Effective shadow AI detection requires behavioral endpoint telemetry layered with network and identity monitoring, which is where DTEX’s DMAP+ engine closes the gap DLP alone cannot.
An effective shadow AI policy starts with visibility, not restriction: you cannot govern AI usage you cannot see, so the first step is deploying detection that surfaces which AI tools employees already use before writing rules. From there, build a tiered policy that distinguishes sanctioned AI (approved, monitored tools), conditional AI (permitted with data-handling guardrails), and prohibited AI (tools handling regulated or high-sensitivity data). Pair the policy with continuous behavioral monitoring rather than one-time audits, since shadow AI adoption shifts monthly. DTEX data shows 68% of insider incidents are proactively resolved through security awareness training and policy adjustments alone, meaning governance rather than outright bans resolves most risk without disrupting productivity.
A basic detection capability covering AI tool discovery and high-risk alert generation can be operational within two to four weeks for organizations with an existing endpoint agent footprint. Building behavioral baselines takes a further 30 to 90 days of observation before meaningful anomaly scoring is possible. A full program covering discovery, baselining, risk scoring, proportional response playbooks, and board-level reporting typically reaches maturity within one quarter. Organizations that already run a CASB or DLP tool can accelerate the network-layer portion, but endpoint behavioral telemetry requires its own agent deployment regardless of existing tooling.
Behavioral baselining is the process of establishing what normal AI tool usage looks like for a specific individual, role, and peer group before attempting to detect anomalies. Without a baseline, every interaction with an AI tool looks equally suspicious, which is precisely why rule-based DLP tools generate excessive false positives that analysts learn to ignore. Effective baselining captures the rhythm of legitimate use: which tools a role typically touches, at what frequency, during which hours, and in what data volume. A deviation from that norm (such as a finance analyst uploading PDFs to a public chatbot at 11 p.m. when that peer group has no prior AI tool usage) produces a scored, actionable signal rather than a generic alert.
Traditional DLP is designed to detect and block the movement of known sensitive data patterns across defined egress points. Shadow AI detection must go further because AI interactions involve free-text prompt input that does not match signature-based patterns, and because risk is often defined by behavioral context (what was happening before the prompt was submitted) rather than the content of the prompt itself. Shadow AI detection also needs to cover locally-run models, browser extensions, and AI features embedded inside sanctioned applications, all of which sit outside the perimeter where traditional DLP operates. DLP can complement shadow AI detection but cannot replace endpoint behavioral telemetry for full coverage.