MCP stdio sanitization fails when arguments reach OS commands

At a glance

What this is: This analysis shows that MCP stdio sanitization can be bypassed when language arguments invoke operating-system commands, turning a defended input path into a remote code execution risk.

Why it matters: It matters because IAM and NHI teams must treat MCP-connected AI services as privileged execution surfaces, not just data interfaces, and govern their authentication, isolation, and command controls accordingly.

👉 Read OXSecurity's analysis of MCP stdio command execution risk

Context

MCP stdio configurations create a direct bridge between user input and execution context, which makes them sensitive identity and access surfaces rather than simple integration plumbing. When command handling is exposed through AI services, the governance question becomes who or what is allowed to execute code, not just who can submit text.

The failure mode here is familiar to identity teams: a control that blocks obvious input patterns can still leave the execution path open if downstream language behaviour can spawn OS commands. For NHI governance, that means authentication, sandboxing, and command disablement need to be designed around runtime execution paths, not just request validation.

Key questions

Q: How should security teams govern AI services that expose stdio command execution?

A: Treat them as privileged non-human identities, not simple application endpoints. Require authentication, isolate the runtime, scope the allowed commands, and log every execution path that can reach the operating system. If the service can access secrets or infrastructure, govern it with the same discipline you would apply to a high-risk service account.

Q: Why do sanitised MCP inputs still leave organisations exposed to command execution risk?

A: Because sanitisation only blocks visible payload patterns. It does not fully control what Python, Node.js, or other runtimes do with approved arguments once they are inside the execution stack. The risk persists when downstream interpreter behaviour can invoke shell commands that the input filter never sees.

Q: What breaks when AI runtimes are deployed without authentication?

A: Without authentication, the service becomes a reachable trust boundary rather than a controlled internal capability. Attackers can probe endpoints, submit crafted payloads, and use built-in export or push functions to move leaked data out of the environment. In practice, unauthenticated access turns one software bug into a much larger exposure problem.

Q: What should teams do when an MCP deployment can reach secrets and infrastructure?

A: Reduce the blast radius before expanding use. Put the service in a sandbox, remove unnecessary command execution, and ensure the endpoint is protected by identity controls and network containment. If those controls are missing, the deployment should be treated as an unmanaged privileged path.

Technical breakdown

Why MCP stdio creates an execution boundary problem

MCP, or Model Context Protocol, connects AI systems to tools and data sources. In stdio mode, the protocol can move from data exchange into command execution if the server accepts user-controlled arguments that a runtime such as Python or Node.js can translate into shell activity. That makes the boundary between input validation and execution dangerously thin. Sanitising obvious metacharacters helps, but it does not eliminate every invocation path because the dangerous behaviour can emerge in downstream interpreter handling, not in the original payload. The architectural problem is that the application trusts a validation layer to constrain a capability that exists deeper in the execution stack.

Practical implication: treat stdio-enabled MCP servers as execution surfaces and isolate them before allowing any user-controlled input path.

Why sanitisation alone does not stop command execution

Input sanitisation filters characters and command fragments, but it cannot reliably model all interpreter-specific ways to reach the operating system. If the application permits approved commands such as python or npx, those commands may still accept arguments that trigger shell execution indirectly. That is why the attack surface can persist even when special characters are blocked. The issue is not simply malformed input, but a mismatch between request-layer controls and runtime behaviour. In identity terms, the privilege boundary is being defined too early. The control assumes the validation stage can predict the full execution chain, which is not true for complex language runtimes.

Practical implication: disable command execution where it is not strictly required and require explicit approval for any stdio path that can invoke system commands.

Why unauthenticated AI services expand the blast radius

When an AI service is exposed without authentication, the problem is no longer only code execution. An attacker who reaches the service can potentially access secrets, environment variables, and adjacent infrastructure, then move laterally within the hosting network. That is an NHI governance issue because the service itself is acting as a non-human identity with privileges that need lifecycle control, access scoping, and monitoring. The architectural weakness is that access to the AI interface becomes equivalent to access to the underlying runtime. Once that shortcut exists, command execution and secret exposure become linked rather than separate risks.

Practical implication: put authentication, least privilege, and network containment in front of any AI service that can touch secrets or infrastructure.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI integration point into a command-execution foothold that exposes secrets and enables broader infrastructure compromise.

