<aside> 📝

Background

The AI application research team reached out to the security/network team to ask how to prevent users from using coding-assistant-style tools, such as Codex-like software, to connect to unauthorized external MCP servers or external large language models.

The intended control objective was to ensure that users can only use approved, locally deployed models, and cannot bypass the internal AI environment by configuring external model endpoints, external MCP connectors, or unapproved tool servers.

A senior engineer responsible for network controls involved me in the review. During the analysis, we found that direct domain blocking was not feasible in this case because the same domain, such as copilot.xxx.com, was used both for model-related API traffic and for user authentication/login. If the entire domain were blocked, users might lose the ability to log in or use approved product functions.

Therefore, the issue was not a simple “block the domain” problem. It required more granular control over AI-related endpoints, session behavior, tool connections, and data movement.

</aside>

The main challenge is that modern AI applications often reuse the same domains for multiple purposes, including login, authentication, model API access, web UI traffic, telemetry, and real-time session communication. As a result, domain-level blocking can be too coarse-grained and may cause business disruption.

The security concern is not only whether users can open the AI application, but whether they can use it to:

1. Connect to unauthorized external LLMs.
2. Configure unapproved external MCP servers.
3. Send internal code, credentials, documents, or sensitive business data to external services.
4. Maintain long-running AI sessions with external endpoints.
5. Allow AI tools or agents to access local files, internal APIs, databases, browsers, or developer environments.

Why WebSocket Blocking Is Only a Compensating Control

WebSocket blocking is better understood as a compensating control, not the primary solution for Shadow AI or Shadow MCP governance.

In this case, because the same domain was used for both authentication and model-related traffic, directly blocking the domain would affect legitimate login flows. A more targeted option is to identify specific AI endpoints or long-connection behaviors and apply session-level restrictions only where domain-level blocking is not feasible.

This can be described as:

Targeted WebSocket control for specific AI endpoints where domain-level blocking is not feasible.

Or more generally:

AI session persistence control / AI session continuity control.

The goal is not necessarily to make the entire website inaccessible. The goal is to prevent unauthorized external AI sessions from maintaining stable long-running connections, preserving context, or continuously processing sensitive inputs.