MCP security gaps expose AI agents to uncontrolled tool access

At a glance

What this is: MCP creates a common way for AI agents to call tools, but its core security model leaves authorization, identity enforcement, and context-aware policy outside the spec.

Why it matters: That matters because IAM, NHI, and emerging agentic AI programmes cannot treat protocol adoption as a security boundary when tool access is still being granted on token possession alone.

By the numbers:

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

👉 Read Pomerium's analysis of MCP security gaps and Zero Trust enforcement

Context

Managed Context Protocol, or MCP, gives AI agents a standard way to discover and call tools, but it does not define how access is authorised in a production environment. That leaves identity, policy, and context enforcement to whatever sits behind the protocol, which is exactly where many teams are weakest.

For IAM and NHI programmes, the gap is not abstract. If tool access is accepted on the strength of a bearer token or a reference server, the organisation has extended execution capability without extending governance. That is a protocol convenience problem until the first agent or attacker uses it as an access path.

Key questions

Q: What breaks when MCP tools rely on bearer tokens alone?

A: Bearer tokens prove possession, not purpose. When MCP tool servers accept them without validating user identity, session context, and scope, any holder of the token can reach internal tools with the same trust level as the intended caller. That creates a replayable access path, weak auditability, and a much larger blast radius than most teams expect.

Q: Why do MCP deployments complicate NHI governance?

A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path. For NHI governance, that matters because tokens, service accounts, and tool permissions are often managed separately, yet they now combine at runtime. If the request is not bound to identity and context, least privilege is only nominal.

Q: How do security teams know if MCP access is actually being governed?

A: Look for evidence that every tool request is evaluated against policy, not just accepted at the endpoint. Useful signals include session-bound authorisation, scoped credentials, deny-by-default behaviour, and logs that show who initiated the action. If a reference server can be reached with a token alone, governance is not in place.

Q: Who is accountable when an MCP-integrated tool exposes internal data?

A: Accountability sits with the team that owns the access boundary, not with the protocol itself. If an MCP tool exposes internal data, the responsible group is the one that decided to trust token possession instead of enforcing identity, session context, and policy. That makes IAM, platform, and application owners jointly accountable for the control failure.

Technical breakdown

Why MCP tool calls become open endpoints without downstream authorization

MCP standardises request and response patterns for tool use, but it does not require the receiving service to apply fine-grained authorization. In practice, that means the tool endpoint becomes the enforcement point, and many reference servers are built for interoperability rather than production security. If the downstream application only checks that a token exists, not who the requester is, what session it belongs to, or whether the action is appropriate, the protocol has effectively widened access without defining control boundaries. The risk is not MCP itself as a protocol. The risk is treating interoperability as if it were policy.

Practical implication: place a policy enforcement layer in front of MCP tools, not inside the assumption that the tool service will secure itself.

Bearer tokens and reference servers create identity ambiguity

The article describes deployments where agents pass OAuth tokens directly to tool servers and are accepted without challenge. Bearer tokens prove possession, not intent, and they become especially weak when they are long-lived, broadly scoped, or detached from the initiating user and session. Reference servers often omit deny-by-default posture, audit logging, and session validation, which makes them convenient for demos but unsafe for privileged or internal workflows. Once that pattern enters production, the organisation loses visibility into who authorised the action and under what context it occurred.

Practical implication: bind tokens to session, audience, and user context before allowing MCP traffic to reach internal systems.

Zero Trust for MCP requires request-level policy at Layer 7

The security control Pomerium describes is not a new protocol layer. It is a reverse proxy that evaluates every incoming request against identity and policy before the tool server sees it. That architecture matters because it restores a basic control principle MCP omits: every call should be explicit, contextual, and auditable. This is a classic Zero Trust pattern applied to agentic workflows. The request is not trusted because it came from an agent, a browser, or a token holder. It is trusted only if policy says so, in that moment, for that identity and environment.

Practical implication: move access decisions to the edge of the tool plane so the enforcement point is consistent across all MCP-integrated services.

Threat narrative

Attacker objective: The objective is to use protocol-enabled tool access to reach internal systems and data without triggering meaningful identity or authorization controls.

1. Entry occurs when an agent or attacker reaches an MCP-compatible tool endpoint with a bearer token or similarly weak credential.
2. Escalation happens when the endpoint accepts the token without validating identity, session context, audience, or least-privilege scope.
3. Impact follows when internal APIs, customer data, or administrative tools are exposed through the agent workflow without a meaningful audit trail.

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

