MCP security risks expose a new identity governance gap

At a glance

What this is: This article argues that MCP creates a distinct security challenge because locally run or remotely exposed servers can execute commands, expose tools, and weaken identity boundaries.

Why it matters: It matters because IAM, PAM, and NHI teams must govern tool-connected workloads and AI-linked access with the same discipline used for other privileged non-human identities.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's analysis of MCP server security risks and controls

Context

Model Context Protocol, or MCP, is a way for AI systems to connect to tools and data sources, but that convenience changes the identity problem. Once a protocol can run locally, call commands, and expose capabilities bidirectionally, traditional application boundaries stop describing the risk accurately.

The article’s core point is that MCP security is really a governance problem for non-human access. The same controls that limit service accounts, secrets, and delegated access now need to cover tool servers, prompt exposure, and execution paths that can be abused by attackers or misused by legitimate integrations.

For practitioners, the starting assumption should be that an MCP server is an identity-bearing component with access consequences, not just an integration layer. That is typical of early-stage protocol adoption, which means security maturity usually lags the pace of deployment.

Key questions

Q: What breaks when MCP servers are not governed like non-human identities?

A: The trust boundary becomes too wide. A server that can execute commands, expose tools, or change behavior after installation can inherit privileges far beyond the task it is supposed to perform. Once that happens, compromise or misuse in one integration can cascade into local system access, sensitive data exposure, or downstream service abuse.

Q: Why do MCP servers create more risk than traditional APIs?

A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls. Traditional APIs usually expose fixed interfaces; MCP adds a broker that can widen the blast radius if credentials or permissions are too broad. The danger is delegation without enough identity governance.

Q: How do security teams know whether an MCP tool is over-privileged?

A: Look for any tool that can access more directories, APIs, secrets, or commands than its immediate task requires. If the tool can reuse environment variables, read broad filesystem paths, or reach multiple systems without a clear business need, its runtime privilege exceeds its intended function.

Q: What should teams do when an MCP server is updated or replaced?

A: Treat the change like an identity lifecycle event. Revalidate the server’s permissions, review tool descriptions and command paths, re-sign or re-approve the component if needed, and confirm that old access paths are removed before the new version is trusted.

Technical breakdown

Why local MCP servers change the trust model

Local MCP servers often run as executables on user machines and communicate through stdio, which means they inherit file, process, and network access that many teams do not treat as part of the application surface. That matters because the security boundary is no longer just the API endpoint. The server becomes a privileged local execution component, and any command it runs may inherit the caller’s permissions. When the same server can also be delivered remotely over HTTP, the trust model must account for both local compromise and remote abuse.

Practical implication: Treat each MCP server as a privileged workload identity and scope its file, process, and network permissions explicitly.

Command injection and tool injection in MCP workflows

Command injection happens when user-controlled input reaches a shell command without sanitisation, allowing an attacker to append malicious metacharacters. In MCP environments, the same pattern can appear in tool definitions, configuration values, or method parameters. Tool injection is a related failure where a model is steered toward a malicious capability because the tool name or description looks legitimate. These are different failure modes, but both exploit trust in the server’s declared behaviour rather than in its actual runtime behaviour.

Practical implication: Validate every user-controlled field that reaches commands or tool metadata, and freeze tool descriptions once approved.

Why bidirectional capability exposure increases abuse potential

MCP is bidirectional, which means clients may expose capabilities such as sampling back to the server. That creates a two-way trust relationship, not a one-way request flow. If the client exposes too much capability, a malicious or compromised server can influence prompts, consume model resources, or extract information through carefully shaped requests. The security issue is not simply that the server is remote. It is that the protocol can turn the client into an execution and inference surface unless permissions are deliberately constrained.

Practical implication: Review every capability the client exposes and apply user approval, rate limits, and context separation where sensitive data is involved.

Threat narrative

Attacker objective: The attacker wants to turn a trusted tool integration into a privileged execution path that exposes data, manipulates model behaviour, or reaches connected systems.

1. Entry begins when an attacker introduces a malicious or backdoored MCP server, or abuses a legitimate server with unsafe command handling or deceptive tool naming.
2. Escalation follows when the server executes commands, influences prompts, or abuses exposed client capabilities such as sampling to extend its reach beyond the intended task.
3. Impact occurs when the attacker gains unauthorized access to local resources, sensitive data, or downstream connected systems through the compromised MCP workflow.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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 server security is an NHI governance problem before it is an AI problem. The protocol creates identity-bearing components that execute with real privileges, so the question is not whether the model is intelligent but whether the connected server is governed like a non-human identity. That means access scoping, secret handling, and command execution controls belong in the same conversation as tool routing and prompt safety. Practitioners should classify MCP servers as governed machine identities, not incidental integrations.

