Network vs Browser vs Endpoint Shadow AI Discovery: Which Method Finds Which AI Use

Most shadow AI discovery programmes are built on network logs, and network logs cannot see the AI that now runs on the laptop itself: local models, desktop agents and MCP servers that never leave the device. Teams buy one discovery method, see a tidy list of AI websites, and assume the job is done. The three main vantage points, the network path, the browser and the endpoint, each find a different slice of AI use and each has its own blind spots and privacy cost. This guide compares them across four kinds of AI use (SaaS AI, local models, agents and MCP servers), sets out the threat model and failure modes of each, and gives a combined design with decision criteria. It is for security architects, endpoint and network engineers and the privacy teams who have to sign off on monitoring. Products named below are examples, listed alphabetically, not recommendations.

Key takeaways

• Each method sees a different layer. The network sees destinations, the browser sees what happens inside web sessions, and the endpoint sees processes, files and local listeners. AI that never crosses the network, such as a local model called by a local agent, is visible only from the endpoint.
• MCP servers are mostly invisible to the network. The MCP specification says clients should support stdio wherever possible, and a stdio server is a subprocess talking over standard input and output. Only endpoint inventory of configuration files and processes finds it.
• Encryption keeps eroding network visibility. RFC 9849 Encrypted Client Hello (March 2026) hides the server name in TLS, and certificate-pinned desktop apps resist inspection. Plan for the network to see less each year.
• Personal devices defeat browser and endpoint methods. Only identity-side controls (conditional access, consent policies) reach unmanaged devices, so discovery must be paired with controls on corporate data access.
• Privacy cost rises with depth. Destination metadata is light; page content, prompts and local file inventories are heavy. UK regulator guidance requires the least intrusive means and a DPIA for high-risk monitoring.

The short answer

Start with the network for breadth and speed, because it covers every managed device and server on day one without installing anything. Add browser controls where most SaaS AI use happens and you need to tell corporate from personal accounts or see paste and upload events. Add endpoint discovery for the populations most likely to run local models, coding agents and MCP servers: developers, data scientists and power users. Feed all three into one inventory and one owner per finding; the AI Usage Monitoring Guide has the full telemetry sources table, including identity provider and AI gateway logs, which this page does not repeat.

Coverage by type of AI use

Network discovery

Threat model and what it finds

Network discovery answers "which AI services are our devices and servers talking to?". It suits the classic shadow AI risk of staff sending corporate data to public AI services, and the server-side risk of workloads calling model provider APIs with unapproved keys. It also catches model and package downloads from public hubs, which is often the first sign that someone is about to run a model locally.

Architecture in words

Logs from forward proxies, secure service edge clients, firewalls and DNS resolvers are matched against an AI application catalogue and a list of provider API and model hub domains. With TLS inspection, a proxy can read requests and apply data loss rules; without it, the method sees hostnames (from SNI or DNS), IP addresses, byte counts and timing. See the TLS Inspection Guide for the inspection trade-offs.

Blind spots and failure modes

• Encrypted Client Hello: RFC 9849 encrypts the ClientHello, including the server name. The RFC notes the destination can still be inferred from DNS or IP addresses and that managed enterprises may disable ECH by policy; do so in managed browsers if your discovery depends on SNI.
• Protocols that skip the proxy: HTTP/3 over QUIC uses UDP, and DNS over HTTPS hides queries from resolver logs. Block or route both on managed devices, or accept the gap.
• Pinned and inspection-incompatible apps: desktop AI apps and CLIs that pin certificates, or that are added to inspection bypass lists, show as destinations only.
• Local traffic: loopback calls between a local agent, a local model and a stdio MCP server never reach the network.
• Off-network devices: laptops with the client disabled or split tunnels sending AI domains direct.
• Catalogue lag: new AI tools and MCP server hosts appear faster than catalogues classify them, so uncategorised destinations need a default rule.

Privacy weight

Low for destination metadata, high once TLS inspection captures prompts. Keep content capture to DLP matches and route it through a DPIA.

Browser discovery

Threat model and what it finds