MCP normalises connectivity, but it does not normalise security. The protocol solves interoperability between agents and tools, yet it leaves the trust decision to downstream services that are often not designed for agentic use. That means the security burden shifts from the protocol to the enforcement layer, and many teams have not built that layer. Practitioners should treat MCP as an integration format, not an authorization model.

Bearer-token acceptance is an identity failure, not just an implementation shortcut. When a tool server accepts possession of a token as proof of legitimacy, it collapses the distinction between an authorised user, an authorised agent, and an unauthorised request replay. That is why contextual enforcement matters more here than in ordinary API traffic. The implication is that access governance must move from static credential checks to request-bound identity verification.

Context-aware policy is the missing control plane for agentic access. MCP-based workflows often span internal APIs, support data, and operational systems, so binary allow or deny decisions are too crude to govern them safely. Pomerium's framing is directionally correct because it restores policy at the request edge, but the broader lesson is architectural: access to tools must be evaluated in the context of identity, group, and session state. Practitioners should design MCP governance as a policy problem, not a transport problem.

Tool exposure without least privilege creates identity blast radius. Once a reference server exposes a tool broadly, every connected agent inherits the same execution surface unless policy constrains it. That expands the blast radius of a single credential or misconfiguration across multiple workflows. The governance conclusion is straightforward: teams need narrower tool scopes, stronger session binding, and a clear distinction between demo connectivity and production entitlement.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how often MCP exposure is still left binary rather than governed.
• For a broader lens on agent risk, see AI Agents: The New Attack Surface report, where 80% of organisations reported agents acting beyond intended scope.

What this signals

Identity-blast-radius: MCP adoption turns tool access into a governance problem, because each exposed endpoint can expand the practical reach of a single credential across multiple workflows. With 53% of MCP servers exposing credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025, the operational issue is not theoretical. Teams should assume that integration convenience will outpace policy unless access is enforced at the request edge.

The reader-level signal is clear: MCP should be treated as an access distribution layer, not a control layer. If your programme cannot tie a tool call back to an identity, a session, and a policy decision, then your audit trail is incomplete before the first incident begins.

As agentic AI expands, the strongest control pattern is converging with Zero Trust principles already used in human and NHI governance. That makes NIST Cybersecurity Framework 2.0 and request-level policy enforcement relevant for the same reason: the request must be verified before the tool can be trusted.

For practitioners

• Insert a request-enforcement layer in front of every MCP tool Route agent traffic through a proxy or gateway that evaluates identity, group membership, and session context before the tool endpoint is reached. The control should deny by default and log every decision for audit and incident review.
• Remove long-lived bearer tokens from MCP pathways Replace broad bearer tokens with scoped, audience-bound credentials that expire quickly and are tied to the initiating identity. Do not let reference servers accept tokens that can be replayed outside the original context.
• Scope tool permissions to the smallest usable function Break MCP exposure into narrow tool sets so an agent can only invoke the actions it genuinely needs. Avoid exposing full internal APIs when a single read-only or task-specific capability will do.
• Require full logging for every agent-to-tool decision Capture who initiated the request, what tool was called, what policy allowed it, and which session context was used. Without that record, MCP access cannot be reviewed or investigated credibly.
• Separate demo servers from production controls Treat reference servers as development scaffolding, not production enforcement. Before any internal system is connected, validate deny-by-default behaviour, audience checks, and context-aware authorisation.

Key takeaways

• MCP improves interoperability for AI agents, but its security model leaves authorization and context enforcement to downstream systems that are often too weak for production use.
• Reference servers and bearer-token flows widen identity blast radius by turning possession into access, which is inadequate for internal tool governance.
• Teams should treat MCP as a transport format and enforce Zero Trust policy at the request edge before tool access reaches sensitive systems.

Key terms

• Managed Context Protocol (MCP): A standard interface that lets AI agents discover and call tools in a common format. In security terms, it is an integration protocol, not an authorization system, so access decisions still need to be enforced by the service or an external policy layer.
• Bearer token: A credential that grants access to whoever possesses it, regardless of who originally obtained it. In MCP-style workflows, bearer tokens are especially risky when they are long-lived, broadly scoped, or detached from the initiating user and session context.
• Request-level policy enforcement: A control pattern that evaluates each access request at the moment it is made, using identity, context, and policy before allowing execution. For agentic and NHI workflows, this is the practical boundary that prevents token possession from becoming unchecked tool access.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pomerium: Why the Managed Context Protocol (MCP) spec still leaves gaping security holes. Read the original.