Topic starter
12/06/2026 12:22 am
TL;DR: July’s MCP roundup shows the ecosystem is expanding faster than security controls, with critical remote-code-execution flaws in mcp-remote and Anthropic’s MCP Inspector alongside 1,862 internet-exposed MCP servers found without authentication or access controls, according to Pomerium. The governance problem is not adoption itself, but the assumption that agent-facing tooling can be safely treated like ordinary integration infrastructure.
Editorial analysis by NHI Mgmt Group, based on content published by Pomerium: “July 2025 Agentic Access and MCP Content Round‑Up: Vulnerabilities, Governance & Growth”.
By the numbers:
- Researchers found 1,862 internet-exposed MCP servers with no authentication or access controls.
Key questions
Q: What breaks when MCP servers do not require authentication?
A: When MCP servers do not require authentication, the access boundary disappears.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP creates a new identity boundary for agents, and the biggest risk is when that boundary is left open or implicit.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 20 hours ago by NHI Mgmt Group
12/06/2026 9:33 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security gaps expose the identity controls agents still lack
This post was modified 20 hours ago by NHI Mgmt Group