MCP security gaps expose the identity controls agents still lack

At a glance

What this is: This is a roundup of July 2025 MCP and agentic access developments, and its key finding is that rapid ecosystem growth is outpacing basic authentication, access control, and governance.

Why it matters: It matters because IAM teams are now being asked to govern AI-agent access paths, not just human and workload identities, while many MCP deployments still expose unauthenticated interfaces.

By the numbers:

• Researchers from Knostic scanned 1,862 internet-exposed MCP servers and found that none possessed any kind of authentication check.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to SailPoint.

👉 Read Pomerium's July roundup on MCP vulnerabilities, governance, and growth

Context

MCP, or Model Context Protocol, is becoming a common integration layer for agentic AI because it lets models reach tools and data sources through a standard interface. That convenience creates a new identity problem: the protocol expands the number of machines, services, and agents that can ask for access, but many deployments still lack the authentication and authorisation controls that identity teams expect.

July’s roundup is useful because it combines vulnerability reporting, ecosystem growth, and governance signalling in one place. The pattern is familiar to IAM and NHI teams: once access paths become easy to publish and reuse, the control plane has to catch up quickly or exposure becomes the default state.

The article also shows that agentic access is no longer a niche developer topic. Security teams are now being asked to decide how MCP servers, AI agents, and privileged tool access should fit into Zero Trust and lifecycle governance without treating every connector like a trusted internal integration.

Key questions

Q: How should security teams govern MCP servers used by AI agents?

A: Security teams should treat MCP servers as privileged access points, not passive integration layers. That means requiring authentication, explicit authorisation, named ownership, and logging before any tool becomes reachable. The goal is to make every server accountable for the data and actions it can expose, rather than assuming the agent layer will stay within safe bounds.

Q: Why do MCP deployments create new identity governance risks?

A: MCP deployments create new risks because they multiply the number of machine-facing access paths that can be reached by agents, scripts, and developer tools. Once those paths are public or loosely controlled, identity governance has to manage discovery, entitlement, and revocation across a wider surface than traditional application access.

Q: What breaks when MCP servers do not require authentication?

A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.

Q: Who is accountable when an MCP connector exposes sensitive data or actions?

A: Accountability should sit with the team that owns the server, connector, and downstream access policy, not with the protocol itself. Organisations need clear ownership for approval, monitoring, incident response, and revocation. Without that assignment, agentic access grows faster than governance can follow it.

Technical breakdown

MCP servers and the authentication gap

MCP standardises how models discover tools and data, but the protocol itself does not guarantee that every server is safe to expose. When researchers find Internet-facing servers with no authentication or access control, the issue is not the protocol alone but the assumption that exposure can be harmless if the endpoint is discoverable only by “intended” users. In practice, unauthenticated MCP servers turn agent access into public access, which collapses the boundary between internal tooling and externally reachable services. That matters because a model does not need full compromise to create risk. It only needs a reachable tool surface with weak identity enforcement.

Practical implication: treat every MCP server as a privileged access point and require explicit authentication before any tool is reachable.

Remote-code-execution risk in MCP tooling

The reported flaws in mcp-remote and MCP Inspector show that agent tooling can become an execution bridge on the operator’s machine, not just a data bridge to enterprise systems. In that pattern, an attacker does not need to attack the target application first. They can abuse the client or inspector layer, trigger command execution, and then use that foothold to pivot into browser sessions, local credentials, or downstream services. This is why MCP security cannot stop at API authorisation. The tooling chain itself becomes part of the identity attack surface, especially where developer desktops and CI environments trust these tools by default.

Practical implication: put MCP clients, inspectors, and connectors under the same hardening and review process as other high-trust execution tools.

Governance models are catching up after exposure has already spread

The formal governance model for MCP is a sign that the ecosystem is moving from experimentation to control-plane maturity. That shift matters because protocol growth tends to outrun access reviews, ownership mapping, and offboarding discipline. Once dozens of servers, connectors, and agent workflows are in circulation, the central question becomes who can approve access, who can revoke it, and how quickly those decisions propagate. For identity teams, MCP is therefore not just an integration standard. It is a lifecycle problem for machine and agent access at scale.

Practical implication: require named ownership, review cadence, and offboarding for every MCP server and connector before it reaches production.

Threat narrative

Attacker objective: The attacker seeks to turn a trusted agent integration path into a foothold for command execution, data access, and broader environment compromise.

