MCP servers need production security checks before deployment

At a glance

What this is: This is a production security checklist for MCP servers that finds adoption has outrun basic controls, leaving authentication, authorisation, input handling, logging, and supply chain verification too weak for real traffic.

Why it matters: IAM and platform teams need to treat MCP servers as production integration points, because weak identity, scope, and provenance controls can expose downstream systems through a single server boundary.

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.

Context

MCP server security is really a production governance problem: the protocol defines how agents discover and invoke tools, but it does not itself enforce authentication, validate inputs, or stop a server from exposing every downstream system it can reach. Once that server is in the path to production data and tools, identity and access decisions become part of the deployment boundary, not an optional hardening layer.

Stacklok’s checklist is useful because it translates an abstract protocol risk into concrete controls across authentication, tool permissions, input validation, secrets management, supply chain security, observability, and network hardening. The article’s core message is that production use requires security checks before exposure, not after the first client connects.

The result is a familiar identity pattern in a new place: if the server boundary is open, weakly scoped, or unobservable, the rest of the stack inherits that failure. For IAM and NHI teams, MCP changes where governance has to attach, not whether governance is needed.

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. The immediate failure is not just exposure of the server itself, but uncontrolled invocation of tools, replayable credentials, and a larger blast radius than the client was meant to have.

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. MCP workloads change tools, prompts, and data needs at runtime, so static credentials tend to authorize far more than the live task requires. The result is broad access to systems and records that should have been constrained to a narrower, context-aware request.

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. If teams cannot explain which tool ran, what policy decided, or whether a write was intentional, the MCP layer is still too permissive for production.

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.

Technical breakdown

Why MCP servers become open proxies without authenticated sessions

MCP defines tool discovery and invocation, not a complete security model. If a server accepts unauthenticated connections, or authenticates only once at session start, it can behave like an open proxy to whatever downstream APIs, data stores, or admin functions it can reach. OAuth 2.1 with PKCE matters here because it gives the server a verifiable client identity and a way to reject replayed or misdirected authorisation flows. The practical security failure is not just missing login. It is the absence of a trustworthy identity signal before the server begins brokering access to other systems.

Practical implication: Require remote MCP servers to reject anonymous access and validate tokens on every invocation, not only at handshake time.

Tool permissions, scopes, and token binding define the real blast radius

In MCP, authentication alone is not authorization. A token that proves who a client is still says nothing about which tools it may use, so tool-level RBAC and per-tool OAuth scopes are the control that limits damage when a client is compromised. Binding the token to a specific server resource also prevents replay across multiple MCP servers in the same environment. Without those constraints, a broad token or shared service account turns one compromised client into access to every exposed tool, which is a privilege problem disguised as a protocol integration issue.

Practical implication: Scope each MCP token to a single server and a narrow tool set, then verify those scopes on every tool call.

Why input validation and signed provenance are part of MCP identity security

MCP server risk is not limited to access control. If a tool passes user-controlled input into shell commands, file paths, or downstream APIs without strict validation, path traversal and command injection become practical exploit paths. The same applies to packages and container images: a server installed from a registry may be malicious or altered after review, so build provenance and image signatures are part of the trust boundary. In production, the server must be treated as both an access broker and a supply chain artifact whose integrity affects every connected system.

Practical implication: Validate all tool inputs, block unsafe path handling, and require signed, attested images before deployment.

Threat narrative

Attacker objective: The attacker wants to use the MCP server as a broker into downstream systems, then turn that access into data exposure, command execution, or wider environment compromise.

1. Entry occurs when a remote MCP server accepts weakly authenticated or anonymous connections and exposes tool discovery to an untrusted client.
2. Credential access follows when static keys, broad scopes, or weakly bound tokens let the client invoke downstream tools beyond its intended permissions.
3. Escalation occurs when permissive tools, poor input validation, or shared service credentials expand that access into file operations, command execution, or lateral reach into connected systems.
4. Impact is the exposure, alteration, or abuse of downstream data and services through the server’s production tool surface.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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

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.

Open MCP servers create identity blast radius, not merely exposed endpoints. When a server accepts broad tokens or shared credentials, every connected tool inherits the same access footprint. That collapses the distinction between a limited client and a privileged backend because one token can reach many downstream systems. The field should stop thinking of MCP as a thin protocol layer and start treating it as an access concentrator that needs explicit blast-radius containment.

Stacklok’s checklist gives MCP a named failure mode: production-ready interface, ungoverned trust. The memorable concept here is that an MCP server can look deployment-ready while still lacking the identity, scope, observability, and provenance controls that make it safe to use. That gap matters because security reviews often stop at functional correctness and miss the server’s downstream authority. Practitioners should measure readiness by whether each server can prove who is calling, what they can do, what changed, and what was deployed.

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.
• 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.
• Read next: MCP Security Guide

What this signals

Stacklok’s checklist shows that MCP governance starts with the server, not the agent. Access control has to be defined where the server brokers downstream authority, because a weak server turns every connected client into a potential path to internal systems. That is why production checks should cover identity, scope, and runtime trust together rather than as separate workstreams.

MCP server security checks should be treated as a release gate for NHI programmes. Once tool permissions, authentication, and image provenance are part of deployment criteria, teams can stop discovering trust gaps after clients are already connected. The practical shift is from reactive hardening to pre-production verification of who can call the server, what it can reach, and how it was built.

For practitioners

• 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.
• Block unsafe input paths before deployment Test file operations and command execution paths for traversal and injection handling, then fail the build when a tool can pass untrusted input into a shell or path.
• Require signed images and provenance Only deploy MCP servers with verified container signatures and provenance attestations so the runtime matches the reviewed source and build pipeline.

Key takeaways

• 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.
• The article’s research data points to broad weakness in both file-operation safety and command-injection resistance, with authentication also lagging far behind production expectations.
• Production readiness depends on a combined control set: authentication, per-tool scoping, input validation, logging, secrets management, and signed build provenance.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Per-Request Token Validation: Per-request token validation means the server checks issuer, audience, expiry, and scope on every tool call, not just at login or session setup. For MCP, this prevents a previously valid token from continuing to access tools after revocation, expiry, or scope change.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.