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

Why This Matters for Security Teams

Sanitising MCP inputs can reduce obvious injection strings, but it does not remove the execution path once a tool call reaches a runtime that can interpret arguments, spawn subprocesses, or invoke shell wrappers. That matters because MCP sits at the boundary between model intent and real system action. Once an approved request is passed downstream, the security question shifts from “was the input filtered?” to “what can the interpreter do with it?”

This is why command execution risk remains even when the front door looks clean. The same tool may be safe for one argument shape and unsafe for another, especially when libraries concatenate strings, call NIST Cybersecurity Framework 2.0 tells teams to manage risks across the full lifecycle, not just at the perimeter of a request. NHI-focused guidance from Top 10 NHI Issues also highlights that exposed automation paths often matter more than the original payload.

In practice, many security teams encounter command execution only after a benign-looking tool argument has already reached a shell, interpreter, or plugin chain rather than through intentional secure code review.

How It Works in Practice

The technical failure usually happens in the gap between validated input and unsafe downstream handling. A filter may strip semicolons, quotes, or obvious shell metacharacters, but the application can still pass the argument into Python, Node.js, Java, or a platform library that later constructs a command line, evaluates a template, or resolves a path in a dangerous way. Sanitisation is therefore only one control, not a guarantee.

For MCP toolchains, the safer pattern is to treat each tool as a privileged workload with tightly scoped behaviour. That means validating not only the string format but also the allowed action, destination, file path, command template, and runtime context. Current guidance suggests using allowlists, argument binding, non-shell execution APIs, and explicit per-tool policy rather than broad text filtering. The OWASP Top 10 for Agentic Applications 2026 is especially relevant here because agentic and MCP-driven workflows often cross from prompt handling into real execution.

• Bind arguments as structured parameters instead of concatenating command strings.
• Use non-shell execution paths wherever the runtime supports them.
• Limit each tool to a narrow command set and a fixed filesystem or network scope.
• Log the final interpreted command, not just the incoming request.
• Apply runtime policy checks before execution, not only at the API gateway.

NHIMG research on The State of MCP Server Security 2025 shows how immature tool permission scoping remains in real deployments, which is exactly where sanitisation-only strategies fail. These controls tend to break down when the approved argument reaches a helper library that silently shells out, because the dangerous behaviour happens after the filter has already finished.

Common Variations and Edge Cases

Tighter command controls often increase implementation overhead, requiring organisations to balance operational convenience against reduced execution flexibility. That tradeoff becomes visible in MCP servers that support plugins, dynamic tools, or user-supplied file paths, where strict allowlists can break legitimate workflows.

There is no universal standard for this yet, but current guidance suggests treating the riskiest cases as high-assurance execution paths. Examples include tools that call compilers, archive utilities, image processors, package managers, or remote automation frameworks. Even if input is sanitised, command execution risk can persist when the runtime expands variables, invokes a shell by default, or passes through a wrapper that reinterprets the input. The 52 NHI Breaches Analysis is a useful reminder that exposed identities and automation paths are frequently chained together in real incidents.

Teams should also be cautious with “safe mode” claims from libraries. Some frameworks sanitise obvious metacharacters but still allow path traversal, environment-variable injection, or command substitution through secondary features. The safest response is to combine input validation with least-privilege execution, per-tool authorization, and continuous review of every code path that can reach a shell. In environments where plugins can load arbitrary community code or where tool arguments are forwarded through multiple services, those controls often degrade fastest because no single layer owns the full execution chain.

Related resources from NHI Mgmt Group

• Why do MFA deployments still leave organisations exposed to identity risk?
• Why do network security tools still leave organisations exposed to access risk?
• Why do strong IAM controls still leave organisations exposed to audit and fraud risk?
• Why can SSO still leave organisations exposed to credential risk?