Why your firewall, proxy and CASB miss AI tools running on laptops
In short
- Firewall, proxy and CASB work at the network edge. They see destinations, domains and data volumes, not content and not processes.
- Four things stay invisible to all three: local models, AI features inside browser extensions and desktop apps, the content of encrypted API calls, and agent actions on the device.
- The gap cannot be closed with more rules at the gateway. It can only be closed on the device.
What each control actually sees
| Control | Sees | Does not see |
|---|---|---|
| Network firewall | destination IP, port, data volume, the domain (SNI) with DPI | prompt content, the process, local models, agent actions |
| Web proxy with TLS inspection | URL and content for traffic without certificate pinning | local models, devices outside the proxy, streamed responses mid-transfer |
| CASB | SaaS services in use, accounts, uploads with API integration | prompt content, extensions, local models, terminal agents |
| EDR | processes, file access, known malware patterns | whether a process generates AI traffic and what it contains |
| Endpoint AI detection | process, destination and content before encryption, local models, agent tool calls | nothing outside the device |
Every row has its purpose. None of the first four was built to answer whether an employee is pasting a customer list into a language model right now.
Blind spot 1: local models produce no traffic
Ollama, LM Studio, models built into the IDE and locally running coding agents process prompts on the same machine. There is no outbound traffic for a firewall to see. The only visible effect at the gateway is the model download at the start, and that looks like any other large download.
For data security this is only apparently harmless. A local model can access files and systems through agents and MCP servers, and the results leave afterwards anyway, into a ticket or a repository. Analyzing what the model gets to see can only happen on the device.
Blind spot 2: AI lives in extensions and apps, not in domains
The domain list was the first reflex of many teams: block or log chatgpt.com, claude.ai, gemini.google.com. That captures the browser tab but not the browser extension that sends page content to a summarization service, not the Copilot in Office, not the assistant in the IDE, and not the AI feature a SaaS product calls in the background through its own API.
These calls go to domains on no list, or to the same domains the approved service uses. At the network edge they are indistinguishable from ordinary application traffic.
Blind spot 3: encryption hides the content
AI API calls are TLS-encrypted. A firewall sees bytes and a destination. A proxy with TLS inspection sees the content, with three limitations:
- Apps with certificate pinning reject the proxy certificate.
- Devices outside the corporate network must be forced through the proxy, otherwise the traffic bypasses it.
- Responses arrive as server-sent events or WebSocket frames. Inspecting the stream only at the end means the data already passed.
And even when the proxy reads the prompt, it can do only two things: pass or block. Replacing the customer number in the prompt with a placeholder and forwarding the rest is beyond it.
Blind spot 4: agents act on the device
A coding agent reads a configuration file, calls an internal API, writes a result into a repository. An MCP server gives an assistant access to mail, database or shell. These actions happen as a process on the device. At most the last step, an API call, shows up at the gateway, without any connection to the steps before.
The question "Is this agent reading a .env file right now and sending the content out?" can only be answered if you see both steps: the source and the sink. That is only possible where the agent runs.
What is different on the device
A component on the endpoint sits in the local network path, before encryption. It sees the process that generates the traffic, the destination and the content. Patronus Protect recognizes AI traffic there by behavior, not by a domain list: patterns in requests and responses, streaming signatures, process origin. New tools are detected before anyone knows their domain. The technical details are in the post on detection across WebSockets, SSE and gRPC.
Because inspection happens before encryption, the reaction can do more than block: redact, log, escalate for approval. And because it happens on the device, it also applies in the home office, without a forced proxy.
What firewall, proxy and CASB keep doing
None of them becomes redundant. The firewall protects the network, the proxy enforces web policy, the CASB inventories SaaS. Endpoint detection adds exactly the layer these tools were not built for: the content of an AI interaction and the process that triggers it.
To check what really runs on your devices: Patronus Monitor shows it for free, without touching the traffic. More on the approach on the shadow AI discovery page.
Sources and context
- The description of the controls follows the usual product categories; vendor-specific extras were not assessed.
- On agents and MCP: The MCP attack surface nobody is securing.
- On the blind spots of the existing stack: Shadow AI: blind spots in the existing security stack.
- As of September 7, 2026.
FAQ
Frequently asked questions
Why can't our firewall catch AI tools running locally on laptops?
Because a network firewall only sees traffic that leaves the laptop, and only as an encrypted destination. A local model such as Ollama produces no outbound traffic. An AI browser extension looks like ordinary HTTPS. Detection has to happen on the device, where the process, the payload and the destination are still visible.
Is a CASB enough to find shadow AI?
A CASB finds SaaS services that are visible through the proxy or an API integration. It sees that chatgpt.com was opened, but not what was typed, and it sees neither local models nor extensions nor agents on the device.
Does TLS inspection at the proxy help?
For cloud tools without certificate pinning, yes, the content becomes readable. It does not help with local models, with devices outside the corporate network that are not forced through the proxy, or with streams that would have to be inspected mid-transfer. And it can only block, not redact.
Is there a tool that monitors AI usage before it hits our network?
Yes. A component on the endpoint, such as Patronus Protect, sits in the local network path and classifies AI traffic before encryption and before the gateway. It sees browser tools, desktop apps, IDE assistants, local models and agents, without per-tool integrations.