Endpoint AI security governs AI where it actually runs — the desktop apps, coding assistants, and local models on employee devices — because certificate-pinned applications and on-device inference structurally bypass the network proxies most enterprises rely on for AI visibility.
That is the short answer to what this category is and why it exists. The longer answer is architectural. For a decade, the standard way to watch data leave the company was to sit on the network — CASB, secure web gateway, forward proxy — and decrypt traffic in transit. AI broke that model in three places at once, and none of the three is fixable with a bigger proxy. This post walks through each gap, compares CASB and endpoint governance side by side, and answers the question buyers keep typing into search boxes: how do you monitor AI agents and local models on employee laptops?
Why can't your CASB see desktop AI apps?
Because of certificate pinning. A CASB or SWG inspects TLS traffic by intercepting the connection and presenting its own certificate — a man-in-the-middle the device is configured to trust. Certificate pinning defeats exactly that mechanism. Netskope's own technical documentation defines it plainly: "TLS certificate pinning is when a desktop or mobile application validates if the proposed server certificates match the hardcoded ones in the application." The same page concedes the consequence: "Predefined certificate pinned applications bypass the Netskope cloud by default." Traffic from pinned desktop apps is steered around inspection out of the box — not as a misconfiguration, but as designed behavior.
Cyberhaven, an endpoint DLP vendor, spells out why in its analysis of how pinning and end-to-end encryption broke the CASB model. The intercepting proxy "presents a certificate that is trusted by the device but does not match the exact certificate hard coded into the application and prevents the client from connecting to the server." Once an app pins, Cyberhaven writes, it is "fundamentally impossible for them to decrypt this traffic. Therefore, it is impossible to inspect this traffic and stop sensitive data from going to the cloud." The apps that pin are not obscure — Cyberhaven names Adobe Creative Cloud, Cisco Webex Teams, Dropbox, and Workday among them. And AI apps are joining the list: researchers at Lumia Security have reported that the ChatGPT macOS desktop app implements certificate pinning and refuses to start when it detects a non-allowed root certificate — which would place the most widely used AI desktop app outside your proxy's view entirely.
Zscaler's SSL inspection deployment guidance takes the same line as Netskope's: applications that pin certificates should be exempted from decryption. When both of the largest SSE vendors document the bypass in their own manuals, the conclusion writes itself. This is not a coverage gap someone will patch next quarter. It is structural.
What happens when the AI never touches the network at all?
Local model runtimes — Ollama, LM Studio, GPT4All, Jan — run inference on the device itself. A prompt to a local Llama or Mistral model never traverses your proxy because there is nothing to traverse: no outbound request, no TLS session, no log line. Network-layer tooling has literally nothing to inspect.
Visibility has to come from the host. Splunk, for example, ships a dedicated Technology Add-on for Ollama built to "illuminate shadow AI deployments," alongside companion guidance on detecting local LLMs with host-based telemetry — an acknowledgment from a major observability vendor that local AI is found on the endpoint or not at all. Process activity, model files on disk, localhost port bindings: these are all device signals. No credible enterprise survey quantifies how many corporate laptops run local models today, so treat any such percentage with suspicion — but the architecture question does not depend on prevalence. If one engineer loads customer data into a local model, the only place that event was ever observable was the device. The same logic applies to the local MCP servers security teams can't see.
How much AI use already escapes managed channels?
The telemetry that does exist is stark. Cyberhaven's 2026 AI Adoption & Risk Report — based, per the company, on "billions of real-world data movements around Generative AI SaaS applications, endpoint AI applications, and AI agents" — found that 39.7% of all data movements into AI tools involve sensitive data, that 32.3% of ChatGPT usage happens through personal accounts (24.9% for Gemini), and that the average employee enters sensitive data into an AI tool once every three days. Of the 100 most-used GenAI SaaS apps, 82% were classified medium, high, or critical risk. Nearly 90% of developers at leading AI-adopting companies use coding assistants — tools like Cursor and Claude Code that live in the IDE and terminal, not in a browser tab — client traffic that, like desktop apps, is structurally outside a standard proxied web session.
Browser-side telemetry points the same direction. LayerX's 2025 enterprise AI report reportedly found that 77% of employees paste data into GenAI prompts, that 71% of GenAI connections use personal rather than corporate accounts, and that 58% of even the corporate-account connections happen without SSO. Personal accounts mean no tenant controls, no audit trail, no retention terms — the textbook definition of shadow AI.
CASB vs endpoint AI governance: which layer sees what?
The honest comparison is not "CASB bad, endpoint good." It is a question of which surfaces each layer can physically observe.
| AI surface | CASB / SWG (network layer) | Endpoint AI governance (device layer) |
|---|---|---|
| Sanctioned SaaS AI in the browser | Visible and controllable — this is the CASB home turf | Visible at the point the prompt is composed |
| Personal-account AI in the browser | Sees the destination; tenant context and account distinction are weaker | Sees the app, the account context, and the content entered |
| Certificate-pinned desktop AI apps | Bypassed by default; traffic cannot be decrypted (Netskope, Cyberhaven) | Inspects content on-device, before encryption |
| AI coding assistants and IDEs | Non-browser client traffic; structurally parallel to desktop apps (no vendor-documented SSE coverage found) | Visible as local processes with observable data flows |
| Local models (Ollama, LM Studio) | Nothing to inspect — no network traffic is generated | Process, model files, and localhost bindings are all host telemetry |
| Blocking a known-bad domain for all users | Strong — one policy at the egress | Requires the agent to be deployed on every device |
The last row matters: network controls still do coarse blocking well, and endpoint agents only see devices they are installed on. But blocking is not governance. Cyberhaven's endpoint pitch — that agents "inspect the contents of the data on the device" so encrypted traffic can then travel to the server untouched — describes the only position from which pinned apps and local models are inspectable at all.
What does endpoint AI security actually cover?
A workable endpoint AI security program does four things:
- Discovery: inventory every AI surface on the device — browser AI, desktop apps, IDE assistants, agent frameworks, and local model runtimes — not just the domains in a proxy log.
- Classification: know what data is entering each prompt before it leaves the device, while it is still plaintext.
- Policy: allow, redact, or block per app, per account type, and per data class — a personal ChatGPT account and a sanctioned enterprise tenant deserve different rules.
- Evidence: a per-interaction record of which app saw which data classes, for audit and incident response.
This is the layer AccuroAI Endpoint AI Governance is built for: it deploys in under 30 minutes, discovers usage against a catalog of 1,400+ AI applications, and classifies prompt content with 40+ data classifiers and 60+ secret-type detectors at under 38ms p99 — on the device, before encryption, where pinning is irrelevant. The launch post covers the architecture in detail.
Who else is working at the device layer?
The market's answer to proxy blindness is a layer war, and it helps to know which layer each vendor actually owns. LayerX — whose browser-extension GenAI DLP monitors text input, copy/paste, and file uploads, and which was reportedly acquired by Akamai in 2026 — owns the browser, which means it covers browser AI but not native desktop apps or local models. Island sells an enterprise browser on the same scoping. Palo Alto's Prisma Browser adds generative AI guardrails that block sensitive pastes into public AI tools, with a March 2026 update adding protections against "shadow AI agents, prompt injection attacks, and agent hijacking" — again, inside the browser. Cyberhaven runs a full endpoint agent and argues the endpoint is "the new cloud control point" for precisely the pinning reasons above.
Microsoft Purview's AI coverage is also browser-centric: DLP is built into Edge for Business (stable version 144 and later), Chrome and Firefox require the Purview extension, and other browsers are treated as "unallowed browsers" and blocked outright. Its catalog of 19 unmanaged AI apps applies to Edge for Business inline protection — not to native desktop AI apps — and nothing in Microsoft's published DLP-for-AI documentation addresses local models. Even Purview's network-layer AI story depends on plugging in a SASE partner, with some integrations still in preview. Last verified: September 5, 2026. For how to weigh all of this in a purchase, see the workforce AI security buyer's guide.
FAQ
Can a CASB block the ChatGPT desktop app?
It can often block the destination at DNS or IP level, but it cannot inspect the traffic — pinned apps refuse man-in-the-middle certificates, and both Netskope and Zscaler document steering pinned apps around decryption. Blocking without inspection means no redaction, no data-class policy, and no record of what almost left.
How do you monitor local AI models on employee laptops?
With host telemetry, because there is no network traffic to monitor. Practical signals: running processes for Ollama, LM Studio, GPT4All, and Jan; model weight files on disk; and services bound to localhost ports. An endpoint agent that inventories AI runtimes and inspects what data reaches them is the only control that operates at the same layer as the model.
Is an enterprise browser enough?
It governs browser AI well — pastes, uploads, personal-account use — but by construction it cannot see native desktop apps, IDE assistants, or local models. If your developer population is anywhere near Cyberhaven's ~90% coding-assistant adoption figure, the browser is only part of your AI surface.
Does Microsoft Purview cover native desktop AI apps?
Microsoft's published DLP-for-AI documentation covers browser surfaces (Edge for Business, plus extensions for Chrome and Firefox) and Microsoft 365 Copilot. Native desktop AI clients and local models are not addressed in those documents. Last verified: September 5, 2026.
Where should an endpoint AI security program start?
With a device-layer usage audit: deploy discovery to a pilot group, enumerate every AI app, assistant, and runtime actually in use, and compare that inventory against what your proxy logs claim. The gap between the two lists is your business case.
Sources: Cyberhaven, "How cert pinning and E2EE broke your CASB" (Mar 2025, updated Jul 2025) · Netskope docs, "Certificate Pinned Applications" · Zscaler, "Deploying SSL/TLS Inspection" · Lumia Security on ChatGPT desktop certificate pinning · Cyberhaven 2026 AI Adoption & Risk Report · LayerX Enterprise AI & SaaS Data Security Report 2025 · Splunk Technology Add-on for Ollama · Microsoft Learn, browser DLP in Edge for Business · Microsoft Learn, Purview extension for Chrome. All sources accessed September 5, 2026.
Related: Endpoint AI Governance · Introducing Endpoint AI Governance · The Shadow AI Pillar Guide · Workforce AI Security Buyer's Guide.