1. Entry occurs through an AI service or MCP stdio path that accepts user-controlled input and exposes command-capable functionality.
2. Escalation follows when interpreter arguments invoke operating-system commands, bypassing basic sanitisation and reaching code execution.
3. Impact is server takeover, secret exposure, and potential lateral movement across the hosting network through the compromised AI runtime.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP stdio input sanitisation is not a sufficient governance boundary. The article shows that blocking obvious characters does not neutralise execution paths when downstream runtimes can still invoke the operating system. That matters because identity governance fails when it mistakes request filtering for privilege containment. Practitioners should treat stdio-connected AI services as execution-capable NHI assets, not as benign integrations.

Command execution exposure creates an identity problem before it becomes a code problem. Once user input can influence runtime execution, the service itself behaves like a privileged non-human identity that needs authentication, scoping, and monitoring. The important point is not just that an exploit exists, but that the control model assumed input control was equivalent to execution control. Practitioners need to reframe these systems as governed identities with blast radius, not just applications with validation logic.

Sandboxing is a containment requirement, not a hardening nice-to-have. When AI services can reach API keys, environment variables, and host networks, an exploit becomes a privilege propagation event. That is the same structural pattern identity teams see in overprivileged service accounts: one failure opens multiple downstream paths. Practitioners should therefore align MCP deployments with isolation-first design and explicit privilege boundaries.

Unauthenticated AI access is the real accelerator behind MCP abuse. The article notes that unauthenticated AI services can expose sensitive information and support lateral movement, which collapses the distinction between external access and internal trust. That is a governance failure because the service is allowed to act before it is identified. Practitioners should require identity enforcement in front of every AI endpoint that can execute code or access secrets.

Shadow AI now includes execution-capable interfaces, not only hidden models. If a team deploys MCP endpoints without central visibility, it creates unmanaged non-human identities with command authority. The named concept here is execution boundary drift, where the interface that was meant to pass context silently becomes a route to OS-level action. Practitioners should inventory AI systems by runtime privilege, not by model count.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how fast protocol-level exposure can scale when runtime interfaces are left visible.
• The next step is to compare MCP exposure patterns with the 52 NHI breaches Report and map which privileged paths most often turn into lateral movement.

What this signals

The governance lesson is that MCP exposure should now be reviewed as part of NHI programme design, not as an isolated application issue. When AI infrastructure is leaking 5x faster than core LLM providers, the control question shifts from whether a service is authenticated to whether its runtime privileges are bounded, observable, and revocable.

Execution boundary drift: this is the pattern where a data-passing interface quietly becomes an execution-capable identity. Teams that already rely on the OWASP Non-Human Identity Top 10 should map stdio-enabled MCP services to the same privilege, authentication, and lifecycle controls used for other high-risk NHI assets.

For practitioners

• Isolate every stdio-enabled MCP server Run code and stdio MCP servers inside an isolated sandbox so a compromise cannot reach secrets, environment variables, or the hosting network.
• Disable command execution by default Remove stdio command execution from deployments that do not explicitly require it, then allow it only for approved users and tightly defined use cases.
• Add authentication before any AI runtime reaches sensitive data Place strong authentication and proper access controls in front of AI services that can touch API keys, environment variables, or internal APIs.
• Review interpreter paths for indirect shell invocation Test Python and Node.js argument handling for OS-level command spawning, including parameter-driven behaviours that bypass character-based filters.

Key takeaways

• MCP stdio validation can fail even when developers follow recommended sanitisation practices, because downstream runtimes may still invoke operating-system commands.
• The exposure is not limited to code execution, since unauthenticated AI services can also surface secrets, environment variables, and lateral movement paths.
• Isolation, authentication, and command disablement are the controls that change the risk equation for execution-capable AI integrations.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Execution boundary drift: A governance failure where a system designed to pass data gradually acquires the ability to execute actions. For AI services, this means the interface that looked like an integration point starts behaving like a privileged runtime, expanding blast radius without a corresponding access model.
• Sandbox: A sandbox is a controlled execution environment that isolates an agent's runtime from the rest of the estate while still allowing defined actions and tool use. For identity teams, the sandbox is part of the trust boundary because it carries the agent's access, state, and audit trail.

What's in the full article

OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• The specific MCP stdio input patterns that still reach command execution despite sanitisation
• The practical sandboxing and authentication measures discussed for reducing server takeover risk
• The deployment conditions under which stdio should be disabled rather than constrained
• The original research context around MCP supply chain vulnerability and tested AI systems

👉 OXSecurity's full post covers the bypass path, isolation guidance, and authentication recommendations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.