Topic starter
19/08/2026 3:56 pm
TL;DR: MCP server security is failing because adoption has outrun structured guidance, according to Stacklok’s checklist, and it cites survey data showing 82% of implementations are vulnerable to path traversal while more than a third face command injection risk. The governance problem is bigger than one control gap: MCP needs authenticated, scoped, observable, and supply-chain-verified access before production use.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “The MCP Security Checklist: What to Verify Before You Ship an MCP Server to Production”.
By the numbers:
- Among 2,614 MCP implementations surveyed by security researchers in early 2026, 82% use file operations that are vulnerable to path traversal attacks.
- Only 8.5% of MCP servers in the ecosystem use OAuth.
- The remaining 91.5% rely on static API keys, shared tokens, or no authentication at all.
Key questions
Q: What breaks when an MCP server ships without authentication and scoped tool access?
A: An unauthenticated or broadly authorised MCP server becomes an access broker for whatever downstream systems it can reach.
Q: Why do static API keys and app-level permissions create risk in MCP deployments?
A: They grant access at the wrong level of abstraction.
Q: What are the signs that an MCP implementation is not governed well enough for production use?
A: Common warning signs include broad tool access, missing masking on sensitive outputs, no approval path for privileged writes, and little or no tracing from agent to API.
Practitioner guidance
- Require authenticated remote access Reject anonymous MCP connections and verify OAuth 2.1 with PKCE on every remote server before it can broker any tool calls.
- Scope every tool at the server boundary Map each tool to a narrow permission set so a client authorised for read-only actions cannot inherit write or delete access on the same server.
- Validate token claims per invocation Check issuer, audience, expiry, and scope on every tool request so revoked or misdirected tokens fail immediately instead of surviving a prior session.
Bottom line: MCP servers can expose downstream systems even when the protocol itself is functioning as designed, because security controls are not enforced by the spec alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:32 pm
Production MCP security is an identity governance problem, not just an application hardening problem. The article shows that the protocol can define discovery and invocation while still leaving authentication, scoping, and downstream trust to implementers. That means the control boundary sits at the server, not the agent, and NHI teams have to govern the broker identity as a production asset. Practitioners should treat MCP servers as privileged integration points with their own lifecycle and access policy.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams evaluate an MCP server before production use?
A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.
👉 Read our full editorial: MCP servers need production security checks before deployment