Tool-connected identity collapses the old separation between application and credential risk. When an MCP server can execute commands, expose methods, or receive bidirectional prompts, the trust boundary moves from the API call to the runtime session. The security consequence is a wider identity blast radius, because a single compromised server can influence both data access and model behaviour. Teams should stop treating protocol adoption as a pure engineering decision and re-evaluate it as an access governance decision.

Access scoping is the named concept this category is missing. In the article’s threat model, the core weakness is not just insecure code but the lack of tight permission boundaries around tool execution. Only 18% of MCP deployments implement any form of access scoping, which shows how immature the control plane still is. The implication is simple: if the server can do more than the task requires, the identity model is already too broad.

Static trust assumptions fail when server capabilities can change after installation. A server that appears safe at onboarding can become dangerous through updated method descriptions, altered tool names, or changed command behaviour. That makes lifecycle governance part of the threat surface, not just a procurement concern. Practitioners should treat updates, version pinning, and approval of tool metadata as identity controls, because they shape what the server is allowed to become.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• For the control side of the picture, Top 10 NHI Issues shows why over-privilege and unmanaged lifecycle controls remain the most common failure modes.

What this signals

Tool-connected identity will become a lifecycle problem, not just a deployment problem. As more AI-linked integrations arrive, the real control question will be whether servers, tokens, and tool permissions are still governed after the first release. Teams that do not extend identity review into runtime and update cycles will accumulate access that no one can confidently explain or revoke.

The governance gap is especially visible where protocol convenience outruns entitlement design. MCP-like patterns reward rapid integration, but every extra tool, command, and client capability expands the attack path unless permissions are narrowed and continuously revalidated. Practitioners should prepare for more audit pressure on who approved what, when, and with which effective privileges.

The next maturity step is not simply blocking dangerous tools, but making tool exposure traceable and revocable across the full lifecycle. That means pairing platform governance with identity review, secret hygiene, and monitored runtime behaviour, which is where NHI programmes and AI governance finally converge.

For practitioners

• Classify MCP servers as governed non-human identities Assign each server an owner, permission boundary, and lifecycle state so it is reviewed like any other privileged workload identity.
• Freeze and verify tool metadata before deployment Pin versions, sign approved components, and prevent unreviewed changes to method names, descriptions, and command parameters.
• Separate prompt context from untrusted capability data Keep external tool content out of sensitive prompt context and block servers from injecting untrusted material into the same session as privileged instructions.
• Restrict bidirectional client capabilities by default Review any sampling or reverse-calling features, then require approval and rate limits before a server can consume model resources or shape completions.
• Run MCP components with minimal operating permissions Use sandboxing, network segmentation, and file-system restrictions so a compromised server cannot move from tool misuse to broader system access.

Key takeaways

• MCP security exposes the same governance failures seen in NHI sprawl, but inside an AI integration layer that many teams still treat as harmless plumbing.
• The biggest risk is not one flaw, but the combination of command execution, bidirectional trust, and weak access scoping across server lifecycle changes.
• Practitioners should govern MCP servers as privileged non-human identities, with explicit permissions, reviewable updates, and sandboxed execution boundaries.

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.
• Tool injection: Tool injection occurs when an attacker causes an AI system or intermediary to invoke tools the legitimate user did not intend. In agentic environments this can turn a compromise in the control layer into unauthorized actions in downstream services.
• Bidirectional capability exposure: A condition where both the client and server can initiate meaningful actions, not just exchange requests and responses. In MCP, that can let a server consume model resources or shape prompts, which expands the security boundary beyond a simple API call.
• Session Scoping: Session scoping limits what an identity can do within a specific session, context, or task. For agentic systems, it is the difference between bounded execution and reusable authority, and it should be tied to the exact workflow that triggered the action.

What's in the full article

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

• Code-level examples of command injection and unsafe tool handling in MCP server implementations
• Recommended deployment patterns for sandboxing, signing, and version pinning MCP components
• Operational guidance on prompt sandboxing and capability restriction for bidirectional client flows
• The article's security-first recommendations for enterprise MCP gateway governance

👉 The full Obot article covers command injection examples, bidirectional abuse, and practical mitigation steps for MCP deployments.

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 programme, it is worth exploring.