Detecting Shadow AI in the Enterprise: The MCP stdio Gap
Close the detection gap for Shadow AI. Learn why the Model Context Protocol stdio transport bypasses CASBs and how to use endpoint telemetry for detection.
Disclaimer
This article is intended for informational purposes and reflects the state of published research and industry practice as of early 2026. It is not professional security advice. Your specific environment, threat model, and regulatory obligations will shape how these principles apply to your situation.
For Security Leaders
Enterprise deployment of AI agents using the Model Context Protocol (MCP) introduces a structural detection blind spot that traditional network-based security tools cannot see. By design, the protocol’s primary transport mode uses local inter-process communication that generates no network artifacts for detection or interception. This allows unsanctioned or malicious AI tools to operate with full access to user credentials while remaining functionally invisible to CASB and proxy controls that lack endpoint-layer visibility into inter-process communication.
What this means for your organization:
Traditional network-based AI governance is blind to local agent activity. When tools operate over inter-process communication, CASB and web proxy tools cannot distinguish between sanctioned and unsanctioned AI orchestration.
Developer workstations are the primary staging ground for AI supply chain attacks. Malicious MCP servers installed locally use the user’s existing permissions to access credentials and data without triggering new authentication events.
The absence of a network artifact is a protocol design choice, not a misconfiguration. Security teams cannot wait for a vendor patch to close a gap that is part of the underlying communication specification.
What to tell your teams:
Deploy file integrity monitoring on known AI configuration paths. Monitor for writes to local JSON config files used by Claude Desktop and Cursor to inventory which MCP servers are actually in use.
Enable EDR telemetry for subprocess argument logging. Configure endpoint detection to flag the launch of known MCP server packages from untrusted or public registries.
Establish an approved-server inventory for local AI tools. Define a clear list of sanctioned MCP servers and block the installation of any package that has not undergone architectural review.
Audit subprocess file access patterns for credential exfiltration. Monitor for AI-initiated processes performing bulk reads of SSH keys, environment files, or cloud configuration directories.
When the AI Gateway Bypasses the Gate: MCP Servers, Subprocess Telemetry, and the Enterprise Detection Gap
A developer opens their code editor. Before any code is written, the application reads a JSON configuration file and spawns three subprocess trees: a Python process connected to an internal database query tool, a Node process for a web search integration, and another Node process connected to a code search API. Each process receives credentials for production systems through the environment variables the config file supplies. The MCP protocol channel between the AI client and each subprocess produces no outbound network connection. No identity provider (IdP) audit event is generated. The MCP protocol messages are not visible as network events, and most EDR/CASB/SIEM pipelines will not label the subprocess activity as MCP orchestration unless they are explicitly configured to watch MCP client config paths, child-process launches, and tool-specific file access. The subprocess spawn, the credential handoff through environment variables, and the MCP protocol messages coordinating those tool calls all live within inter-process communication (IPC). The MCP servers themselves may connect outward when executing their tools, but that traffic appears as ordinary subprocess network activity with no identifier linking it to the MCP orchestration layer. This is the default behavior of MCP clients on developer workstations today, and it is a protocol design choice, not a misconfiguration.
What I would examine before anything else is the transport layer connecting the AI client to enterprise systems, not the model itself. The MCP specification defines two transport modes: stdio and Streamable HTTP. Under stdio, the AI client launches each registered server as a local subprocess and exchanges all messages through that process’s stdin and stdout channels. Between the AI client and the MCP server, no socket is opened and no DNS query is issued: that channel is entirely IPC. After the MCP server receives and executes a tool call, however, outbound connections do flow: a web search server makes requests to a search API, a database tool connects to the database endpoint. That traffic is real and visible on the network, but it carries no identifier linking it to the MCP orchestration layer that triggered it. The MCP specification’s authorization section explicitly instructs stdio implementations not to follow its OAuth requirements, directing them instead to retrieve credentials from the environment. The specification created this gap deliberately.
That specification choice has structural consequences. MCP servers running as local subprocesses use the stdio transport by design: it is the natural implementation for developer tooling integrated into code editors and AI clients. In common desktop-client configurations, credentials are often supplied through env fields in local JSON configuration files. Those config files sit at predictable paths: on macOS, ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows, %APPDATA%\Claude\claude_desktop_config.json. While the MCP specification directs stdio implementations to retrieve credentials from the environment without mandating plaintext storage, many current implementations result in API keys and access tokens being stored directly in the env field of these configuration files. Any process with read access to those paths collects credentials for every service the user’s MCP stack touches.
The detection architecture enterprise security teams inherited assumes every unsanctioned tool announces itself on the network.
What I find notable in the current moment is that this assumption does not break at the edge cases but at the center of the deployment model. CASBs were built around the network connection as the detection primitive: an employee using an unsanctioned SaaS tool produces an HTTPS request to an identifiable domain, that request can be intercepted, categorized, and acted on. That assumption transferred cleanly to AI governance tools, which classify and enforce against connections to known AI API domains. Any MCP server running locally as a subprocess uses a transport that produces no network connection between the AI client and the MCP server.
At the endpoint layer, an EDR agent watching process telemetry sees what the protocol produces: a parent application spawning a child process, typically node or python, with arguments drawn from a config file. The child process is behaviorally indistinguishable from any other developer tool invoked the same way. An npm run dev invocation and an MCP server launch produce identical process tree signatures unless the EDR specifically watches for known MCP server package names or config file paths. This pattern shares characteristics with T1036 (Masquerading) in MITRE ATT&CK terms, where a server is launched under a name or package that is indistinguishable from legitimate developer tooling to evade detection. The only endpoint artifact that reliably identifies an MCP server registration is a write or modification event on the known config file paths. File integrity monitoring (FIM) against those paths would give a security team a coarse inventory of registered servers, but it does not capture servers launched from the command line without config file modification. Evasion would more likely involve disabling or modifying monitoring coverage, or placing payloads in already-excluded paths, depending on the control design.
The CASB failure mode is more architecturally precise. CASB products classify applications by their network endpoints. An MCP server that calls the Anthropic or OpenAI API for model inference will appear in CASB telemetry as ordinary sanctioned AI API traffic, because the CASB sees the destination domain, not the locally installed server generating the request. The distinction between an approved AI development tool and an unauthorized data exfiltration server routing through the same API endpoint is not recoverable from the network record alone. An API-mode CASB that relies on cloud provider log access can see that API calls were made under a user’s credentials, but cannot determine whether those calls originated from a direct integration or from an MCP server running on that user’s machine.
The OAuth audit trail, most commonly cited as the detection path for unauthorized AI tool adoption, behaves differently depending on transport. When an MCP server runs over HTTP, the client connection to a remote endpoint produces outbound traffic visible in firewall and proxy logs. If the server requires authentication, it also triggers a Dynamic Client Registration event and an Authorization Code grant at its configured authorization server. When that server is the enterprise IdP, those events appear in Entra ID or Okta audit logs and are catchable by detection teams with alert rules for novel client registrations. When the MCP server uses its own OAuth infrastructure, the authorization events land outside enterprise visibility, though the network connections to that infrastructure still appear in firewall logs. When a server runs over stdio, none of this exists. No remote connection is made between client and server, so no firewall artifact is produced. The protocol specification’s explicit exclusion of stdio from the OAuth flow is architecturally reasonable: a subprocess running under the user’s account already has access to everything the user has access to, making OAuth delegation largely redundant as a permission mechanism. The stdio gap is the complete absence of any network or authentication artifact: no firewall event, no OAuth flow, no registration record of any kind.
Inside that blind spot, three attack variants share a common surface: the gap between what the AI model reads in tool descriptions and what the user sees.
MCP servers expose their capabilities to the AI model through tool descriptions: structured metadata with a name and a free-text description that the model reads when deciding which tools to invoke. That metadata is separate from what the user sees in the client interface. A malicious tool description can contain instructions that are invisible in simplified UI rendering but fully visible to the model. Invariant Labs demonstrated this in April 2025 against the Cursor MCP client: a server containing hidden instructions in tool metadata caused the model to read SSH key files and pass their contents through a side channel encoded in an API call parameter, without producing any entry in user-facing interaction logs. The technique requires no exploitation of an implementation vulnerability. It follows from the design separation between model-visible metadata and user-visible interface elements. The OWASP Top 10 for Agentic Applications (December 2025) ranks this class of attack first, designating it ASI01 Agent Goal Hijack, reflecting both the frequency with which it appears in practice and the architectural difficulty of containing it.
A second variant exploits the same gap between what the AI model reads in tool descriptions and what the user sees in the client interface, but defers the malicious payload to a later point. A server presents benign tool descriptions at initial installation, passes whatever approval process an organization runs, and then modifies those descriptions in a subsequent update so the model receives different instructions at the next session. This pattern is called a rug pull, and it bypasses any inspection gated on the server’s initial state. The access control policies in AgentBound (Bühler et al., accepted at FSE 2026) address this with tool-pinning and source-code-derived policy generation, achieving 80.9% accuracy in automatically constraining server permissions to only what the implementation actually requires. That 19.1% error rate is notable: enforcement without human review creates residual risk of both over-permissioning and false blocking.
A third variant operates through composition rather than deception. An agent authorized to use three individually scope-limited tools can invoke them in a deliberate sequence that produces an outcome none of the individual tool permissions would authorize: read a config file, extract a database credential from it, then pass that credential as an argument to a query tool the agent is separately permitted to call. Each invocation is individually authorized. The combined effect is not. No current endpoint telemetry or SIEM rule inspects the aggregate outcome of a sequence of MCP tool calls; detection coverage is per-call, not per-chain. This is the structural analog of privilege escalation through combined API calls, and it is the attack surface where authorization model design and detection architecture diverge most completely.
The Agent-to-Agent (A2A) protocol, donated to the Linux Foundation in June 2025 and now supported by 150+ organizations, introduces a genuinely different detection surface through its Agent Card mechanism. An A2A-compliant agent serves a JSON metadata document at /.well-known/agent-card.json describing its capabilities, skills, and authentication requirements. Network scanners can enumerate these endpoints across internal IP space and build an inventory of declared agents. The v1.0 specification adds cryptographic signing to Agent Cards, enabling trust anchor verification. This is architecturally sound. The catch is that A2A compliance is opt-in and requires deliberate implementation. No major agent framework enables it by default. Visible agents are the compliant ones. Invisible agents are the problem population. The detection surface therefore covers exactly the set of agents least likely to represent unsanctioned deployment.
MCP server registries have the same structural properties that preceded large-scale compromise in npm and PyPI: public repositories of packages that install and execute on developer machines, with community-sourced authorship, minimal pre-publication vetting, and namespace collision as a vector. Adversarial attention has already arrived. The LiteLLM supply chain incident of March 2026 demonstrated the maturity of adversarial interest in AI tooling infrastructure: two PyPI versions of a widely deployed AI proxy package were compromised with a credential stealer capable of exfiltrating cloud credentials, SSH keys, and Kubernetes secrets. Official reports confirmed the harvesting of these sensitive artifacts; third-party analyses also reported lateral movement and backdoor attempts targeting container environments. The detection primitive distinguishing a tampered MCP server from a legitimate one with identical process and network behavior does not yet exist at the signature level. Behavioral detection, flagging bulk reads of credential files and cloud configuration within a single subprocess execution context, is the most tractable current approach. It requires EDR telemetry that includes subprocess argument logging and file access patterns for processes launched from the known config file paths, which is not a default EDR configuration.
A compromised sanctioned MCP server and an insider-deployed unsanctioned one produce identical observable artifacts. The execution path is fully determined by what is written in the config file, not by the identity or intent of the actor who wrote it: identical process trees, identical config file entries, identical API call patterns result from all four attacker categories documented in the field’s most-cited systematic threat taxonomy. That taxonomy (Hou et al., arXiv:2503.23278, 70+ citations since March 2025) maps 16 threat scenarios across Malicious Developer, External Attacker, Malicious User, and Security Flaws categories. The implication for detection is that no artifact available to current endpoint or cloud tooling can distinguish between them after the fact.
No purpose-built detection rules for MCP server deployment or agent skill registration exist as a community-vetted artifact. Sigma rules, the shared format used by the security practitioner community for portable endpoint and network detection logic, have no MCP-specific entries in the SigmaHQ main repository as of May 2026. The only SigmaHQ artifact referencing MCP is a tool that exposes Sigma rule validation capabilities to AI assistants, not a rule set for detecting MCP activity. The absence confirms that the detection methodology for this class of deployment has not yet been codified where security teams look for it.
The detection surface for stdio-transport MCP is the endpoint file layer. Everything else is noise or misattribution.
What I take from this architecture is a specific investment ordering, not a call for new vendor tooling.
The current model treats the network as the primary detection surface for shadow AI. That model works for HTTP-transport MCP deployments and for direct browser-based AI SaaS usage. It cannot surface the MCP orchestration layer for any MCP deployment running locally under stdio: the client-server channel produces nothing to intercept, and the downstream tool executions appear as ordinary subprocess network traffic. The detection investment needs to shift toward the endpoint file layer: file integrity monitoring on the known config file paths, behavioral anomaly detection on subprocess file access patterns, and private registry enforcement that blocks installation from public sources before an unauthorized server ever reaches a developer workstation.
The governance gap documented in Errico et al. (arXiv:2511.20920) is real and specific. NIST AI RMF 1.0 and ISO/IEC 42001:2023 both predate the MCP specification, and neither addresses dynamic tool invocation across trust boundaries, the policy distinction between sanctioned and unsanctioned agent deployment, or the runtime monitoring requirements for systems that initiate actions in external services without synchronous human review. The Cloud Security Alliance has published an advisory Agentic Profile for the NIST AI RMF, but advisory guidance carries no compliance weight. The practical enforcement boundary proposed by academic governance research is categorical: prohibit local MCP server execution on user machines except for explicitly approved servers, requiring remote, containerized deployments managed through centralized infrastructure for everything else. That is an architectural constraint, not a policy document.
Shadow AI incidents carry a $670,000 cost premium per breach, according to the IBM Security Cost of a Data Breach Report 2025, which surveyed 600 organizations. Among the organizations that experienced AI-specific breaches, 97% lacked proper AI access controls. Those figures describe the cost of the current state. The trajectory of the supply chain threat, visible in the structural parallel between MCP registries and npm and PyPI before the adversarial pressure peaked, suggests that the detection investment required will be substantially higher if it is reactive rather than proactive.
The governance gap and the tooling gap are unlikely to close together or quickly. Framework revisions produce updated documents; updated documents do not reduce operational exposure without corresponding enforcement mechanisms and detection capabilities in place. Endpoint detection vendors face development cycles, telemetry pipeline changes, and customer deployment timelines before any new capability reaches production. The exposure window has no reliable end date.
The controls most commonly proposed for this gap are weaker than they appear. Registry enforcement is porous: a developer intent on using a specific server installs it from a GitHub URL, a downloaded tarball, or a package copied from a personal machine. The installation source is irrelevant to the registration event. The config file path write is the only detection primitive that holds regardless of how the package arrived: any server added through the MCP client’s configuration produces a write event at a known path. Monitoring that signal, combined with an approved-server inventory and a defined policy for how inclusion is granted and revoked, is the most defensible organizational control currently available. General enterprise requirements around configuration management and software inventory could technically apply here, but no AI-specific governance framework draws that connection to AI tool deployment. Organizations that want this coverage have to make the mapping themselves.
Of the available controls, the approved-server inventory is the pre-breach decision that makes everything else actionable: without a baseline of authorized servers, a config file write event is noise rather than signal. Config file path monitoring is the registration primitive, the earliest detection point for a new server entry regardless of how the package arrived. Behavioral anomaly detection on subprocess file access patterns is the control that changes the outcome of an incident already underway: bulk reads of credential files within a single MCP server execution context are the observable trace of active exploitation in progress. Registry enforcement sits below all three: it raises the barrier for casual installation but a determined developer routes around it in minutes.
Peace. Stay curious! End of transmission.
Fact-Check Appendix
Statement: “Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.”
Source: MCP Specification v2025-03-26, Authorization section (normative).
URL: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization
Statement: Shadow AI breaches averaged $4.63 million versus a $3.96 million baseline, a $670,000 premium. Among the organizations that experienced AI-specific breaches, 97% lacked proper AI access controls.
Source: IBM Security / Ponemon Institute, Cost of a Data Breach Report 2025. 600 organizations surveyed.
URL: https://www.ibm.com/reports/data-breach
Statement: AgentBound achieves 80.9% accuracy in automatically generating access control policies from MCP server source code. Dataset of 296 widely deployed MCP servers.
Source: Bühler, C., Biagiola, M., Di Grazia, L., Salvaneschi, G., “AgentBound: Securing Execution Boundaries of AI Agents” (FSE 2026, 34th ACM Joint ESEC/FSE).
URL: https://arxiv.org/abs/2510.21236
Statement: Hou et al. maps 16 threat scenarios across four attacker categories to the MCP lifecycle.
Source: Hou, X., Zhao, Y., Wang, S., Wang, H., arXiv:2503.23278 (v3, October 7, 2025). 70+ citations.
URL: https://arxiv.org/abs/2503.23278
Statement: NIST AI RMF does not specifically address dynamic tool invocation and cross-system data flows. ISO/IEC 42001 and 27001 do not provide controls for MCP-style protocol security, agent authentication and authorization, or runtime monitoring.
Source: Errico, H., Ngiam, J., Sojan, S., arXiv:2511.20920 (November 25, 2025).
URL: https://arxiv.org/abs/2511.20920
Statement: A2A protocol supports 150+ organizations as of April 2026; Agent Cards served at /.well-known/agent-card.json; Signed Agent Cards in v1.0; compliance is opt-in.
Source: Agent2Agent Protocol Specification, Linux Foundation; Linux Foundation press release (April 9, 2026).
URL: https://a2a-protocol.org/latest/specification/ | https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
Statement: LiteLLM PyPI packages 1.82.7 and 1.82.8 were compromised in March 2026 with a credential stealer capable of exfiltrating cloud credentials, SSH keys, and Kubernetes secrets.
Source: LiteLLM, “Security Update: Suspected Supply Chain Incident” (March 2026).
URL: https://docs.litellm.ai/blog/security-update-march-2026
Statement: T1036 Masquerading is a technique where attackers manipulate artifacts to appear legitimate; its prevalence is documented across numerous enterprise threat reports.
Source: MITRE ATT&CK for Enterprise v19 (released April 28, 2026).
URL: https://attack.mitre.org/techniques/T1036/
Statement: The OWASP Top 10 for Agentic Applications (December 2025) ranks tool description hijacking first, designating it ASI01 Agent Goal Hijack.
Source: OWASP Gen AI Security Project, “Top 10 for Agentic Applications” (December 9, 2025).
URL: https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
Top 5 Authoritative Sources
MCP Specification v2025-03-26 (Anthropic / MCP Working Group) - normative reference for transport architecture and OAuth requirements: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports
Bühler et al., “AgentBound: Securing Execution Boundaries of AI Agents” (FSE 2026) - the only peer-reviewed enforcement solution for MCP access control, with a 296-server empirical dataset: https://arxiv.org/abs/2510.21236
Errico et al., “Securing the Model Context Protocol (MCP): Risks, Controls, and Governance” (arXiv:2511.20920) - primary academic treatment of the NIST AI RMF and ISO 42001 governance gaps: https://arxiv.org/abs/2511.20920
IBM Security / Ponemon Institute, Cost of a Data Breach Report 2025 - primary cost quantification for shadow AI incidents across 600 organizations: https://www.ibm.com/reports/data-breach
Hou et al., “Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions” (arXiv:2503.23278) - foundational systematic threat taxonomy with 70+ citations: https://arxiv.org/abs/2503.23278