Endpoint vs network shadow AI discovery

Seven ways to find shadow AI, from cloud gateways to coding-agent hooks, by what each sees, misses, enforces, and breaks.

26 min read
In short: Decrypting gateways read prompts but need a root certificate that pinned apps and developer tools reject. Browser extensions read the prompt in the tab only. Identity and MDM inventories find accounts and installs, not use. Endpoint network observation ties each connection to an app and a person without decrypting, and coding-agent hooks decide each tool call. Most organizations need two layers.

Should you detect shadow AI on the endpoint or the network?

Choose the layer where most of your shadow AI runs, then add a second layer for what the first one can't see. A cloud security service edge (SSE) or an on-device secure web gateway decrypts TLS, so it reads prompts and can insert tenant headers, but every app and developer tool has to trust its root certificate. A browser extension reads the prompt in the tab with no proxy and sees nothing outside the browser. Identity grants and email metadata list AI accounts tied to a work address without touching a device, and MDM and EDR inventories show what's installed. Endpoint network observation ties each connection to a signed app and a person without decrypting anything, and coding-agent hooks decide each tool call before it runs.

A workforce that uses AI mostly in browser tabs gets the most from a browser extension or from the SSE it already runs. Contractors and BYOD laptops need a browser tool that installs on unmanaged devices, or an identity inventory that needs no device at all. Engineering teams whose command-line agents break under TLS inspection need endpoint observation plus hooks. If you hold Microsoft 365 E5 or run Jamf, turn on what you've already paid for before you buy anything.

Arcjet publishes this comparison and sells an endpoint agent and coding-agent hooks, which are two of the seven approaches on this page. Vendor details come from each vendor's public documentation, reviewed on November 3, 2026. Vendors appear as examples of an approach, not in a ranking. For a product-by-product view, see shadow AI detection tools, and to run each method yourself before you buy, see how to detect shadow AI.

How do the seven approaches compare on visibility?

Each approach sits at a different point between the person and the AI service, and that position fixes what it can see. The following table compares what each one records and what it structurally can't.

ApproachWhat it seesWhat it missesExample vendors
Cloud SSE, SWG, or CASB with TLS inspection

Hostname, user, and app category for traffic it steers; URL and prompt where it decrypts

Bypassed and pinned apps, QUIC unless blocked, laptops off the tunnel, local tools

Zscaler, Netskope, Microsoft Defender for Cloud Apps
On-device SWG with a local root CA

The same content inspection, performed on the laptop wherever it is

Apps on its bypass list, unmanaged devicesdope.security
Browser extension

Prompts, pastes, uploads, and often the signed-in account in the tab

Desktop apps, CLI agents, MCP servers, browsers without the extension

Harmonic Security, Akamai Workforce Protector, Prompt Security, Microsoft Purview

Identity and SaaS graphOAuth grants and sign-ups tied to a work email, from any devicePersonal-email sign-ups, API keys, actual useNudge Security, Google Workspace, Microsoft Entra
MDM, software inventory, and EDR agent discoveryInstalled apps, running agents, and configured MCP serversBrowser use, the signed-in account, whether a tool was usedMicrosoft Intune, Jamf, Microsoft Defender for Endpoint
Endpoint network observation without decryptionEach connection with its signed app, provider, and person

Prompt content, the account behind a shared hostname, local models

Arcjet, Microsoft Defender for Endpoint
Coding-agent hooks

Each tool call, prompt, and model switch in a hooked agent, with the policy decision

Agents and machines without the hook, chat appsArcjet, Runlayer, Harmonic Security

How do the approaches compare on enforcement and setup?

The following table compares how each approach enforces policy, what it breaks on developer machines, and what it takes to deploy.

ApproachHow it enforcesWhat it breaksSetup
Cloud SSE, SWG, or CASB with TLS inspectionBlock, warn, DLP block, tenant header insertion

