TL;DR
Shadow AI detection means finding the AI tools, accounts, extensions and agents people use without approval, using signals your security stack already collects. Start with network and SSE logs, which show who contacts AI services and how much data leaves. Then add identity data, because OAuth grants reveal AI apps connected to corporate accounts. Endpoint and browser inventories catch extensions, desktop AI clients and local models that network logs miss. Developer surfaces, expense reports and agent config files close the remaining gaps, including local MCP servers that never touch the proxy. Finally, correlate every signal into one inventory, route each finding through a triage ladder, and track coverage and time to detect.
Key Takeaways Shadow AI detection works best as a layered search across logs you already own, rather than as a single scanner. Network logs show contact with AI services, but upload volume and data class decide how serious a finding is. OAuth grants, browser extension reports and endpoint inventories catch what the proxy cannot see. Local agents and MCP servers leave config files behind, so read those files rather than waiting for traffic. Every finding needs an owner, a confidence level and a next step, from a quiet nudge to a full incident. Measure coverage, time to discover and repeat findings, so you know whether detection is improving. Watch on YouTube
How KANGuard Secures Your Data | Prevent Leaks & Unauthorized Access with DLP Policies
Kanerika walks through how kanGuard uses DLP policies on Microsoft Purview to stop sensitive data leaking to places it should not go, including unapproved apps.
A Clean Proxy Report and the Laptop That Proved It Wrong
This morning is a composite, but plenty of detection teams will recognise it. An analyst filters a week of proxy logs for AI domains and finds the expected names, all routed through the company’s approved enterprise tenant. The report looks clean, so it goes out to the CISO before lunch.
That afternoon a help-desk ticket arrives about a slow laptop. While fixing it, the engineer finds a browser extension that can read every page.
There is also a personal chatbot login in a second browser profile, plus a coding assistant wired to a local MCP server with database credentials. None of it showed up in the proxy report, and none of it was in the SaaS inventory.
That gap is exactly what shadow AI detection has to close, and it is not a fringe problem.
Microsoft’s 2024 Work Trend Index , surveyed in early 2024, found that 78% of AI users were bringing their own AI tools to work. In IBM’s 2025 Cost of a Data Breach research , one in five organizations reported a breach tied to shadow AI. Yet only 34% of organizations with AI governance policies regularly audit for unsanctioned AI.
Finding shadow AI is also harder than finding older shadow IT. The tools are free, they run in a browser tab, and they sit behind personal accounts or switch on inside software you approved years ago. So the evidence is scattered across five or six consoles, each owned by a different team.
Shadow AI Detection Signals at a Glance
Each signal source answers a different question. Still, each one has a blind spot that another source covers. The table maps them, along with the team that usually owns the data.
Signal source What it reveals Blind spot Usual owner DNS, proxy, SWG and SSE logs Who reaches AI services, how often and how much data leaves Off-network devices, encrypted DNS, AI inside approved SaaS Network security or SOC CASB cloud discovery App risk scores and sanctioned or unsanctioned status Only the traffic it receives logs for Cloud security Identity provider and OAuth grants AI apps connected to corporate accounts, with their scopes Personal accounts that never touch SSO Identity team Browser extension reports AI extensions, install counts and requested permissions Unmanaged browsers and personal profiles Desktop engineering Endpoint inventory and DLP Desktop AI clients, local runtimes, sensitive data sent to AI sites Devices that are not enrolled Endpoint and data security Code repos and CI pipelines Model API keys, AI SDK imports, egress from build runners Code kept outside managed repos AppSec or platform team Expense and AP records Paid AI subscriptions, owners and cost centres Free tiers and bundled add-ons Finance and procurement Agent and MCP config files Agents, MCP servers and the tools they can call Hosts you cannot read files on Endpoint and AppSec
Almost every row, in fact, is telemetry an enterprise already pays for. So the first month of a detection program is mostly plumbing, which means getting each feed into one place and agreeing on who reads it.
Which Signals to Connect First
First, connect the two or three sources that cover the most users, usually network logs and the identity provider. Then add the others in order of the risk they close. Afterwards, the result feeds the same register described in our guide to AI inventory management , so detection and inventory never drift apart.
Why One Tool Never Finds All of Shadow AI
Vendors sell shadow AI discovery as a single dashboard, and every one of them has gaps. Those gaps come from how AI tools reach users, rather than from weak products.
Personal accounts are the first problem. A consumer chatbot login and the company’s enterprise tenant often share one domain. So domain matching alone cannot tell them apart.
Unmanaged and personal devices are the second, because they never send logs to your proxy at all.
AI features inside approved SaaS form the third gap. When a CRM, a note-taking app or a design tool turns on an assistant, the traffic goes to a domain you sanctioned long ago. Local models and agents are the fourth, since a model running on a laptop may never make a network call that looks like AI.
Encryption adds a fifth blind spot. For instance, browsers and apps can resolve names over DNS over HTTPS (RFC 8484) , which bypasses the corporate resolver. In addition, TLS inspection exceptions, often set for banking or health sites, can hide the rest.
A zero-trust data security posture helps here, because it routes access through identity rather than trusting the network path.
Network Layer: DNS, Proxy, SSE and CASB Logs
Network telemetry is the usual starting point because it covers every managed device at once. Done well, it answers three questions, namely who contacted an AI service, from which device and with how much data.
Build and Maintain an AI Destination Catalog
The catalog lists AI-related domains with a category for each, such as chat assistant, model API, coding tool or MCP endpoint. New tools launch every week, so treat the list as a live feed with a named owner who updates it. That is also why this guide does not publish a static domain list, because it would be out of date within a month.
Commercial CASB catalogs also do much of this work for you. For example, Microsoft’s Defender for Cloud Apps cloud discovery checks traffic logs against more than 31,000 cloud apps. Each app is scored on over 90 risk factors.
Fields Worth Extracting
Pull the timestamp, user identity, device name, source IP, destination host, URL category, HTTP method, bytes sent and bytes received. User identity matters most, because a finding with only an IP address is hard to act on. If your proxy does not authenticate users, join on device name and the DHCP or VPN logs instead.
Separate Contact From Data Transfer
A user who opened a chatbot page once is a different case from one who sent 40 MB to it over a week. Bytes sent, POST counts and upload endpoints are what separate the two. Score them separately, because contact alone is usually a policy conversation, while large uploads may be a data incident.
AI Assessment
See How Ready Your AI Program Is to Spot Shadow AI
Score your organization’s AI maturity across data, governance and security to see which detection gaps to close first.
Start Your AI Assessment → A Starter Detection Query
The query below is an illustrative Kusto (KQL) starting point for a SIEM such as Microsoft Sentinel. It assumes two watchlists, one for AI destinations and one for approved AI domains. It also assumes a proxy table, so rename its columns to match yours.
// Illustrative only. Rename WebProxyLogs and its columns to match your SIEM.
let AIDestinations = _GetWatchlist('AIDestinations') | project Domain = SearchKey, Category;
let Approved = _GetWatchlist('ApprovedAIDomains') | project Domain = SearchKey;
WebProxyLogs
| where TimeGenerated > ago(7d)
| extend Domain = tolower(DestinationHost)
| join kind=inner AIDestinations on Domain
| join kind=leftanti Approved on Domain
| summarize Requests = count(), BytesOut = sum(SentBytes),
Devices = dcount(DeviceName),
FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by UserPrincipalName, Domain, Category
| extend Pattern = iff(BytesOut > 1000000, "possible upload", "contact only")
| order by BytesOut descThe 1 MB threshold is a placeholder rather than a benchmark. Tune it against a week of your own traffic, then review the top results by hand before you automate anything.
A Microsoft Stack Example
On Microsoft tooling, Defender for Cloud Apps builds snapshot reports from uploaded firewall and proxy logs, or continuous reports from forwarded logs. It then refreshes discovery data four times a day. On top of that, Microsoft Entra Global Secure Access shadow AI discovery inspects traffic for generative AI apps, SaaS MCP servers and model provider APIs. Admins then filter by “Generative AI apps and tools” under Insights and Analytics.
Microsoft’s Generative AI Insights feature, in preview as of November 2026, can also log prompt content through TLS inspection. Whether to capture prompts is a privacy decision, though, not a detection requirement, and the endpoint section below explains why classifications usually serve better.
Identity Layer: OAuth Grants, Consent and SSO Gaps
Identity data catches a class of shadow AI that network logs miss entirely. These are AI apps a user connected to a corporate account with one consent click. A meeting assistant reading the calendar is a typical case, and so is a writing tool with mailbox access.
Pull Every Delegated Grant
Export every delegated permission grant, then match the client app names and publishers against your AI catalog. The table shows where that data lives on the two most common platforms.
Platform Where to pull grants What to flag Microsoft Entra ID Microsoft Graph GET /oauth2PermissionGrants, plus enterprise app sign-in logs AI apps with mail, file or offline-access scopes and recent sign-ins Google Workspace Admin console App access control (Accessed apps) and OAuth log events AI apps reading Drive or Gmail, and new client IDs
On Microsoft, for example, the oauth2PermissionGrants list API returns every delegated grant and supports filters. On Google, the App access control page lists accessed apps, while OAuth log events record the client ID, scopes and API method. Also note that new app details typically appear 24 to 48 hours after authorization.
Scopes That Deserve a Second Look
Read access to mail, files, calendars and chats matters most, along with offline access that keeps a token alive after the user logs out. A grant is not proof of use, so check the last sign-in or the last API call before escalating. A stale grant from an abandoned trial, however, is a cleanup task rather than an incident.
Prevention also sits next to detection here. Entra’s built-in consent policy, microsoft-user-default-low, limits user consent to verified publishers and low-impact permissions. Turning it on therefore shrinks the number of new grants you have to review each week.
Sign-Ups That Never Touch SSO
Many AI tools let people register with a work email and a password, skipping SSO entirely. So search mail logs for welcome and verification emails from AI vendors. That covers accounts the identity provider will never see, and it also maps neatly to the access rules in your generative AI policy .
Datasheet
Elevate Data Governance, Compliance and Security of Your Organization
Kanerika’s datasheet on data governance, compliance and security services for teams tightening control over who and what can reach sensitive data.
Get the Datasheet → Endpoint and Browser: Extensions, Desktop Apps and DLP
The endpoint is where the most intimate shadow AI lives, from browser extensions that read every page to local models that never call home. It is also where privacy concerns are sharpest, so collection choices matter as much as coverage.
Audit Browser Extensions by Permission, Not by Name
Extension names change and clones appear weekly, so filtering on the word “AI” will miss many of them. Look instead at what an extension can do, such as reading all site data, capturing the clipboard or injecting scripts. The Chrome Enterprise Apps and extensions usage report lists installs across managed browsers with permission counts and third-party risk scores.
Inventory Desktop AI Clients and Local Runtimes
Desktop chat clients, local model runtimes and AI coding tools also show up in software inventory. Microsoft Intune’s Discovered apps report lists detected apps on enrolled devices, and its App inventory successor refreshes several times a day.
As of November 2026, Microsoft is also previewing a Shadow AI page in the Microsoft 365 admin center under Agent 365 . In this preview, ChatGPT Desktop, Ollama Desktop and Poe Desktop can be detected but not blocked. It also requires Frontier program opt-in, Defender for Endpoint, Microsoft 365 E5 and Intune enrollment, so check the prerequisites before planning around it.
Endpoint DLP on Uploads and Paste Events
Endpoint DLP sees what network logs only infer, which is sensitive data actually leaving through an upload or a paste. For example, Microsoft Purview DSPM for AI can report users visiting third-party AI sites and sending sensitive information to them. As of November 2026, Microsoft has replaced that classic version with a new one that adds support for AI apps and agents. That requires the Purview browser extension and onboarded devices, and our guide to Microsoft Purview data loss prevention covers the policy side.
Collect Classifications, Not Prompts
Capturing full prompts feels thorough, but it creates a new store of sensitive text that needs its own protection. For most programs, the classification label, the destination and the volume are enough to decide what happens next. So reserve prompt capture for an open investigation with legal sign-off.
Classification only works, however, if your data carries labels first. Teams that skipped that groundwork can start with our data classification best practices , because DLP rules are only as good as the labels they read.
On-Demand Webinar
Data Security Risks in AI: How Microsoft Purview Helps
An on-demand Kanerika webinar on the data security and privacy risks AI introduces, and how Microsoft Purview labels, policies and monitoring keep them in check.
Watch the Webinar → Developer Surfaces: API Keys, SDKs and Build Pipelines
Engineering teams adopt AI through code, which means the evidence sits in repositories and build systems rather than in browsers. Three checks cover most of it.
First, run secret scanning. GitHub secret scanning includes patterns for Anthropic API keys and Anthropic Admin API keys, among many others, so a committed Anthropic key shows up as an alert. Second, scan dependency manifests for model provider SDKs and orchestration libraries, then compare the list against approved projects.
Third, watch egress from CI runners and build agents to model APIs. After all, a pipeline calling an AI endpoint nobody registered is shadow AI with production reach. The same reasoning feeds AI threat modeling , where every unregistered model call is an unmapped data flow. Our roundup of LLM security tools also covers scanners built for this.
AI Hiding Inside Approved SaaS
Some of the hardest shadow AI to spot arrives as a feature update. A sanctioned CRM, ticketing system or document suite turns on an assistant, and suddenly an approved vendor is processing data in a new way.
Picture a CRM that adds an AI call summarizer in a routine release. The vendor, the domain and the contract stay the same, yet recorded customer calls now flow into a model nobody assessed.
Network logs will not flag this, because the domain was approved years ago. Instead, review each major tenant’s admin console for AI feature toggles, connected assistants and data-sharing settings at least once a quarter. Then record which features are on, who enabled them and which data they can reach.
Copilot-style assistants are the obvious example, and our review of Microsoft Copilot security concerns shows how much depends on existing permissions. The wider controls also appear in our guide to generative AI security .
Follow the Money: SaaS Spend and Expense-Report Mining
Paid AI tools leave a paper trail, even when the network trail is thin. Expense reports, corporate card feeds and accounts payable records show who is paying for what, and on which cost centre.
The work is a data-matching job. Normalise merchant names, because one AI vendor can appear under several billing descriptors. Then match them against your AI vendor list, join the results to the approved inventory, and attach the cost-centre owner to every unmatched charge.
For example, one AI writing tool might appear under three different merchant descriptors, on cards held by sales, marketing and HR. Each charge is small enough to pass expense review, but together they reveal a team-wide habit that nobody approved.
This signal has clear limits. Free tiers cost nothing, personal cards never reach your systems, and AI add-ons bundled into existing licences hide inside a familiar line item.
Even so, finance data often reveals team-wide adoption that started as one manager’s subscription, and it gives you a named budget owner to talk to. Cleaning and joining these sources is routine data engineering work rather than a security project.
Finding Unsanctioned Agents and MCP Servers
AI agents are the newest form of shadow AI and the riskiest, because they act rather than answer. For instance, a coding assistant connected to an MCP server can read a database, open tickets or push code with the user’s own credentials.
Read the Config Files Agents Leave Behind
Agents and their Model Context Protocol servers are declared in config files at known paths. An endpoint script that reads those files lists servers, launch commands and connected tools. That works even when the laptop sends no unusual traffic.
Client Config location What to record Claude Desktop macOS ~/Library/Application Support/Claude/claude_desktop_config.json, Windows %APPDATA%\Claude\claude_desktop_config.json, Linux ~/.config/Claude/claude_desktop_config.json Server names, launch commands, names of environment variables VS Code .mcp.json at the workspace root, .vscode/mcp.json, or the user-profile mcp.jsonServer names, transport type, the repository it sits in GitHub Copilot (global) ~/.copilot/mcp-config.json or $COPILOT_HOME/mcp-config.jsonServer names and the tools each one exposes
The paths come from the MCP documentation on local servers and the VS Code MCP guide . Record the names of environment variables, never their values, so the inventory does not become a second credential store. A config file also proves presence, not activity, so pair it with process or network evidence before you escalate.
Why Local MCP Servers Never Reach the Proxy
The MCP specification defines two standard transports. Streamable HTTP sends each message as an HTTP request, so remote servers can show up in network logs. The stdio transport instead runs the server as a local subprocess that talks over standard input and output.
As a result, a stdio server makes no network call between the agent and the server at all. It may still reach a database or an API afterwards, but that traffic looks like an ordinary application. So for local agents, the config file and the process list are your primary evidence.
Network-Side Agent Discovery
Network tools, meanwhile, are catching up. Microsoft’s Global Secure Access AI agent discovery , in preview as of November 2026, attributes agent traffic to a user, device and process. It labels an agent as shadow when it is not registered with Microsoft Entra Agent ID. It also covers local agents on endpoints running the Global Secure Access client.
Once agents are found, the question becomes what they can do. Our map of AI agent security tools covers that control layer, and agentic AI governance covers ownership. An MCP server that exposes document stores also inherits the retrieval risks in our guide to RAG security .
Correlate Signals Into One Shadow AI Inventory
Eight signal sources produce eight lists, and nobody can act on eight lists. Correlation turns them into one record per tool, per account, per user, which is what reviewers and owners actually need.
Normalise every finding into a shared event schema before you merge anything. The fields below are a workable minimum.
Field Why it matters Source and timestamp Shows which signal caught it and when User and device Gives the finding an accountable person App and account type Separates a personal account from an enterprise tenant Destination or config path Shows where data went or where the agent lives Permission or scope Measures what the tool can reach Data class Drives severity far more than the app name Confidence Rates how sure you are that the finding is real Owner and state Tracks who acts next and where the finding sits
Keep confidence and priority as separate fields, because they answer different questions. A certain finding about a harmless tool is low priority, while a shaky signal of a large upload of customer data deserves a fast look. Then deduplicate by app, account and user within a time window, so one person’s daily use does not flood the queue.
Give each inventory entry a state, such as discovered, under review, approved, approved with limits, or retired. That list then becomes the shared view that data security posture management tools and governance teams can both work from.
From Shadow AI Detection to Response: A Triage Ladder
Detection without a response plan just produces a longer report. A triage ladder instead routes each finding by confidence and data sensitivity to a proportionate action and a named owner.
Rung Typical finding First action Owner Example target 1. Nudge Contact with an unapproved AI site, no sensitive data Point the user to the approved tool IT or the user’s manager Within a week 2. Review OAuth grant or sign-up with read access to internal data Revoke the grant or start an app review Identity team Within two business days 3. Contain Confirmed sensitive upload, or an agent holding production credentials Revoke access, block the app, rotate credentials SOC Same day 4. Incident Regulated data exposed, or signs of ongoing exfiltration Open an incident and preserve evidence Incident response lead and legal Immediately
The target times are illustrative, so set your own from your incident policy. The rungs and the owners matter more than the numbers.
Containment and Handoff
Containment tools already exist in most stacks. In Defender for Cloud Apps you can unsanction discovered apps in bulk. Then, with the Defender for Endpoint integration, Network Protection blocks managed devices from reaching them.
Finally, rung four hands over to your incident process, and NIST SP 800-61 Rev. 3 , published in April 2025, is the reference for running it as of November 2026.
Two more inputs keep the ladder humane. An amnesty or self-report channel lets people declare tools before detection finds them, which is often the fastest signal you will get. And when a shadow tool proves useful, fast-track its review, because an approved alternative ends more shadow use than a block does.
The policy tiers behind those decisions are set out in the shadow AI governance guide , and suspected deliberate misuse belongs with insider risk management .
Regulatory Exposure When Shadow AI Goes Undetected
An AI tool nobody has inventoried is also one nobody can govern. The NIST AI Risk Management Framework makes this explicit in GOVERN 1.6, which calls for mechanisms to inventory AI systems, resourced by organizational risk priorities.
In the EU, Regulation (EU) 2026/1744 amends the AI Act so deployers must take measures to support their staff’s AI literacy. It also sets the high-risk obligations to apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
Metrics That Prove Shadow AI Detection Is Working
A detection program needs numbers that show whether it sees more and acts faster over time. The seven metrics below can be calculated from the inventory itself.
Metric How to calculate it Direction Signal coverage Users or devices sending each signal, divided by all in scope Up Mean time to discover Average gap between first activity and first detection Down Sanctioned share AI use on approved tools, divided by all detected AI use Up Reviewed precision Findings confirmed as real, divided by findings reviewed Up Controlled-test recall Planted test tools detected, divided by test tools planted Up Repeat rate Users with a second finding within 90 days, divided by users with any finding Down Unique-signal contribution Findings only one source caught, per source Watch
Controlled-test recall deserves special attention. Plant a test extension, a test OAuth app and a test MCP config each quarter, then count how many your pipeline finds. That is the only honest way to measure what you miss.
For rollout, a 30/60/90 plan keeps scope sane.
In the first 30 days, connect network logs and the identity provider, and build the AI catalog. By day 60, add browser, endpoint and DLP signals, and stand up the triage ladder. By day 90, add developer, finance and agent config sources, then run the first controlled test. The same figures slot into an AI auditing framework , so auditors see evidence rather than intentions.
Common Shadow AI Detection Mistakes
Five mistakes show up again and again in early programs.
Relying on a static blocklist, which is stale within weeks and teaches users to find the next tool. Blocking whole vendor domains, which also blocks the enterprise tenant you pay for. Trusting DNS alone, which misses encrypted resolution, off-network devices and local agents. Hoarding prompts, which builds a sensitive data store that then needs protecting. Running a one-off audit, which captures a single week while new tools launch every week. A sanctioned route, however, fixes several of these at once. Routing approved model traffic through an LLM gateway makes legitimate use visible and easy, which shrinks the pool of shadow use to investigate. For where detection sits among wider controls, see our review of AI governance tools .
How Kanerika Helps Teams Detect and Route Shadow AI
Kanerika’s AI governance consulting starts with an assessment that surfaces governance gaps before they become audit findings and tests controls on your highest-risk systems first. For shadow AI, that means checking which of the signals above you already collect and where the blind spots sit.
Checklist
Generative AI Checklist
A practical checklist for secure generative AI adoption, from approved tools and data access to monitoring what people actually use.
Get the Checklist → The engagement also covers operational monitoring with exception handling, plus an AI Policy and Guardrails track: acceptable use policy drafting, technical guardrails with advanced content filtering, and defined escalation procedures with periodic review cadences. In other words, those are the policy and the escalation paths a triage ladder needs to work.
On the data side, Kanerika delivers kanGuard, its unauthorized access prevention and data security service, on Microsoft Purview . That is the layer where DLP rules and classification labels decide whether an upload to an AI site is routine or serious. Kanerika is also a Microsoft Solutions Partner for Data & AI and holds the Analytics on Azure Advanced Specialization.
Classification has to come before detection can judge severity. In one healthcare engagement, Kanerika built a Purview data catalogue and a classification framework across Azure Blob Storage, SQL databases and SaaS apps. The client saw a 57% reduction in data discovery time, a 90% increase in compliance adherence and a 70% improvement in data accessibility.
More on that approach is in our guide to data governance with Microsoft Purview , alongside our data governance services . For how the AI and data programs split ownership, see AI governance vs data governance .
Case Study
90% Compliance Adherence for Healthcare with Purview
Kanerika built a Microsoft Purview catalogue and classification framework for a healthcare organization, cutting data discovery time by 57% and lifting compliance adherence by 90%.
Read the Case Study → Where Shadow AI Detection Starts
Shadow AI detection rarely needs a new platform on day one. Instead, it needs the logs you already own, read together, with a clear rule for what happens to each finding.
Network logs show contact, identity data shows connections, and endpoints show extensions, desktop clients and local agents. Developer, finance and config-file signals then close the gaps.
Correlation turns all of that into one inventory, the triage ladder turns findings into action, and the metrics show whether the program improves. That inventory then becomes the base of your wider AI governance program. So start with the logs you own, correlate them, triage every finding and measure what you miss.
Frequently Asked Questions
How do you detect shadow AI in your organization?
Layer the signals you already collect. Match network and SSE logs against an AI destination catalog, review OAuth grants in your identity provider, and audit browser extensions and endpoint software. Then add secret scanning in code repositories, expense records and agent config files. Correlate everything into one inventory and route each finding through a triage process with named owners.
Can DNS or proxy logs show employees using ChatGPT without reading their prompts?
Yes. Proxy and DNS logs show the user, device, destination, time and bytes sent, which is enough to see who uses an AI service and how heavily. Upload volume and POST counts separate a quick visit from bulk data transfer. Prompt content needs TLS inspection and a deliberate privacy decision, so most programs do not capture it.
Can a CASB tell a personal AI account from an approved enterprise account?
Often only partly. Personal and enterprise accounts frequently use the same domain, so domain matching alone cannot separate them. Inline SSE or CASB controls that read tenant or login details can help, and identity logs confirm which accounts sign in through corporate SSO. Treat domain-only matches as lower confidence until another signal confirms the account type.
How do you detect AI browser extensions on managed laptops?
Use your browser management console’s extension report, such as the Chrome Enterprise apps and extensions usage report, which lists installs, permission counts and risk scores. Filter by what an extension can do, such as reading all site data or capturing the clipboard, rather than by name. Names change often, while risky permissions stay visible in the report.
Will endpoint DLP catch data pasted into AI tools?
Endpoint DLP can catch uploads and paste events to AI sites when the device is onboarded, the browser extension or agent is installed, and the data carries a sensitivity label or matches a pattern. Unlabelled data and unmanaged devices slip through. That is why data classification usually has to come before DLP-based detection works well.
How do you find local MCP servers that never appear in proxy logs?
Read the config files that AI clients store on disk, such as claude_desktop_config.json, .vscode/mcp.json or the Copilot mcp-config.json. Servers using the stdio transport run as local subprocesses, so no traffic passes between the agent and the server. Record server names and launch commands, never secret values, and confirm activity with process data.
How do you detect shadow AI on devices you do not manage?
You mostly detect it indirectly. Identity logs show AI apps connected to corporate accounts from any device, and SaaS audit logs show data leaving approved systems. Expense records reveal paid subscriptions. Conditional access policies can also require a managed device for sensitive apps, which pushes AI use back onto devices you can actually see.
What should happen after shadow AI is detected?
Route the finding by confidence and data sensitivity. Low-risk contact gets a nudge toward an approved tool. Grants with access to internal data get revoked or reviewed. Confirmed sensitive uploads or agents with production credentials get contained the same day, and regulated data exposure becomes a formal incident handled by your incident response process.
Which metrics show that shadow AI detection is improving?
Track signal coverage across users and devices, mean time to discover, and the share of AI use on sanctioned tools. Add reviewed precision to measure false positives and controlled-test recall to measure what you miss. A falling repeat rate shows that users are moving to approved tools instead of returning to shadow ones.