Browser discovery answers "what are people doing with AI inside web sessions, and with which account?". It is the best method for paste and upload of sensitive data into AI chat tools, for telling a corporate AI tenant from a personal one, and for AI browser extensions that read page content. ATT&CK tracks malicious extensions as T1176.001 Software Extensions: Browser Extensions; see the AI Browser Extensions Security Guide.

Architecture in words

Three forms exist: managed browser policy pushed by device management, an enterprise browser that replaces or wraps the consumer browser, and a security extension force-installed into managed browsers. Policy alone gives an extension inventory and control: in Google Chrome and Microsoft Edge, the ExtensionSettings policy sets installation_mode per extension (allowed, blocked, force_installed, normal_installed, and in Edge also removed), blocks extensions by requested permission with blocked_permissions, and stops extensions touching named sites with runtime_blocked_hosts. Enterprise browsers and security extensions add page-level events such as paste, upload and account identity.

Blind spots and failure modes

• Other browsers and native apps: anything outside the governed browser, including desktop AI apps, CLIs and IDE assistants, is invisible.
• Local models and MCP: a browser sees none of them unless a web interface for the local model is opened in it.
• Extension self-protection gaps: a security extension that users can disable, or that is not force-installed, gives partial coverage that looks complete.
• Personal profiles: users signed into a personal browser profile on a managed device may fall outside policy unless profile separation is enforced.
• Built-in browser AI: assistants built into the browser itself need their own policy settings. See Browser Built In AI Features.

Privacy weight

Moderate to high. Page-level telemetry can reveal far more than AI use; scope collection to AI destinations and sensitive data events, and tell staff what is collected.

Endpoint discovery

Threat model and what it finds

Endpoint discovery answers "what AI software, models, agents and MCP servers are installed or running on this machine, and what can they reach?". It is the only method that sees local AI. A local MCP server runs with the user's account permissions, so a misconfigured or malicious one can read and change anything the user can. A local model server bound to all interfaces becomes a network service nobody approved. Developer machines also hold the API keys these tools use; see AI Coding Tools and Secrets Sprawl.

Architecture in words

An EDR or endpoint agent, or device management software inventory, collects installed applications, running processes and their command lines, listening ports, network connections and selected file paths. AI discovery adds three kinds of rules on top:

Blind spots and failure modes

• Unmanaged devices and servers without agents: contractors' laptops, personal machines, and container workloads where no endpoint agent runs.
• Content blindness: the endpoint sees that a process connected to a provider, not what was sent, unless endpoint DLP is in place. See the Endpoint DLP Guide.
• Rule rot: configuration paths and file names change as clients evolve; for example, Visual Studio Code now steers new configurations to native destinations rather than .vscode/mcp.json. Review detection rules each quarter against current client documentation.
• Portable tools: binaries run from user directories without installation escape software inventory and need process and hash telemetry.
• Collecting too much: reading whole configuration files can pull API keys into the security data lake. Parse server names, commands and URLs; hash or drop secret values.

Privacy weight

Moderate. Software and process inventory is routine; file content collection is not. The endpoint method is also the one most likely to touch personal data on home-working devices, which UK guidance treats as within scope of worker monitoring rules.

Privacy and proportionality across the three

The ICO's monitoring workers guidance says you must be clear about your purpose and select the least intrusive means, must inform workers about monitoring, must complete a DPIA before processing likely to cause high risk, and that covert monitoring is unlikely to be justified in most circumstances. It also notes that home working and personal devices blur the line between workplace and private information. The guidance states it is under review following the Data (Use and Access) Act, so check its current status. In practice: collect destination and inventory metadata by default, collect content only on DLP matches, publish a short notice that lists the three methods, and consult worker representatives where required. The Employee Monitoring and Privacy Guide covers the legal detail.

Decision criteria

A combined design

1. Baseline from the network (weeks 1 to 2): report AI app, provider API and model hub domains by user and device from proxy and DNS logs. Separate browser use from API calls by user agent and source.
2. Inventory the browser (weeks 2 to 4): pull the extension inventory from managed browser policy; set a default of blocked or allowed with review for extensions requesting broad permissions on all sites.
3. Add endpoint rules in audit mode (weeks 3 to 6): deploy detections for MCP configuration files, AI client child processes, local model runtimes and listeners on all interfaces. Start with developer and data science device groups as the pilot ring.
4. Correlate: join findings on device and user. A model hub download (network) followed by a new local listener (endpoint) is one finding, not two.
5. Triage by access: rank by what the AI can reach, not by brand. An MCP server with a production database token outranks a popular chatbot used for drafting. See the Shadow AI Discovery Guide for the scoring model.
6. Act with an alternative: coach, sanction or block per the approach in Block vs Sanction vs Coach, and publish an approved MCP server list and local model policy before enforcing.
7. Roll back safely: endpoint rules that break developer tooling are switched back to audit for the affected group while the exception is reviewed, rather than removed estate-wide.