Pinned apps and tools with their own trust store, until you add the root CA or a bypass

A client or tunnel on every device, a root CA, and a bypass list to maintain

On-device SWG with a local root CABlock, tenant restriction, DLP on prompts and uploadsThe same trust-store problem, handled on the deviceOne agent and its root CA through MDM
Browser extensionWarn, ask for justification, redact, or block in the pageNothing outside the browser

Extension through browser policy; some products also install on unmanaged devices

Identity and SaaS graphRevoke or restrict OAuth grants; ask the person to actNothing on the deviceAn API connection to the IdP or email tenant
MDM, software inventory, and EDR agent discovery

Remove an app; push managed settings to the AI tools that support them

Nothing on the networkUsually already deployed
Endpoint network observation without decryptionAllow or block connections to a provider on the device

Nothing certificate-related; pinned apps and CLI agents keep working

An agent through MDM, and a mapping of local accounts to people
Coding-agent hooks

Allow or deny each tool call, prompt, or model switch before it runs

Nothing on the network; a policy that's too strict stops legitimate work

Managed settings for each agent, and a policy reviewed in dry run

What limits every approach that reads network traffic?

Five conditions narrow what a network-based approach sees, whether it runs in a data center or on the laptop. The Learning Center covers each one with commands and sources in where network detection goes blind, so this section only summarizes them.

HTTP/3 runs over QUIC on UDP port 443, which TCP-based proxies and inspection engines can't read, so gateway vendors tell you to block UDP 443 and let browsers fall back to TCP. Encrypted Client Hello (ECH) hides the real server name behind a shared outer name, which matters for any tool that reads the name from the handshake without decrypting. When reviewed on November 3, 2026, chatgpt.com, claude.ai, cursor.com, and other large AI hosts didn't publish an ECH configuration, so the exposure is smaller tools on Cloudflare's free plan. Certificate pinning forces a decrypting gateway to bypass an app entirely, and a bypassed app shows a hostname and nothing else. A laptop on a phone hotspot skips any gateway that isn't running on the device.

The fifth condition affects every approach that sees only a hostname. A developer on a personal Claude Max plan and a colleague in your Claude Enterprise organization both reach claude.ai and api.anthropic.com. Separating them takes a vendor tenant control: the anthropic-allowed-org-ids header for Claude, the ChatGPT-Allowed-Workspace-Id header for ChatGPT, plan-based hostnames for GitHub Copilot, or Cursor's AllowedTeamId policy through MDM. The two headers need a proxy that decrypts, which is where TLS inspection most clearly earns its cost. For each control, see how to block personal AI accounts on work laptops.

What does each approach see, miss, and break?

The following sections take each approach in turn, with the vendors that document it.

Cloud SSE, SWG, and CASB with TLS inspection

A security service edge steers device traffic through a client or tunnel to the vendor's cloud, decrypts it, and applies app category and data loss prevention (DLP) policy. With inspection on, it sees the full URL and request body, which is what makes prompt-level DLP and tenant header insertion possible. Zscaler's generative AI page describes AI app dashboards by user and department, visibility into "all input prompts users send to apps", DLP blocking, and browser isolation that disables cut, paste, and download. Netskope's app instance awareness blocks public instances of ChatGPT and Gemini while it allows the corporate ones, though Netskope notes that it doesn't support instance awareness for every generative AI app. Microsoft Defender for Cloud Apps works from the CASB side: its app catalog has a Generative AI category, and you filter discovered apps to it and sanction or unsanction each one.

The cost lands on developer machines. Zscaler's guide to SSL inspection in developer environments walks through adding its root certificate to Docker, Git, npm, Java, pip, and the Python requests library one at a time, through settings such as http.sslCAInfo in Git and cafile in npm. Claude Code trusts the operating system store on the native installer and on Node 22.15 or later, and needs NODE_EXTRA_CA_CERTS on older Node versions. Cursor's network configuration guide recommends disabling SSL inspection for .cursor.sh, cursor.com, and related domains, and says Cursor falls back to HTTP/1.1 when Zscaler and similar proxies buffer its HTTP/2 streams. Netskope keeps a bypass list of certificate-pinned apps, and on a bypassed app the gateway sees a hostname and no content.

