MCP server security risks are exposing identity control gaps

At a glance

What this is: MCP server security is about how AI agents inherit broad access through a protocol that lacks native authentication and authorization, creating request-level risk across internal systems.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent access as an identity problem, not just a transport or application problem.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Pomerium's analysis of MCP server security risks in 2026

Context

MCP, or Model Context Protocol, is the standard that lets AI agents call tools and data sources through a single interface. The governance gap is that the protocol itself does not supply native authentication or authorization, so every deployment inherits the trust decisions placed around it, not inside it.

That makes MCP a direct IAM and NHI problem, because the server acts with whatever authority it has been granted and agent requests are evaluated only if teams add external controls. For security teams, the question is whether identity-aware policy can keep pace with agent-driven access before broad permissions become the default operating model.

Key questions

Q: How should security teams control MCP server access in production?

A: Security teams should enforce identity-aware policy on every MCP tool call, not just at session start. That means scoping server permissions to the minimum needed for the task, verifying requester context before execution, and logging each decision so access can be reviewed and revoked with precision.

Q: Why do MCP servers create more risk than ordinary API integrations?

A: MCP servers can expose broad internal authority to AI agents without native authentication or authorization in the protocol. That turns a single request path into a high-trust execution channel, so the risk is not only data access but unauthorized action under a legitimate server identity.

Q: What do teams get wrong about prompt injection in MCP environments?

A: Teams often treat prompt injection as a content problem when it is also an identity problem. If the server will act on manipulated instructions without verifying who initiated the request and what authority it should have, the injection becomes a path to real execution, not just model confusion.

Q: How do Zero Trust controls apply to MCP server security?

A: Zero Trust applies by forcing each tool call through policy, context, and revocation rather than trusting an established session. For MCP, that means per-request authorization, isolated execution, and continuous auditability so a compromised agent or server cannot keep acting unchecked.

Technical breakdown

MCP request flow and where authorization disappears

MCP sits between an AI host, a protocol client, and one or more servers that expose tools, resources, or prompts. The important detail is that the protocol standardises discovery and invocation, but not trust decisions. Without an external control point, the server accepts tool requests using the authority already attached to it, which means the access model is inherited from deployment rather than enforced by protocol. That is why a simple integration can become an identity boundary with no embedded policy layer.

Practical implication: place per-request authorization in front of every MCP server call, not just at initial session start.

Prompt injection, tool poisoning, and confused deputy failures

MCP expands the attack surface because the model can be influenced by data, tool descriptions, or task context. Prompt injection manipulates the agent through retrieved content, tool poisoning alters the metadata the agent trusts, and the confused deputy problem appears when a legitimate server performs actions for an unverified requester. These are different failure modes, but they converge on the same outcome: the agent or server acts on input that was never identity-checked at the point of execution.

Practical implication: validate both tool metadata and request context before allowing an action to proceed.

Standing privilege in MCP server deployments

When an MCP server can reach file systems, APIs, or databases broadly, it becomes a standing-privilege identity even if the session is brief. That matters because the server maintains access whether or not the task still needs it, and compromise of one request can expose a much larger blast radius than the original action justified. In identity terms, the dangerous part is not just exposure, but persistent authority attached to an ephemeral workflow.

Practical implication: scope each server to task-bound permissions and isolate it from systems it does not actively need.

Threat narrative

Attacker objective: The attacker wants to turn a trusted MCP server into an execution proxy for data theft, command execution, or lateral movement inside internal systems.

1. Entry occurs when a poisoned prompt, malicious tool definition, or exposed MCP endpoint reaches a server that trusts requests without verifying the requester.
2. Credential access or abuse happens when the server uses its own broad permissions to query data, run commands, or invoke internal APIs on behalf of the attacker.
3. Impact follows when the attacker exfiltrates data, triggers unauthorized actions, or moves laterally through the privileged systems the server can reach.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Policy gaps, not protocol novelty, are the real MCP risk. MCP does not create a new identity category, it exposes an old one in a more dynamic form. The protocol gives agents a route to tools, but the security failure appears when teams assume the route itself implies authorisation. Practitioners should treat MCP as a governance boundary that must be mediated by identity-aware policy, not by transport assumptions.

