Notifications
Clear all
Topic starter
12/06/2026 9:25 pm
TL;DR: MCP’s rapid adoption has produced thousands of internet-reachable servers with no authentication, while researchers have also documented supply-chain compromise, malicious servers, and localhost abuse, according to WorkOS and cited security reports. The governance problem is no longer theoretical: MCP turns tool access into ambient authority unless identity, scope, and audit controls are enforced.
NHIMG editorial — based on content published by WorkOS: MCP auth: The difference between a bridge and a backdoor
By the numbers:
- CVE-2025-6514 in mcp-remote affected over 437,000 downloads.
- The September 2025 npm phishing campaign compromised 18 popular packages.
Questions worth separating out
Q: What breaks when an MCP server is exposed without authentication?
A: Without authentication, an MCP server becomes ambient authority.
Q: Why do MCP connectors create more risk for NHI governance than ordinary APIs?
A: MCP connectors often sit between AI agents and privileged tools, so a single endpoint can expose files, cloud actions, email, and databases at once.
Q: How do security teams know if an MCP deployment is outside its intended boundary?
A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch.
Practitioner guidance
- Require authentication on every MCP server Block any server that can touch production data, run commands, or enumerate tools unless access is mediated through authenticated identity and revocable tokens.
- Scope tool permissions to least privilege Map each MCP tool to a narrow role or entitlement set and remove broad delegation paths that let one connector inherit unrelated system permissions.
- Treat MCP packages as control-plane dependencies Pin versions, review transitive dependencies, and place MCP proxies and plugins under the same approval and monitoring process used for privileged infrastructure.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The exact auth patterns the vendor recommends for MCP servers that sit in front of real systems.
- The implementation examples for mapping OAuth scopes to internal roles and permissions.
- The logging and audit workflow details for tracing what users, agents, and MCP clients did.
- The deployment guidance for avoiding accidental public exposure of local or networked MCP services.
👉 Read WorkOS's analysis of MCP authentication and security exposure →
MCP authentication gaps: are your agent connectors safe enough?
Explore further
12/06/2026 11:27 pm
Identity does not become safer when tool access is hidden inside protocol convenience. MCP makes integration easier, but ease of integration is not a security control. When an agent connector can reach files, email, databases, or cloud consoles, the connector becomes a privilege boundary that must be governed like any other production access path.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Who is accountable when an MCP server is abused through a malicious package or proxy?
A: Accountability should rest with the team that approved the connector, the package source, and the access model, because MCP supply-chain compromise is an identity governance failure as well as a software risk. If the component can execute or delegate privileges, it belongs in the same governance chain as other production access paths.
👉 Read our full editorial: MCP auth failures are turning agent connectors into backdoors