An SSE also sees nothing of a stdio MCP server or a local model, because neither crosses the network. If you already run Zscaler or Netskope everywhere, turning on its AI controls takes hours. If you don't, deploying a client, distributing a root certificate, and tuning the bypass list is a separate project.

On-device secure web gateway with a local root CA

An on-device gateway does the same decryption on the laptop instead of in a data center. dope.security describes its agent doing "the decrypt, inspect, and re-encrypt locally" in its comparison of on-device and cloud inspection, and its shadow AI post says one agent on Mac and Windows discovers AI apps in the browser, desktop, and command line, inspects prompts and uploads, and restricts ChatGPT and Claude to corporate tenants. Because inspection travels with the laptop, a developer on a hotel network stays covered without traffic going back to a data center.

The root certificate problem doesn't go away. The macOS installer ships dope.security.root.crt, which the installation guide describes as "required for SSL inspection". The same comparison post says pinned apps "refuse to trust a MITM'd one", so the agent keeps a bypass list, and dope.security's post on AI coding assistants says some CLI clients "need a trusted CA or an SSL bypass". dope.security also says the agent needs managed Mac and Windows devices, so BYOD needs another layer. This approach fits a company that wants SWG, CASB, and AI DLP in one agent and can put a root certificate on every developer machine.

Browser extensions

A browser extension reads the page after the browser has decrypted it, so it needs no proxy and no root certificate, and it can see the signed-in account in a way a hostname never shows. Harmonic Security's browser extension identifies the account type and plan behind each session, so a personal free ChatGPT login appears apart from your Enterprise workspace, and it can warn before a paste, ask for a business justification, steer the person to a sanctioned tool, or block. Akamai Workforce Protector, formerly LayerX, deploys on managed and unmanaged devices and can warn, redact, or block. Microsoft Purview uses its browser extension and Endpoint DLP to warn or block pasting sensitive information into third-party AI sites from onboarded Windows devices, with several capabilities limited to Edge and a requirement for pay-as-you-go billing. Prompt Security, part of SentinelOne, also works here.

Everything outside the browser is invisible to this approach. The Claude desktop app, Cursor, a claude session in a terminal, and an MCP server never load a page. The one browser trace a coding agent leaves is its sign-in: Claude Code opens a claude.com page that redirects to claude.ai, which shows that someone signed in, not what the agent did next. A second browser without the extension is a gap too, so pair the extension with a browser policy that limits which browsers can run. Deployment through browser management takes hours to days, and the unmanaged-device support in some products makes this the closest fit for contractors' laptops.

Identity and SaaS graph

When someone signs in to an AI tool with a work Google or Microsoft account, the identity provider records an OAuth grant with the app, the user, and the scopes. Google Workspace's accessed apps list and Microsoft Entra's user consent grants give you that list in about an hour, and how to detect shadow AI has the console paths and a Microsoft Graph PowerShell script. Nudge Security extends the same idea to email: its guide says it analyzes email metadata to find AI tools tied to a corporate address "regardless of device or network", and governs the OAuth grants those tools request.

It's the only approach on the page that needs no software on a contractor's personal laptop, as long as the contractor used a work email. It misses everything that doesn't: a Claude Max plan bought with a personal Gmail address, an API key in an environment variable, and a stdio MCP server. A grant also shows a sign-up, not use, and it doesn't show the plan. Enforcement means revoking or restricting grants in the IdP, or asking the person to move to the company tenant, and nothing on the device changes, so nothing breaks.

MDM, software inventory, and EDR agent discovery

