Notifications
Clear all
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.
NHIMG editorial — 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, while the remaining 91.5% rely on static API keys, shared tokens, or no authentication at all.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create more risk than traditional APIs?
A: MCP servers create more risk because they centralize access, make tools discoverable at runtime, and often sit close to the secrets that authenticate downstream calls.
Q: What breaks when MCP servers do not enforce tool scoping?
A: When MCP servers do not enforce tool scoping, models can reach tools and data across users, tenants, or environments that were never meant to be shared.
Practitioner guidance
- Enforce OAuth 2.1 for every remote server Reject anonymous connections at the transport layer, validate tokens on every tool call, and fail closed when issuer, audience, or expiry checks do not match the expected server identity.
- Scope permissions at the tool level Map each tool to a minimum set of OAuth scopes and RBAC rules, then test that read-only roles cannot invoke write or delete actions on the same MCP server.
- Remove long-lived credentials from server paths Store downstream API keys and tokens in a dedicated secrets store, retrieve them at runtime, and rotate them through a documented emergency runbook if compromise is suspected.
What's in the full article
Stacklok's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step verification checks for OAuth 2.1, PKCE, and per-request token validation across remote MCP servers.
- Concrete test cases for tool-level RBAC, scope enforcement, and confused deputy prevention in proxy architectures.
- Implementation guidance for secrets scanning, runtime redaction, and short-lived credential rotation.
- Supply chain and logging checks that pair signed images with identity-linked audit evidence.
👉 Read Stacklok’s MCP security checklist for production verification steps →
MCP server security checklist: are your controls ready for production?
Explore further
19/08/2026 4:32 pm
MCP security is really identity boundary design. The article shows that the protocol’s main failure is not just weak implementation hygiene, but an unclear trust boundary between the caller and every downstream system the server can reach. When authentication is optional or scope is server-wide, MCP stops behaving like a governed identity layer and starts behaving like an exposed relay. Practitioners should treat every server as a policy enforcement point, not a simple integration endpoint.
A few things that frame the scale:
- Only 8.5% of MCP servers in the ecosystem use OAuth, while the remaining 91.5% rely on static API keys, shared tokens, or no authentication at all, according to the State of MCP Server Security 2025.
- The same research found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which turns deployment artefacts into identity risk.
A question worth separating out:
Q: Who is accountable when an exposed MCP server is used to reach internal systems?
A: Accountability sits with the team that owns the delegated access path, the network exposure, and the identity controls around the server. In practice, that means security, platform, and application owners must all understand whether the MCP trust boundary is intentionally public or accidentally exposed.
👉 Read our full editorial: MCP servers need production security checks before deployment
