MCP security gaps expose the identity controls agents still lack

At a glance

What this is: This roundup pulls together July 2025 MCP security developments and shows that agent-facing tooling is growing faster than the identity controls around it.

Why it matters: IAM, NHI, and agentic AI teams need to treat MCP as an identity and authorization problem, not just an integration pattern, because exposed servers and unsafe tool paths expand attack surface quickly.

By the numbers:

• Researchers found 1,862 internet-exposed MCP servers with no authentication or access controls.

Context

MCP is a protocol that lets AI applications and agents connect to external tools and data sources. In practice, that makes it an identity boundary, because the security question is not only what an agent can reach, but how access is authenticated, authorized, and constrained at the moment a tool call is made.

The July 2025 roundup highlights two separate failure modes: exposed MCP servers with no access controls, and vulnerabilities in widely used MCP tooling that can turn a trusted connection into remote code execution. That combination matters because it shows the ecosystem is not just scaling, it is scaling before the governance model around it has settled.

For IAM and NHI programmes, MCP should be read as a lifecycle and authorization problem, not a convenience layer for AI integration. The article’s examples are typical of a fast-growing platform category where controls lag adoption, which makes identity design the primary security task.

Key questions

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: Why do vulnerable MCP clients create more risk than ordinary integration bugs?

A: Because they translate remote input into local execution with the operator's or workstation's authority. That means the vulnerable component is not just a connector, it is an execution bridge that can turn trust into host compromise. The practical risk is loss of containment, since one bad tool path can inherit the privileges of the user running it.

Q: How should teams decide whether MCP access is safe enough to allow?

A: Teams should allow MCP access only when the agent or server can be bounded with explicit scopes, revocable credentials, and traceable client registration. If the integration depends on static secrets, shared keys, or opaque delegation, the access model is too durable for reliable governance and should be redesigned before production use.

Q: What should security teams do when an MCP integration is retired or replaced?

A: They should revoke the server path, disconnect the client, and remove any related tokens, secrets, or deployment hooks from the estate. The key risk is orphaned access, because old MCP links can persist after the business owner has moved on. Offboarding has to be part of the lifecycle, not an afterthought.

Technical breakdown

Why unauthenticated MCP servers are a governance failure

An MCP server is only as safe as the controls placed around discovery, authentication, and tool authorization. When a server is internet-exposed and accepts requests without identity checks, the protocol becomes an open service boundary rather than a governed access path. In identity terms, that means the server is operating without a trust decision at the point of use, so any client that can reach it may be able to enumerate or invoke tools. The result is not just a missing login screen; it is a missing policy enforcement layer for agent-facing access.

Practical implication: treat every externally reachable MCP endpoint as an access-controlled service and require explicit authentication plus authorization for each tool.

How MCP tooling flaws turn trust into code execution

The mcp-remote and MCP Inspector issues illustrate a familiar pattern in integration tooling: a trusted bridge accepts input from an untrusted server or browser context, then executes actions locally with the privileges of the operator or workstation. That is why remote-code-execution bugs in agent tooling are especially dangerous. They do not merely break the connector; they collapse the separation between model-driven intent and host-level execution. In identity terms, the tool boundary becomes a privilege boundary, and once that boundary fails, the attacker inherits the effective trust of the user or runtime.

Practical implication: isolate MCP clients and inspector tools from high-privilege endpoints and treat them as execution surfaces, not harmless developer utilities.

What MCP governance has to cover beyond protocol adoption

The governance announcement in the roundup shows the ecosystem beginning to acknowledge that protocol growth needs role clarity, specification changes, and maintenance discipline. That is necessary, but not sufficient. For security teams, governance has to extend to identity assignment, tool scoping, server inventory, and revocation when an MCP integration is retired or replaced. Without those lifecycle controls, a rapidly expanding MCP estate becomes difficult to audit and impossible to shrink safely. The real challenge is not whether MCP exists, but whether its access paths are owned and reviewable like any other production identity surface.

Practical implication: add MCP servers, clients, and connector permissions to the same inventory, review, and offboarding process used for other non-human identities.

Threat narrative

Attacker objective: The attacker wants to turn agent-facing trust into host-level control and then use that foothold to steal data or move deeper into the environment.