Worked scenario

A software company with 2,000 staff runs SSE on all laptops and believes it has shadow AI under control: the SSE dashboard lists 40 AI websites and shows a sanctioned AI tenant carrying most traffic.

• Network view: spikes of large downloads from model hub domains on 60 engineering laptops, and steady calls to two model provider APIs from developer machines using keys that are not from the company's account.
• Browser view: the extension inventory shows an AI writing extension on 300 browsers with permission to read all sites, including the internal HR system.
• Endpoint view (pilot on engineering): 140 MCP client configuration files listing 35 distinct servers, eight of them with database or cloud tokens in environment variables; 45 local model runtimes, three listening on all interfaces; one coding agent running as a scheduled task overnight.
• Outcome: the extension is blocked from internal domains with runtime_blocked_hosts while a review runs; the exposed model listeners are rebound to localhost; the eight token-bearing MCP servers are moved to an approved list with tokens issued from the vault; personal provider keys are replaced with gateway keys. None of the endpoint findings appeared in the network dashboard.

Where identity fits

Every discovered AI tool is useful to an attacker because of the identity it holds: an OAuth grant, a provider API key, a hub token, or the user's own session. Endpoint discovery often finds those credentials in MCP configuration files and environment variables, which turns a shadow AI finding into a non-human identity finding with an owner, scope and rotation date. Route remediation through the same process you use for other leaked or unmanaged machine credentials. See the MCP Security Guide for MCP authorisation.

Detection and measurement

Framework mapping

Common failure patterns

• Treating the SSE dashboard as the inventory: it lists websites, not local models, agents or MCP servers.
• Endpoint rules written once: MCP clients change configuration locations, and stale rules report zero findings that look like good news.
• Leaving AI destinations in the inspection bypass list: added to fix a broken app, never reviewed.
• Harvesting secrets into the SIEM: collecting whole MCP configuration files copies tokens into another system. The Vercel Context.ai OAuth Breach 2026 shows how a credential held by a forgotten AI app becomes the incident; do not create a second copy.
• Monitoring before telling staff: switching on page-level browser telemetry without a notice or DPIA creates a privacy complaint and pushes AI use onto personal phones.

Practitioner checklist

• Map your AI use into the four types (SaaS AI, local models, agents, MCP) and mark which method covers each today.
• Add model hub and provider API domains to network reporting, separated from AI website use.
• Disable or route ECH, QUIC and DNS over HTTPS on managed devices where network discovery depends on them.
• Pull extension inventories through managed browser policy and block broad-permission AI extensions by default pending review.
• Deploy endpoint detections for MCP client configuration files, AI client child processes and local model listeners, in audit mode first.
• Parse configuration files for server names and commands only; never store secret values in security tooling.
• Correlate findings by user and device and rank them by the access each AI tool holds.
• Complete a DPIA and publish a staff notice listing the discovery methods before collecting page or content data.
• Review endpoint rules and catalogue coverage quarterly against current client documentation.

Standards and references

• Model Context Protocol: Transports specification
• IETF: RFC 9849 TLS Encrypted Client Hello
• ICO: Data protection and monitoring workers
• Model Context Protocol: Connect to local MCP servers
• Visual Studio Code: MCP configuration reference
• Google: Chrome ExtensionSettings policy
• Microsoft Learn: Microsoft Edge ExtensionSettings policy reference
• Ollama: FAQ (bind address, port and model storage)

Related NHI Mgmt Group resources: AI Usage Monitoring Guide · Shadow AI Discovery Guide · AI Gateway vs CASB/SSE for Controlling Shadow AI · Endpoint Telemetry Guide · Self-Hosted LLM Security Guide