MCP security gaps expose AI agents to uncontrolled tool access

At a glance

What this is: Pomerium argues that MCP makes agent-to-tool integration easier but leaves core security decisions outside the spec, creating uncontrolled access paths when teams rely on reference servers and bearer tokens.

Why it matters: IAM and platform teams need to treat MCP as an access pattern, not a security control, because agent-driven tool use needs identity, session, and policy enforcement before internal APIs are exposed.

Context

Managed Context Protocol, or MCP, is the shared interface layer that lets AI agents call tools and move data between systems. The security gap is that the protocol standardises how requests are made, but not who is allowed to make them, under what context, or with what policy boundary.

For identity programmes, that leaves a familiar problem in a new form: a transport standard can make agent integration easier while leaving authorization and session accountability unresolved. In practice, that means internal tools can become reachable through reference servers and bearer tokens before any real governance layer is in place.

The article is a clear example of why agentic access needs policy at the enforcement point rather than trust in the protocol layer. The article's starting position is typical for early MCP deployments, not an outlier.

Key questions

Q: What breaks when MCP tools are exposed without policy controls?

A: Without policy controls, MCP tools become a discoverable privilege surface rather than a governed capability set. An agent may see sensitive tools it should never use, and downstream services may have no reliable way to distinguish approved use from overreach. That makes least privilege impossible to enforce consistently and undermines auditability.

Q: Why do bearer tokens create risk in MCP if they are reused across systems?

A: Bearer tokens become risky when they are portable across trust boundaries. In MCP, a token issued for the server should not be passed through to GitHub, a database, or another upstream API. Reuse collapses delegation boundaries and makes one session token operate like universal authority.

Q: How can organisations tell whether MCP access is actually being governed?

A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

Q: Should organisations route agent traffic through a policy layer?

A: Yes. Agent traffic needs the same kind of contextual enforcement that protects other sensitive access paths, especially when internal tools can reach customer data or administrative APIs. A policy layer gives the team a decision point that MCP itself does not provide.

Technical breakdown

Why MCP tool calls become a security boundary

MCP defines a common way for an agent to invoke tools, but the protocol itself is not an authorization system. That distinction matters because the moment a tool is reachable through MCP, the receiving service becomes the real control point. If the service does not enforce identity, scope, and session context, the agent is effectively operating against an open API surface with a friendlier wrapper. The risk is not the protocol format itself. The risk is that teams mistake interoperability for governance and assume the MCP layer has already enforced access decisions.

Practical implication: place explicit authorization in front of every MCP-exposed tool, not in the agent or prompt layer.

Bearer tokens and reference servers create weak trust chains

The article highlights a common deployment pattern: reference servers and bearer tokens used as a fast start for MCP pilots. Bearer tokens prove possession, not intent, and they do not by themselves bind a request to a user, session, or role. Reference servers are useful for experimentation, but they often lack deny-by-default handling, audit logging, and token scoping. That creates a trust chain where an agent can present valid credentials and still bypass the contextual checks needed for safe production use.

Practical implication: treat bearer-token acceptance without scoping as a production blocker for any MCP deployment.

Why binary exposure is the wrong control model for agents

The article's strongest technical point is that MCP access is often treated as binary. A tool is either exposed or not, which is too coarse for agentic workflows that need limited, traceable, and context-aware access. In practice, the control model needs to consider identity, group membership, environment, and session context at request time. Without that layer, the system cannot distinguish a legitimate support action from an unsafe cross-context tool call, even when both arrive with valid credentials.

Practical implication: design MCP policies around request context and role boundaries rather than a simple allow or deny list.

Threat narrative

Attacker objective: The objective is to use a valid-looking MCP request path to reach internal tools and data without the governance checks that should restrict access.

1. Entry occurs when an AI agent reaches an MCP-compatible tool server through a reference deployment that trusts bearer-token presentation.
2. Credential access is effectively granted when the token is accepted without scoping, expiration, or audience validation.
3. Impact follows when the agent can invoke internal tools and APIs without the user, session, or role context being verified.

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.

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 has exposed a governance gap, not just a protocol gap: the problem is not that AI agents need a shared tool interface, but that the interface is being deployed without an equivalent identity and policy boundary. Once internal tools are reachable through MCP, the burden shifts from the protocol to the enforcement layer. Practitioners should treat MCP as the start of the access design, not the end of it.

Bearer-token access is the wrong trust primitive for agentic workflows: tokens prove possession, but agentic tool use needs proof of the initiating subject, the session, and the context. A request can be technically valid and still be operationally unsafe if it is detached from the user, group, or environment that should govern it. This is where binary authorization collapses into overexposure.

Reference servers are training wheels, not production controls: the article correctly separates early experimentation from secure deployment, and that separation should be formal in policy. Teams that promote reference servers into production without adding deny-by-default policy, logging, and session validation are importing an insecure operating assumption. The implication is that MCP governance must move from developer convenience to enforceable access design.

Context-aware policy is the missing control plane for agentic access: the article shows that role, group membership, and session state are the variables that determine whether a tool request is appropriate. That is the right frame for AI agent access governance because it preserves least privilege while making the access decision explainable. Practitioners should build agent access rules around request context, not only around token validity.

Open MCP exposure creates identity blast radius: once a tool server accepts generic agent traffic, the blast radius is no longer limited to the agent itself. It extends to every internal API the server can reach, which is why tool exposure, auditability, and request provenance must be governed together. IAM and platform teams should assume that any unmanaged MCP endpoint is already part of the privileged access surface.

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 Security Guide

What this signals

Identity-aware enforcement is the missing control plane for MCP: the protocol will continue to accelerate agent integration, but it will also keep expanding exposure unless policy is enforced at the request boundary. Teams that treat agent traffic as just another API pattern will miss the fact that access must be evaluated with user, session, and environment context in real time.

Uncontrolled agent access widens the identity blast radius: once an MCP endpoint can reach internal tools, the trust problem is no longer local to the agent. It propagates into the systems behind the tool, which is why network reachability and authorization are no longer separable concerns in agentic environments.

For practitioners

• Define MCP enforcement points Place policy enforcement in front of every MCP-compatible tool so the request is evaluated before the tool executes, not after the token is accepted.
• Bind access to user context Require the initiating user, group membership, and session context to be checked on each tool call instead of trusting bearer-token possession alone.
• Replace reference-server assumptions Treat reference servers as development scaffolding only, and move any production traffic behind deny-by-default controls with full request logging.
• Scope tokens for agent use Limit bearer tokens by audience, expiration, and approved tool set so a captured token cannot be reused across unrelated MCP requests.
• Review internal APIs exposed through MCP Inventory every internal service that can be reached through an MCP path and classify the access as part of the privileged application surface.

Key takeaways

• MCP makes it easier for AI agents to reach internal tools, but the security decision still has to be enforced by the receiving service, not assumed from the protocol.
• Bearer tokens and reference servers create a weak trust model when they are not scoped to identity, session, and context.
• The practical control shift is from binary exposure to request-level governance that can trace, validate, and limit agent tool use.

Key terms

• Managed Context Protocol: Managed Context Protocol, or MCP, is the shared request format that lets AI agents invoke tools and move data between systems. In security terms, it is an interoperability layer, not an authorization layer, so it still needs identity, policy, and session controls around it.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Reference Server: A reference server is a sample or starter implementation intended to show how a protocol works. It is useful for development, but it is not automatically safe for production because it may omit authentication, logging, and deny-by-default controls.

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.