TL;DR: Unsafe MCP server configurations can let user-controlled values reach shell commands, and the resulting risk is not that every tool call becomes code execution but that agent-accessible servers can collapse into an uncontrolled privilege boundary, according to HikmaAI. Governance has to treat tool exposure, validation, and execution identity as one control surface, not separate checks.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on HikmaAI's blog post: Unsafe MCP server configurations can turn agent tool access into shell command execution if validation and execution identity are not governed together.
Why it matters: IAM, PAM, and NHI teams need to treat MCP servers as active privilege boundaries, because tool exposure, server identity, and log evidence now shape the real blast radius.
Context
MCP lets an AI agent request a tool call and have the server execute it, so the security question is no longer just whether a tool exists but what that tool can do, what inputs it accepts, and under which identity it runs. That makes MCP security a governance problem, not a narrow application issue.
HikmaAI's analysis separates protocol behaviour from application failures: the protocol does not turn every tool call into code execution, but unsafe server wiring can. That distinction matters because the real control boundary sits around tool exposure, argument validation, and the server's execution context.
The governance challenge is typical for early MCP deployments: teams often approve connectivity before they have a defensible model for permissions, logging, and host-level blast radius.
Key questions
Q: How do MCP servers become a privilege boundary for agents?
A: MCP servers become a privilege boundary when the agent can trigger actions that the server executes under its own runtime identity. The risk is not only tool exposure but also the permissions attached to the server, the inputs it accepts, and the host resources it can reach. Governance has to treat the server as an active execution layer, not a passive transport channel.
Q: How should teams validate MCP server arguments safely?
A: Validate MCP server arguments against a strict allowlist, parse them as structured fields rather than free text, and reject unexpected flags, paths, or environment overrides. Treat startup commands as sensitive input because a malicious argument can redirect tools, expose secrets, or change the server's runtime scope without changing the code.
Q: What is the difference between an MCP tool and a shell command?
A: An MCP tool is a structured capability exposed through the protocol, with defined inputs, outputs, and policy boundaries. A shell command is an operating system instruction executed by a command interpreter, usually with direct file, process, and environment access, so it has a much broader execution surface and less inherent structure.
Q: Who is exposed when MCP server logs are too thin?
A: Thin MCP server logs expose the operator, the owning team, and the human accountable for the agent or service account because you cannot reconstruct who invoked a tool, which permission applied, or what data was touched. Without that evidence, access reviews, incident response, and revocation decisions become guesswork.
Technical breakdown
How MCP tool calls become a security boundary
MCP is a client-server protocol for exposing tools to agents. The agent asks for a tool call, the server receives arguments, and the server performs the action. That creates a new control boundary because the trust decision is not only about authentication to the server. It is also about which tools are exposed, what each tool can return, and whether the server is allowed to translate user-controlled inputs into system commands. In practice, the server's schema, argument handling, and runtime permissions determine whether the integration behaves like a constrained interface or a delegated execution path. See the MCP Security Guide.
Practical implication: Inventory every exposed tool before enabling agent access, and classify each one by the action it can actually perform.
Why unsafe STDIO server configuration creates code execution risk
STDIO-based MCP servers are started with local configuration, often by passing commands, arguments, and environment values into a launch path. If those values are not validated correctly, a shell command can inherit attacker-controlled content and execute with the server's privileges. Command allowlists do not help if the application composes a shell string unsafely or treats configuration as trusted input. The failure mode is not the protocol itself. It is the application layer that turns a server startup path into a command runner without sufficiently constraining parsing, interpolation, or execution context. See the AI Agent Sandboxing and Code Execution Guide.
Practical implication: Review launch-time configuration handling as code execution surface, not just as deployment plumbing.
How execution identity defines the blast radius of an MCP server
The identity the server runs as determines how far a successful tool call can reach. A server running with broad local privileges can touch files, databases, and process-level resources far beyond the agent's intended scope. That is why the server is not just a tool endpoint; it is a privilege boundary with its own authorization context. When a host treats an MCP server as a convenience layer instead of a governed runtime, the agent inherits the server's local power even when the agent's own role appears limited. See the NHI Authentication Guide.
Practical implication: Bind each MCP server to a narrow runtime identity and separate it from high-value host resources.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP turns the server into the real privilege boundary: Once an agent can trigger tool execution, the server's own permissions define the meaningful attack surface. That means governance cannot stop at agent identity or client authentication; it has to account for what the server can do on the host and beyond. The practitioners who treat MCP servers as execution boundaries will see the risk sooner than those who treat them as passive middleware.
Unsafe configuration is the failure mode, not the protocol: The weakness sits in applications that let user-controlled values reach command execution paths, sometimes even when allowlists exist. That is a classic input-validation failure wrapped around a new protocol surface. Security teams should read this as a reminder that protocol adoption does not remove the need to secure launch paths, parsing, and runtime composition.
Tool inventory is now part of governance evidence: An MCP assessment has to know which tools exist, what each tool returns, and which permissions each tool requires before connection is granted. Without that inventory, reviewers cannot separate a read-only tool from a tool that can modify state or execute commands. The result is an authorization model that cannot be defended in audit or incident review.
Auditability depends on linking tool action to control outcome: Event logs that merely capture prompts or transcripts miss the governance question that matters: what permission applied, what the server did, and what outcome resulted. Structured records create traceability across the agent, the tool, and the control decision. Teams that cannot reconstruct that chain will struggle to prove whether an agent path stayed within its approved scope.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Gateway and MCP Server Governance Guide
What this signals
Execution identity will become the decisive MCP control: As more agents call tools through MCP, the server's runtime identity will matter more than the agent label attached to the request. Governance that cannot separate a harmless lookup from a privileged command path will keep misjudging blast radius. That pushes teams toward identity-aware tool brokerage rather than generic integration approval.
Command safety and protocol safety are not the same problem: The protocol can be sound while a deployment still lets attacker-controlled values reach a shell. That distinction should shape how teams review AI-enabled integrations, because the failure may sit in startup composition, not in the protocol exchange itself. A control model that ignores launch-time input handling will miss the easiest compromise path.
Tool sprawl creates hidden secret exposure: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. As MCP paths multiply, secret handling and execution identity need to be governed together rather than as separate operational queues.
For practitioners
- Map every exposed MCP tool Create a pre-connection inventory of tools, schemas, return values, and required permissions so reviewers can distinguish read-only actions from state-changing ones.
- Treat startup arguments as executable input Review STDIO launch commands, environment values, and configuration interpolation for shell injection risk before any server is allowed to run.
- Constrain the server runtime identity Run each MCP server with the narrowest feasible privileges and isolate it from high-value local resources, especially production data stores.
- Build structured action logs Record actor, source, action, permission, and result in a machine-readable format so tool calls can be reconstructed without storing unnecessary sensitive content.
Key takeaways
- MCP changes the control question from whether an agent can call a tool to what that tool can do under the server's own privileges.
- Unsafe server configuration can convert ordinary input handling failures into command execution, even when the protocol itself is not the root cause.
- Structured logs, narrow runtime identity, and a pre-connection tool inventory are the controls that make MCP use defensible.
Related NHI Mgmt Group resources: MCP Security Guide · MCP Gateway and MCP Server Governance Guide · NHI Authentication Guide · AI Agent Sandboxing and Code Execution Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP servers depend on how the agent and server authenticate before tool calls are accepted. |
| NHI-06 — Insecure Cloud Deployment Configurations | Unsafe MCP STDIO startup and runtime settings create the command-execution condition described here. | |
| NHI-10 — Human Use of NHI | MCP tool control depends on humans approving and governing machine identities before agents use them. | |
| Recommendation — Validate MCP server authentication paths and reject unauthenticated or weakly bound access. Review MCP deployment and launch settings for unsafe defaults, shell interpolation, and overbroad runtime access. Require human-reviewed governance for each MCP server before agent access is enabled. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP agents can misuse exposed tools or trigger unintended commands through unsafe server behavior. |
| Recommendation — Restrict tool scopes and monitor for agent actions that exceed intended tool use. | ||
| MITRE ATT&CK | TA0002; TA0006 — Execution; Credential Access | The article centres on command execution paths and the potential exposure of secrets through those paths. |
| Recommendation — Map MCP server compromise paths to execution and credential-access detections in your pipeline. | ||
Key terms
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- 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.
- STDIO Servers: STDIO Servers are services that communicate through standard input and standard output rather than a network socket. In practice, they are often local helper processes or protocol endpoints, so the calling application controls the process boundary and the exchanged messages.
- Command injection: Command injection occurs when attacker-controlled data is inserted into a shell command and changes what the process executes. In AI tooling, that often happens through wrappers, plugins, or installation flows that turn paths or prompts into shell strings. The impact is privilege abuse through the process’s inherited authority.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org