Your MDM already collects installed applications. Microsoft Intune's discovered apps report lists every app on company-owned Macs, and on Windows it lists Windows Installer apps every 24 hours, which misses a CLI installed with npm or Homebrew. EDR agents go further. Microsoft Defender for Endpoint's local AI agent discovery finds agents on Windows and macOS when it observes their process running or reads installed VS Code extensions, and reports configured MCP servers, including the command that starts a local one. Microsoft's own documentation says that an inventory entry "isn't proof of active use or successful access to an AI service". Jamf's AI Governance uses Jamf Protect to build AI application and MCP server inventories on Macs.

Inventory says nothing about the browser or the account in use. Enforcement is either removing the app or configuring it: Jamf AI Governance publishes policies through Apple's Declarative Device Management as managed settings that users and local processes can't edit, for Claude Code, Claude Cowork, and OpenAI Codex on AWS Bedrock, with Cursor and GitHub Copilot planned. Managed settings change how an approved tool behaves, but they don't stop an unapproved one. This approach breaks nothing, and if you run Intune, Jamf, or Defender, the data is already there.

Endpoint network observation without decryption

Software on the device can record which process opened each connection and the server it reached, without terminating TLS. That combination ties a command-line agent on a laptop in a café to a signed app and a person, which neither a gateway log nor an inventory can do. For the manual version with lsof, codesign, and Get-NetTCPConnection, see what endpoint network observation shows.

Arcjet's endpoint agent works this way. On macOS it's a Network Extension content filter with a root launchd service that owns reporting and credentials, so closing the menu bar app or logging out doesn't stop managed reporting. On Windows it's a service that runs under LocalSystem from boot, reads the destination server name from the TLS ClientHello through Windows' built-in Packet Monitor API, and correlates kernel network and process ETW events to find the process and user, with no kernel driver. Neither platform decrypts TLS, installs a root certificate, or reads prompts, so pinned apps, Git, npm, and CLI agents keep working. An administrator maps local accounts to people, and shared, system, and unidentified accounts show as Unknown user instead of inheriting the device owner. Endpoint provider policies set Allow or Block per provider for a group of devices, the agent blocks the connection on the device, and each decision lands in Arcjet Activity with the person, device, app, and provider. Detection rules ship as a reviewed manifest that updates without a new agent release.

Microsoft Defender for Endpoint does a version of this. Its DeviceNetworkEvents table records the remote URL, initiating process, and account for each connection, and network protection reads the server name from the TLS handshake to block domains in non-Microsoft browsers and other processes. When you tag an app Unsanctioned in Defender for Cloud Apps, its domains reach network protection and are blocked within up to three hours. Microsoft documents that blocking domains this way in non-Microsoft browsers requires QUIC and ECH to be turned off there. Harmonic's Protect Agent also reports connections to known AI hosts.

The approach has firm limits. A connection isn't a prompt, and it isn't always an AI request: Claude Code contacts downloads.claude.ai for update checks. A hostname can't tell a personal account from a company one. A model in Ollama makes no outbound connection, and a device without the agent, including every personal phone, is out of scope.

Coding-agent hooks

Claude Code, GitHub Copilot, Cursor, OpenAI Codex, and Muse Code fire hooks before a tool runs and when a prompt is submitted. A hook installed through managed settings receives the tool name and arguments and can deny the call, so it sees what an agent did, not only where it connected. Arcjet enforces one policy across those five agents, installed through managed settings, MDM, or an organization lock, and decides each tool call, prompt, or model switch before it runs, with starter policies for MCP allowlists, egress allowlists, model allowlists, credential access, and sensitive information. Runlayer's AI Watch installs hooks in Monitor, Protect, or Enforce mode. Harmonic's Protect Agent intercepts prompts and tool calls in Claude Code, Codex, Cursor, GitHub Copilot CLI, and other clients through "the applications' built-in hooks features". Microsoft Defender lists agent-native event inspection for Claude Code and GitHub Copilot in its runtime protection matrix, in preview on Windows.