Standing privilege in MCP is a familiar NHI failure mode wearing an AI label. The same pattern that drives service account abuse now appears in server-to-tool workflows: access persists longer than the task that justified it. That means compromise of a single MCP server can inherit broad reach into databases, APIs, and file systems. The practical conclusion is that privilege scope, not model capability, determines the blast radius.

Confused deputy becomes more dangerous when the requester is an agent. Human request patterns at least offer contextual clues and predictable cadence, but MCP requests can be generated continuously and adaptively once the agent is in motion. That makes weak requester verification a structural control gap, especially when the server can act on behalf of the agent without confirming who or what initiated the call. Teams need to treat request provenance as part of the access decision, not an audit afterthought.

Identity blast radius is the right named concept for MCP governance. The central question is how far a single agent request can travel once it reaches a server with broad authority. That blast radius is determined by permissions, isolation, logging, and revocation speed, not by whether the deployment is local or remote. Practitioners should reframe MCP risk around how much damage one approved action can cascade into.

MCP security now sits at the intersection of NHI governance and agentic access control. The governance model must cover workload identity, tool-scoped privilege, and per-request policy in one control plane. That is exactly where NHI programmes and emerging agentic controls converge, and why treating MCP as just another application integration will leave material gaps. Teams should align MCP oversight with both NHI controls and Zero Trust enforcement.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• That same research shows 97% of NHIs carry excessive privileges, which is why broad MCP server authority is a governance problem, not just an application hardening issue.
• Read OWASP Agentic Applications Top 10 for the adjacent agent-side threat model that often intersects with MCP deployments.

What this signals

Identity blast radius: MCP will force more programmes to measure how far a single tool call can reach before policy or revocation interrupts it. The organisations most exposed will be the ones that still treat server permissions as static setup work rather than an ongoing access decision. With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the gap is already visible in adjacent machine identity programmes.

MCP also pushes NHI teams toward a more unified governance model for humans, services, and agents because the same access layer now has to answer who acted, what they could reach, and whether the action was authorised. That is where NIST Cybersecurity Framework 2.0 becomes practical: govern and protect need to meet policy enforcement at request time, not after the fact.

For practitioners

• Enforce per-request authorization on every tool call Evaluate each MCP request against identity, task, source, and environment before the server acts. Do not rely on a one-time login or implicit trust in the client session.
• Scope every MCP server to task-bound privilege Limit access to only the files, APIs, and databases the server needs for the current workflow. Remove broad read and write access that persists after the job is complete.
• Isolate servers from public network exposure Bind MCP services to local sockets or private networks and avoid 0.0.0.0 bindings. This reduces the chance that a neighbour network or shared environment can reach a trusted server.
• Verify tool definitions and upstream dependencies before approval Review server source, package lineage, and tool metadata before onboarding anything into production. Supply chain trust should be explicit, not inferred from the server name or repository popularity.
• Log tool input, output, and policy decisions together Capture request context, returned data, and the policy verdict in the same record so investigators can reconstruct what happened and whether the action was authorised.

Key takeaways

• MCP security is an identity governance problem because the protocol moves trust from built-in controls to external policy.
• Broad server permissions create a standing-privilege blast radius that can turn one agent request into internal system compromise.
• Per-request authorization, isolation, and full-context logging are the controls that separate manageable deployments from exposed ones.

Key terms

• Model Context Protocol: Model Context Protocol is an open standard that lets AI applications discover and invoke external tools and data sources through a shared interface. In security terms, it moves the trust boundary to the server layer, where identity, permission scope, and request provenance must be enforced externally.
• Confused Deputy: A confused deputy is a system that uses its legitimate authority on behalf of an attacker without realising it. In MCP environments, the danger appears when a server acts on a request without verifying the requester, allowing abuse of valid permissions rather than a direct credential theft.
• Identity Blast Radius: Identity blast radius is the amount of damage a single identity can cause if it is misused, compromised, or over-permissioned. For MCP servers, it reflects how far one approved tool call can reach across APIs, file systems, and databases before policy or revocation stops it.
• Per-Request Authorization: Per-request authorization means checking each action individually against identity, context, and policy instead of trusting a session once it starts. For MCP, this is the difference between a brief authenticated connection and a continuously governed execution path.

Deepen your knowledge

MCP server security risks and identity-aware policy enforcement are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents, services, and shared infrastructure, this is a useful place to start.

This post draws on content published by Pomerium: MCP Server Security Risks: What Development Teams Need to Know in 2026. Read the original.