- AI governance is ultimately a visibility problem. Network and endpoint controls are getting smarter, but each can only govern the AI activity that appears within its inspection surface.
- The enterprise AI surface is expanding beyond traditional control points. Local MCP, desktop clients, embedded web surfaces, and agentic workflows create interactions that may be only partially visible—or never appear on the network at all.
- Effective AI governance requires an interaction layer. The strongest architecture combines network, endpoint, and interaction-layer controls, with each covering a distinct part of the AI lifecycle.
Network controls have gotten sharper about AI in the last year. Application control that identifies GenAI apps by protocol signature. Telemetry parsing for HTTP-based Model Context Protocol streams. Some implementations now add OCR to inspect sensitive data hidden inside image uploads. Real advances, all of them. But only when the traffic actually reaches an enforcement point in a form it can read.
That “when” is doing a lot of work. Network-layer AI governance inspects the portion of the AI surface that reaches a managed enforcement point, gets decrypted, and arrives with enough application context for the policy to bite. A growing share of the AI surface fails one or more of those conditions.
The Network Got Smarter. The Surface Got Wider.
Credit where it’s due. Network-layer AI controls in 2026 can identify GenAI applications and apply policy to them. Some implementations parse MCP and agent-to-agent traffic, logging methods, arguments, and tool calls, when those protocols run over supported transports and reach the enforcement point. Others add OCR to inspect image-embedded data. When AI activity shows up at the network in a form the control understands, more of it is legible than ever before.
Inspecting AI traffic that reaches an enforcement point is a different thing from governing every AI interaction. That distinction is easy to blur in a slide deck and harder to hold in an architectural evaluation.
Six Boundaries of Network-Layer AI Governance
Vendors claiming “AI-native governance” at the network layer usually answer objections about one specific condition, like TLS deep inspection or MCP support, as if resolving it addressed the whole surface. It doesn’t. Network-layer visibility has at least six distinct boundary conditions. Resolving one doesn’t resolve the other five.
No path: the traffic never reaches the enforcement point. Direct-to-internet applications, split-tunnel VPN connections, unmanaged endpoints, users on personal hotspots or public networks. What matters is whether the traffic actually reaches the inspection point; device ownership and physical location are secondary. Network-only enforcement can also create an evasion path: the same workflow may move to a device, application, or connection that skips it entirely.
No decryption: the traffic arrives, but stays unreadable. Certificate pinning, applications that reject interception certificates, unsupported encryption patterns, and the operational reality that many organizations exempt substantial traffic categories from TLS inspection to preserve performance and compatibility.
No semantic parsing: the payload is visible, but its AI meaning is not. Identifying that traffic is going to an AI service tells you nothing about what tool the agent called, what arguments it passed, or what the response then influenced. Protocol support is not surface coverage. The presence of MCP identification in a product doesn’t guarantee that every field, transport, or tool interaction is fully parsed.
No network event: the interaction never becomes traffic. Model Context Protocol supports a stdio transport in which an AI client launches a local MCP server as a child process and exchanges JSON-RPC messages through operating-system pipes: standard input and output between two processes on the same machine. Stdio is a standard MCP transport, and the protocol’s architecture guidance describes local MCP servers as typically using it. Nothing crosses the wire because the interaction never leaves the OS.
Incomplete context: the request is visible; the surrounding user action is not. Was the content typed, pasted from another application, uploaded from a specific file, or generated in-app? A DLP engine may detect a credential pattern in an outbound body and identify the destination service. That’s a long way from reconstructing the interaction sequence around it: where the content came from, which in-app surface received it, or what the user did with the model’s response. Traditional DLP was built to catch sensitive strings moving through a pipe. AI governance needs to understand what’s happening around those strings, too.
No post-response visibility: the network may see the model’s response come down the wire but nothing of what happens next. Copied into a code editor, pasted into an internal chat, forwarded to another agent as input. Once the response lands, the interaction continues off-network.
Answering “we support MCP inspection” addresses the semantic-parsing boundary for one protocol on supported transports. The other five conditions are untouched.
The Local MCP Case, Precisely
MCP shows the network boundary in its cleanest form. When it runs over a supported HTTP transport and crosses an inspected path, a network-layer control can identify the protocol, log tool calls, and apply policy. That capability is real. It’s also transport-dependent.
MCP explicitly supports local subprocess deployment, and its own materials describe local MCP servers as typically using stdio: a desktop AI client spawning a local MCP server as a child process, exchanging JSON-RPC messages through OS pipes between two processes on the same machine. That exchange never becomes a network flow. The network has nothing to inspect because the interaction is inside the operating system rather than on the wire.
A local MCP tool may later contact a remote service, and that downstream connection can be visible to a network control, even when the initiating MCP interaction wasn’t. What the control may not know is that the connection originated from an MCP tool call, which model requested it, what arguments were supplied, or what local data informed the action. Even when the tool call itself is visible, visibility alone doesn’t establish that the action was authorized.
Why EDR Doesn’t Rescue This Either
Moving from the network to the endpoint doesn’t automatically recover the missing semantics.
EDR observes the execution environment. It can log which executable launched an AI client, which child processes were spawned, which files were accessed, and which network connections followed. That telemetry is valuable, and EDR vendors are beginning to add dedicated AI-runtime inspection through agent integrations and network hooks. Those capabilities go beyond conventional process telemetry, which is precisely the point. Recovering AI semantics takes a new inspection surface, not just the presence of an endpoint agent. And any control that ships as an endpoint agent inherits the same routing constraint the network layer has: it sees what happens on machines the agent is installed on. Unmanaged devices, contractor laptops, and BYOD sessions remain outside its coverage envelope.
What conventional EDR does not natively provide is a semantic record of the AI interaction itself: the user’s prompt, the content supplied to the model, the tool-selection decision, the arguments passed through MCP, the content returned to the user. At a conventional process-telemetry layer, claude.exe spawning node.exe and accessing config.json can look like expected activity by trusted applications, even when the semantic purpose of that activity differs radically. Different behaviors may leave different signatures at the process layer, but the interaction-level content (what the user asked, what the agent decided, what data crossed the model) isn’t inherent in ordinary process telemetry.
EDR shows what the process did. What the model was asked, and why the agent acted, sits above that layer. Both matter, and neither replaces the other.
What to Ask on the Next Vendor Call
AI activity that runs in a sanctioned web application, from a managed device, on a managed network path, with TLS inspection enabled, in a protocol the network control understands: that’s the well-handled case. The rest of the enterprise AI surface (browser extensions, WebView2-based embedded panes, Electron desktop applications, dedicated native clients, local agents, local MCP servers, AI-native browsers) is where the six boundaries concentrate.
No single control covers all of them. The mature architecture layers them: network controls for traffic enforcement and downstream connections; endpoint controls for process behavior, file access, and activity that stays on the device; interaction-layer controls for what happens inside browser sessions and embedded-web application surfaces. Each layer has a definable envelope, and each has a definable boundary. Packets show the transmission. Processes show the execution. Whether either shows the interaction is a separate question.
Ask what the product can actually observe. Which interactions can the control see when the traffic never reaches the enforcement service? What does it see when TLS inspection isn’t applied? What semantic context does it parse, for which protocols and transports? What can it see when the interaction generates no network event at all? What interaction context does it preserve: typed vs. pasted, which in-app surface, prompt vs. response? Can it associate downstream network activity back to the initiating user or agent action?
Applied to a network-layer AI product, those questions define a coverage envelope with real edges to it. Applied to a product claiming interaction-layer visibility, Red Access included, they define the same map. Red Access operates at the interaction layer: observing and governing activity inside web browser sessions and embedded-web application surfaces rendered through Electron, WebView2, and related runtimes, such as Slack, ChatGPT/Claude desktop, Outlook, and many more.
The vendors will keep claiming they cover AI. Buyers who map coverage across the six boundaries above will find out who actually does.