A hook covers only the client where it's installed. A second agent, a cloud session, or an unmanaged machine never fires it, and some hooks fail open. Hooks see nothing of chat apps. Nothing on the network changes, so the risk is a policy that blocks legitimate work, which is why you publish a starter policy in dry run first. Setup takes a few days, most of it spent reviewing what the dry run would have denied.

How does each approach see one developer's afternoon?

Consider Dana, a developer on a managed MacBook in a company with a Claude Enterprise organization. She opens chatgpt.com in Chrome, signed in to a personal account, and pastes a stack trace. Then she runs claude in a terminal, signed in to a personal Max plan, and the session calls a stdio MCP server listed in her ~/.claude.json. At 4 PM she moves to a café and tethers to her phone without the VPN.

A cloud SSE with inspection sees the chatgpt.com paste, and if it inserts the ChatGPT-Allowed-Workspace-Id header, ChatGPT refuses her personal login. It sees the claude traffic only if the root certificate reaches Claude Code's trust store, and it never sees the MCP server. At the café, it sees nothing unless its client runs on the laptop. A browser extension sees the paste and her personal ChatGPT account, and nothing of the terminal. The identity graph shows the ChatGPT account only if she signed up with her work Google login, and it never shows the Max plan. Defender's agent discovery or Jamf's inventory shows that Claude Code runs and lists the MCP server, without the account.

Arcjet's endpoint agent records a chatgpt.com connection from Chrome and an api.anthropic.com connection from the Anthropic-signed claude binary, both attributed to Dana, including from the café. It can't say that either account is personal. Blocking Anthropic as a provider would also block her company's Claude Enterprise organization, so the right control for the Max plan is the anthropic-allowed-org-ids header or an equivalent tenant control. Arcjet's hooks, delivered as managed settings files through MDM, record each tool call in her claude session, including the MCP calls, and apply the policy whichever account she signed in with. Hooks delivered only as server-managed settings wouldn't load, because her personal session never authenticates to your organization.

For coding agents, each source proves something different. The endpoint connection shows that an app reached a provider, the hook event shows what the agent ran and what the policy decided, and the Claude Compliance API shows sessions in your organization's account. Dana's Max session appears in the first two and not the third, which is a lead to investigate, not proof. A hook event close in time to a connection isn't proof that both came from the same request. For more about how to combine these sources, see what each source of evidence proves.

Which two approaches should you start with?

Find the row that matches your organization. Each row pairs a primary approach with the second layer that covers its largest gap.

Your situationStart withAddWhy
Browser-heavy workforce, few developersA browser extension, or the SSE you already runIdentity and SaaS graph

Prompts live in tabs; the identity graph finds tools the browser policy doesn't cover

BYOD laptops and contractorsA browser extension that installs on unmanaged devicesIdentity and SaaS graph

Nothing you install through MDM reaches a personal laptop, and email metadata finds sign-ups from any device

Microsoft 365 E5Defender for Cloud Apps, Defender agent discovery, and PurviewCoding-agent hooks

Discovery, domain blocking, and Edge prompt DLP are already licensed; hooks decide what agents run

Jamf-managed Mac fleetJamf AI Governance and Jamf inventoryEndpoint observation or hooks

Managed settings configure supported tools; the second layer covers unsupported agents, browsers, and Windows

Engineering teams with CLI agentsEndpoint network observationCoding-agent hooks

Neither needs a root certificate; one ties connections to people, the other decides each tool call

Zscaler or Netskope already on every deviceYour SSE's AI controls and tenant headersCoding-agent hooks or endpoint observation

The SSE covers browsers; developer tools on its bypass list need another layer

An inventory this week, with no deploymentIdentity grants and expense dataMDM and EDR inventoryBoth use data you already hold; neither touches the network

