MCP security is closing fast on the enterprise risk window

At a glance

What this is: This is an Obot analysis of MCP security that argues the protocol’s biggest risk is the gap between rapid experimentation and immature governance, with exposed servers, prompt injection, and overprivileged tool access as the key attack patterns.

Why it matters: It matters because MCP changes how AI systems reach tools and data, so IAM, PAM, and security architecture teams need to govern model-to-tool authorization before those connections become operational defaults.

By the numbers:

• Half of organizations are actively experimenting with MCP servers, but only 11% have reached production, creating a 39-point governance gap.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Obot's analysis of MCP security risks and defence layers

Context

MCP security is now a live governance problem, not a future architecture question. MCP collapses the boundary between instructions and execution by letting AI agents choose tools and actions at runtime, which means access control, authentication, and auditability have to be designed around model behaviour as well as system permissions.

The article argues that the highest risk sits in pre-production deployments, where experimentation often outpaces security review. That creates a direct identity and privilege concern for teams managing secrets, tool authorization, and machine-to-system trust, because the first usable MCP connection can already reach sensitive downstream services.

This is a familiar pattern in early platform adoption: velocity comes first, governance arrives later, and shadow deployments fill the gap. The difference here is that the trusted actor is not a human user but an AI-driven control path that can invoke tools, read context, and trigger actions without traditional manual checkpoints.

Key questions

Q: What breaks when an MCP server is compromised?

A: When an MCP server is compromised, the agent may still trust its response as if it were internal policy or approved guidance. That breaks the assumption that tool use is safe simply because the tool is authenticated. In practice, the agent inherits malicious instructions through a channel that should have been treated as untrusted until verified.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.

Q: How should security teams contain prompt injection in agentic systems?

A: Containment should start with delegated identity, not prompt wording. Give the agent the smallest viable permission set, separate read-only and state-changing tools, and enforce policy at every tool call. If the injection succeeds, the agent should still be unable to reach sensitive systems, move money, deploy code, or exfiltrate data at scale.

Q: Who is accountable when a compromised AI agent misuses delegated access?

A: Accountability usually spans the business owner of the workflow, the team that issued or approved the credential, and the vendor if a third-party integration was involved. The critical governance question is not who logged in, but who allowed the delegation chain to exist and remain valid. That chain must be documented before incidents occur.

Technical breakdown

Why MCP creates a new control plane for AI tool use

Model Context Protocol gives an AI system a standard way to discover tools, pass context, and invoke actions across downstream services. That makes the MCP server more than an API endpoint. It becomes the decision point where model output turns into system action, which is why basic application security testing often misses the real risk. The important boundary is not code execution alone, but the chain of trust between the client, the model, and every tool the server can reach.

Practical implication: treat MCP servers as privileged control planes and require explicit authentication, authorization, and logging before any tool execution.

How prompt injection and metadata poisoning manipulate runtime behaviour

Prompt injection in MCP does not require compromising the model itself. Attackers can place instructions in tool descriptions, parameter fields, retrieved content, or external data that the model later interprets as legitimate context. Because the model processes these inputs at runtime, malicious instructions can ride through trusted channels and alter behaviour without changing application code. This is why MCP security depends on validating inputs and outputs as part of the execution path, not just scanning code repositories.

Practical implication: sanitize tool metadata and returned content before it reaches the model, and inspect runtime context for hidden instructions.

Why overprivileged agents create the confused deputy problem

When an MCP client or agent holds broad permissions but the invocation layer does not re-check intent, the system can act on behalf of an attacker with more authority than intended. That is the confused deputy problem in an AI context: the agent has the technical ability to call privileged tools, but lacks a governance boundary that limits what each request may do. In practice, that turns a small access foothold into an administrative path across databases, SaaS platforms, and internal services.

Practical implication: scope every tool to a task-specific role and enforce policy at the gateway or client layer, not only inside each server.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI tool path into a privileged execution channel that reaches sensitive data, administrative functions, or downstream systems.

1. Entry begins with an exposed or weakly protected MCP server that responds predictably to a connection attempt, making discovery and validation trivial.
2. Escalation occurs when prompt injection, poisoned metadata, or overbroad tool permissions let an attacker influence what the model decides to do next.
3. Impact follows when the agent invokes downstream services with unintended authority, creating unauthorized actions, data exposure, or lateral access across connected systems.

NHI Mgmt Group analysis

MCP security is really identity and authorization governance for AI toolchains. The protocol matters because it gives models the ability to act through tools, not just generate text. That makes the trust boundary about who or what can invoke which action, under what context, and with what audit trail. For IAM and PAM teams, MCP should be treated as a new class of privileged access surface, not a simple integration layer.