1. Entry occurs through exposed MCP servers or vulnerable MCP tooling that can be reached without meaningful authentication.
2. Credential or command access is then obtained through weakly protected client tooling, insecure connector behaviour, or browser-side exploit paths.
3. Impact follows when attackers use that access to run commands, move laterally, steal data, or expand control across linked systems.

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 is becoming an identity problem before it is a tooling problem. The roundup shows that protocol adoption is outrunning basic enforcement, which means teams are now publishing access surfaces faster than they can govern them. That creates a familiar NHI failure mode: a new class of machine-facing identities is treated as integration plumbing instead of governed access. Practitioners should read MCP growth as a control-plane warning, not a feature story.

Unauthenticated MCP exposure is a governance failure, not a deployment detail. The fact that researchers found 1,862 internet-exposed servers with no authentication shows that many deployments still assume obscurity is a control. That assumption fails the moment agents, scanners, or adversaries can enumerate endpoints directly. The implication is that identity enforcement must move in front of the server, not be left to the consuming application.

Agentic access widens the NHI blast radius because one connector can bridge many downstream systems. A single compromised MCP path can reach tools, data sources, and local execution contexts in one chain. That makes the identity blast radius more important than the number of agents or servers deployed. Practitioners should stop measuring exposure by inventory alone and start measuring how much privileged reach each connector inherits.

Formal governance for MCP will matter only if it changes ownership and revocation behaviour. Naming maintainers and enhancement proposals is not the same as assigning access accountability. Without lifecycle discipline for servers, connectors, and agent permissions, the ecosystem will keep growing faster than offboarding and review processes can absorb. Security teams should treat governance as a revocation and review problem first, and a community process second.

OWASP Agentic Applications Top 10 gives the right framing for this category. MCP risks map cleanly to tool misuse, identity confusion, and supply-chain exposure in agentic systems. That makes the current moment useful for control mapping, because the failure pattern is already visible: access to tools is being granted before the access model is mature. Practitioners should use that lens to align agent governance with Zero Trust expectations.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That makes OWASP Agentic AI Top 10 the right next step for teams building policy around agent tool use and access scope.

What this signals

Identity teams should expect MCP to move from developer convenience into formal access governance. The growth pattern in this roundup suggests that every new connector becomes a reviewable identity boundary, not just a technical integration. That means entitlement catalogues, ownership records, and revocation workflows need to extend to machine-facing protocols as quickly as they do to human-facing apps.

With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, the agentic access problem is arriving inside a much broader exposure pattern. MCP does not create the governance issue from scratch. It concentrates it, because one exposed connector can link external models to sensitive internal systems in a single policy gap.

Enterprises that already struggle with service-account visibility will feel this first. If you cannot track machine identity ownership cleanly today, MCP will widen the gap between what is deployed and what is actually governable.

For practitioners

• Inventory every MCP server and connector Map each server, client, and tool surface to an owner, a data classification, and an approval path before it is exposed to users or agents.
• Enforce authentication in front of every exposed MCP endpoint Do not allow an MCP server to rely on obscurity or network placement. Require explicit identity checks and authorisation before any tool can be invoked.
• Apply the same hardening to MCP tooling as to privileged admin tools Review client applications, inspectors, and local connectors for command execution risk, browser exposure, and token handling weaknesses.
• Build offboarding into MCP governance from day one Remove connectors, revoke server trust, and retire agent permissions when projects end or ownership changes, rather than letting stale access accumulate.
• Measure connector blast radius, not just deployment count Assess how many downstream systems each agent path can reach and prioritise controls where one connector can open multiple sensitive services.

Key takeaways

• MCP is now part of the identity perimeter, because exposed servers and weak client tooling can turn agent access into an open attack surface.
• The evidence points to a control gap that is already visible in production, with unauthenticated servers, RCE flaws, and broad AI-agent scope drift all appearing in the same ecosystem.
• Security teams should govern MCP with ownership, authentication, revocation, and blast-radius controls before agent access becomes operationally irreversible.

Key terms

• Model Context Protocol: Model Context Protocol is a standard that lets AI models connect to tools and data sources through a common interface. In practice, it creates a new access plane that identity teams must secure, because every server, connector, and tool exposed through the protocol can become a governed entitlement.
• Agentic access: Agentic access is the set of permissions and tool connections that an AI agent can use at runtime to complete tasks. It differs from ordinary automation because the agent may select actions dynamically, which makes identity, authorisation, and auditability central to governance.
• Connector blast radius: Connector blast radius is the amount of downstream reach a single integration path gives to an agent or application. A small number of connectors can still create large risk if they can touch sensitive systems, write actions, or privileged data without strong controls.
• Context-aware enforcement: Context-aware enforcement is the practice of checking identity, purpose, and risk at the moment access is requested. For agentic systems, it prevents a tool call from succeeding just because a connector exists, and it forces policy to travel with the request.

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

This post draws on content published by Pomerium: July 2025 Agentic Access and MCP Content Round-Up: Vulnerabilities, Governance & Growth. Read the original.