1. Entry occurs when an attacker reaches an internet-exposed MCP server or an untrusted MCP server is connected through a vulnerable client.
2. Credential or trust abuse follows when the connector or inspector executes with the operator's effective authority instead of enforcing tool-level constraints.
3. Escalation happens when the flaw allows arbitrary command execution or complete access to the host machine.
4. Impact is achieved through data theft, persistence, backdoors, or lateral movement from the compromised developer environment.

Breaches seen in the wild

• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

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 security gaps expose a governance boundary, not just a software bug class. The roundup shows that exposed servers, unsafe tool bridges, and immature governance are converging in the same ecosystem. That matters because MCP is becoming an identity decision point for agents, and identity decisions without policy enforcement become open access paths. Practitioners should treat MCP inventory, authentication, and tool authorization as one control surface.

Unauthenticated MCP access is a standing privilege problem in new clothing. A server that accepts requests from the public web without authentication is effectively granting persistent invocation rights to anyone who can find it. That is the same failure pattern security teams have spent years trying to remove from service accounts and APIs. The implication is straightforward: MCP adoption without access scoping reproduces old identity mistakes at agent speed.

Tool bridges now sit inside the trust chain, so local execution risk belongs in identity governance. The mcp-remote and MCP Inspector issues show that the client side of MCP can be the real blast-radius amplifier. Once a connector can translate remote input into local execution, the browser, workstation, or agent host becomes part of the identity perimeter. Practitioners need to think in terms of host authority plus tool authority, not protocol convenience.

Formal MCP governance is necessary, but the named concept here is identity blast radius for agent tooling. Each new connector, server, and inspector expands the set of identities and execution contexts that can be reached through one agent workflow. The article’s core signal is that this blast radius is growing faster than most teams can inventory it. Security programmes should expect MCP to force tighter ownership of connector lifecycles, not looser integration policy.

The market is moving toward distributed agent access, which makes identity the control plane. The roundup combines growth, open-source governance, and vulnerability reporting because the category is maturing in public. That maturation does not reduce risk; it reveals where the risk already lives. The practitioner takeaway is to align MCP rollout decisions with existing NHI and PAM governance, rather than allowing a new protocol to bypass them.

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: AI Agent Observability, Audit and Incident Response Guide

What this signals

Identity blast radius for agent tooling: MCP turns every new connector into an access decision point, so the real question is whether teams can still map who or what is allowed to invoke which tools. If that inventory is missing, the protocol's convenience will outrun the programme's ability to govern it.

Access reviews alone will not close MCP risk if the servers themselves are reachable without authentication. The control has to move left to issuance and authorization, because once agents can discover tools freely, the identity perimeter has already been widened.

The scale signal is already visible: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That is a reminder that agent ecosystems create secrets and access sprawl at the same time.

For practitioners

• Inventory every MCP server and connector Track externally reachable MCP endpoints, attached clients, and the tools each connector can invoke so the estate is reviewable as a governed access surface.
• Require authentication before tool exposure Block unauthenticated MCP access and enforce per-tool authorization so discovery does not automatically imply use.
• Separate client trust from host privilege Run MCP clients and inspector utilities with the minimum possible host rights, and remove any assumption that a trusted connector can safely execute local actions.
• Add MCP paths to offboarding checks When an MCP integration is retired, revoke server access, connector credentials, and any related tokens or deployment hooks with the same discipline used for other NHI estates.

Key takeaways

• MCP creates a new identity boundary for agents, and the biggest risk is when that boundary is left open or implicit.
• The July roundup pairs exposed servers with execution flaws, which shows that both control-plane access and client-side trust are still immature.
• Security teams should govern MCP as a lifecycle-managed access surface, with authentication, scoped authorization, and revocation built in from the start.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agent-facing Access Boundary: An agent-facing access boundary is the point where an AI system is allowed to reach into enterprise tools, APIs, or data stores. It is a security and governance boundary, not just a technical integration, because it defines scope, accountability, and the blast radius of machine-driven actions.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Tool Authorization: Tool authorization is the control that decides which external actions an AI system may invoke, under what conditions, and with what constraints. For autonomous or semi-autonomous systems, it is a core identity control because unsafe tool access can turn a model response into a real-world action.

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.