Pre-production MCP sprawl is a governance debt problem, not just a deployment phase problem. When half of organisations are experimenting and only a small fraction have production controls, the risk accumulates in unmanaged endpoints, temporary credentials, and ad hoc gateways. That is the point where shadow AI becomes shadow infrastructure, and security teams lose the ability to reconcile authorised intent with actual runtime behaviour. The practical conclusion is that governance must arrive before scale, not after it.

Tool metadata is emerging as a distinct attack surface for agentic systems. The attack surface is not limited to prompts or model weights. It includes descriptions, parameters, retrieved content, and every field the model can interpret as instructions. That creates a specific named concept here: instruction-bearing context, meaning trusted-looking data that can alter execution decisions. Teams should assume any context channel that reaches the model can be weaponised.

Centralised policy enforcement is the only sustainable way to govern MCP at enterprise scale. Distributed server-by-server controls will always lag behind engineering velocity. A gateway or client-layer policy plane gives security teams one place to validate identity, scope tools, log requests, and block unsafe execution. That aligns with the broader direction of zero trust and least privilege, but it applies them to AI-mediated execution rather than human sessions.

The market signal is that AI platforms are becoming access brokers, not just application consumers. Once models can query databases, call APIs, and trigger actions, the control problem shifts from model quality to delegated authority. That should push identity programmes to re-evaluate how machine identities, secrets, and transient permissions are governed across application, cloud, and AI stacks. Practitioners who still separate AI security from access governance are already behind the actual risk model.

What this signals

Instruction-bearing context is the pattern security teams should start naming when they assess agentic systems. Any metadata, retrieved content, or runtime input that can change model behaviour becomes part of the control surface, which means traditional appsec boundaries are no longer enough. Teams that already govern NHI and secrets should extend those controls into model-mediated execution paths, with policy checks anchored to the NIST Cybersecurity Framework 2.0.

This is also where the governance stack needs to converge. MCP is not just another integration protocol, because it creates a new path from identity to action. That makes access scoping, auditability, and secret handling part of AI operations rather than separate disciplines, and it is why the OWASP Non-Human Identity Top 10 remains relevant even when the workload is an AI agent.

Model-to-tool trust will become a recurring design issue as more organisations move from experimentation to production. The practical implication is simple: if a model can call tools, the organisation must be able to prove which identity authorized that call, which policy allowed it, and what downstream systems were reachable. That is the same accountability logic that underpins modern identity governance, now applied to agentic control paths.

For practitioners

• Inventory every MCP endpoint and gateway Build a live register of all MCP servers, clients, and exposed HTTP endpoints, then classify each one by authentication state, tool scope, and downstream reach. Prioritise any endpoint that can initialize without authorization because it functions as an open proxy to connected systems.
• Enforce policy at the gateway layer Move authentication, authorization checks, tool inventory control, and audit logging into a centralized gateway or client-layer control plane. That reduces inconsistent server-by-server implementation and gives security teams a single place to block unsafe tool invocation before it reaches databases, SaaS apps, or internal services.
• Sanitize context before model execution Scan tool metadata, parameter fields, returned files, and retrieved content for hidden instructions before the model consumes them. Treat context as untrusted input even when it arrives through a legitimate tool channel, because the attack often lives in trusted data rather than obvious payloads.
• Scope agent permissions to task-level roles Replace broad agent permissions with minimum-necessary tool access tied to a specific task or workflow. Re-review those scopes regularly so temporary access, stale credentials, and privilege creep do not turn a low-risk integration into a standing execution path.
• Require human approval for high-risk actions Keep sensitive operations such as administrative changes, code execution, and access grants behind explicit human confirmation and isolated runtimes. This adds friction where it matters and limits the damage when a model is manipulated into taking an unsafe action.

Key takeaways

• MCP turns AI tool use into a privileged execution problem, which means access governance has to move upstream from the server to the policy boundary.
• The highest-risk failures are predictable and already visible: exposed endpoints, instruction-bearing context, and overbroad tool permissions.
• Centralized authorization, runtime sanitization, and task-scoped access are the controls that make MCP usable without turning it into shadow infrastructure.

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.
• Instruction-Bearing Context: Instruction-bearing context is any metadata, retrieved content, or runtime input that can change what a model decides to do. It matters because the model may treat that input as trusted, which lets attackers steer execution without altering code or directly compromising the model itself.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Connection-Layer Governance: The controls that sit between an application or AI tool and the enterprise systems it can reach. It combines scope enforcement, centralized visibility, logging, and revocation so that third-party access stays auditable and recoverable.

What's in the full article

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

• Step-by-step MCP gateway design patterns for authentication, authorization, and audit logging
• Practical examples of tool-level scope design for agents that need database, SaaS, and internal service access
• Detailed breakdowns of the six attack vectors with mechanics and defensive checkpoints
• Implementation guidance for centralized governance without slowing developer workflows

👉 The full Obot article covers the six attack paths, governance model, and gateway-led defence approach in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control language needed for agentic AI and machine-to-tool access.