Most organizations need two layers because the approaches fail in different places. Decrypting gateways lose sight of pinned and bypassed apps, browser tools lose sight of everything outside the tab, and inventories lose sight of use. Before you commit, run the proof-of-concept tests in shadow AI detection tools against your shortlist, including a personal account on an approved domain and a developer tool that refuses an inspecting certificate.

Where does Arcjet's approach fit, and where doesn't it?

Arcjet covers the endpoint observation and coding-agent hook rows. It fits Mac and Windows fleets where engineers run CLI agents and MCP servers, where TLS inspection breaks tools or isn't acceptable, and where you want each connection tied to a named person and one console for provider policies and hook policies. You deploy the agent through your MDM, including Jamf, and in the Arcjet Console, Discovery leads from People to Devices to AI usage, with a Providers view that shows which people, devices, and apps reach each service. Counts are connections, not prompts or tokens. The Claude Compliance API and OpenTelemetry add observe-only records for sessions that hooks don't cover.

Arcjet is the wrong choice in the following situations:

  • You need to read prompts. Arcjet doesn't decrypt TLS or inspect browser tabs. A browser extension such as Harmonic Security, Akamai Workforce Protector, or Prompt Security, or a decrypting SSE, does.
  • Your shadow AI is on unmanaged devices. The agent reaches only managed devices, so start with a browser tool built for unmanaged devices or an identity inventory.
  • You need to separate personal from company accounts on one hostname. Apply the vendor tenant controls through your gateway or MDM.
  • You need to find local models that make no network connection. Use MDM or EDR inventory.

For pricing and availability of the endpoint agent, book a demo. To start with coding agents, follow the Arcjet coding agents guide and publish a starter policy in dry run.

Frequently asked questions

Is endpoint or network shadow AI detection better?

Neither covers everything. A network gateway that decrypts TLS reads prompts and can insert tenant headers, but pinned apps and developer tools that refuse its root certificate end up on a bypass list, and laptops off the tunnel drop out. An endpoint agent sees which signed app opened each connection and who was signed in to the device, on any network, without decrypting, but it doesn't read prompts and doesn't reach unmanaged devices. Choose by where your AI use happens, and add a second layer for the first one's gaps.

Should I use a CASB or a browser extension for shadow AI?

Use a browser extension when most AI use happens in browser tabs, especially on contractor or BYOD devices, because it reads the prompt and the signed-in account in the page with no proxy or root certificate. Use a CASB or SSE when you already steer traffic through one and need controls beyond the browser, such as tenant header insertion for desktop apps. Neither sees a CLI coding agent's tool calls; that takes hooks.

Can any approach tell a personal ChatGPT or Claude account from a company one?

Not from the hostname, because personal and company sessions reach the same domains. A browser extension can read the account in the page, and a decrypting proxy can insert the vendor's tenant header, such as anthropic-allowed-org-ids for Claude or ChatGPT-Allowed-Workspace-Id for ChatGPT. GitHub Copilot routes plans to separate hostnames, and Cursor supports an AllowedTeamId policy through MDM.

Does Arcjet decrypt TLS or install a root certificate?

No. On macOS, Arcjet's endpoint agent is a Network Extension content filter, and on Windows it reads the server name from the TLS ClientHello through Windows' Packet Monitor API. It ties each connection to a signed app and a person and can allow or block a provider on the device. Because it doesn't decrypt, pinned apps and CLI agents keep working, and it doesn't read prompts.

Which shadow AI approach works for BYOD and contractors?

A browser extension that documents deployment on unmanaged devices, such as Akamai Workforce Protector, plus an identity and SaaS graph that finds AI sign-ups made with a work email from any device. Endpoint agents, on-device gateways, MDM inventory, and hooks installed through managed settings all require a managed device.

AI runtime security in your code

Protect your AI agent workflows with Arcjet

Arcjet runs inside your application, where it can use runtime context to enforce agent actions and budgets, detect prompt injection, and protect sensitive information before a workflow acts.