MCP servers need production security checks before deployment

At a glance

What this is: This is a production security checklist for MCP servers that maps the protocol’s weakest points to concrete verification steps across authentication, authorisation, validation, secrets, logging, supply chain, and network hardening.

Why it matters: It matters because MCP servers can expose downstream systems to any client that connects, so IAM, PAM, NHI, and platform teams need controls that scope and audit tool access before agents or users reach production data.

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.

👉 Read Stacklok’s MCP security checklist for production verification steps

Context

MCP server security is the set of controls that governs how an AI agent or client is allowed to discover tools, authenticate, and invoke downstream systems through the Model Context Protocol. The core problem is that the protocol defines connectivity, not assurance, so a server can be reachable, functional, and still dangerously overexposed if identity, scope, and validation are left to implementation choice.

The article’s central claim is that production readiness depends on verifying controls before traffic arrives, not after a server is already wired into workflows. For IAM and NHI teams, that means treating each MCP server as an access boundary with its own authentication, authorisation, logging, secrets, and supply-chain requirements, rather than as a simple application endpoint.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

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. Traditional APIs usually expose fixed interfaces; MCP adds a broker that can widen the blast radius if credentials or permissions are too broad. The danger is delegation without enough identity governance.

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. The failure is usually not obvious at the interface level. It appears later as leakage, unauthorised actions, or audit gaps that are hard to reconstruct after the fact.

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.

Technical breakdown

Why unauthenticated MCP servers become downstream open proxies

The MCP specification defines how tools are discovered and invoked, but it does not by itself guarantee that the server enforces identity at the transport boundary. If a server accepts a handshake without OAuth 2.1, or falls back to static keys and shared tokens, it loses the ability to prove who is calling and what that caller should reach. That turns the server into a relay for whatever downstream systems its tools can access. Per-request token validation matters because session-level checks leave a long-lived trust window after revocation or compromise.

Practical implication: enforce OAuth 2.1, reject anonymous sessions, and revalidate tokens on every tool call.

Tool-level RBAC is different from server-level access

Authorization in MCP is not solved by authenticating the caller once. A user or agent can hold a valid token and still be over-privileged if the server grants all tools on the boundary rather than checking scope per tool. This is the same failure pattern seen in shared service account designs: one credential becomes a superuser trap. MCP proxy servers make the problem worse because upstream API access can be confused between users unless tokens remain user-scoped and resource-bound.

Practical implication: map every tool to explicit scopes and validate audience, resource, and role at invocation time.

Why secrets, logging, and supply chain controls are part of the same control plane

MCP servers often fail as a system, not as a single bug. If credentials appear in code, logs, or build artefacts, the server’s identity boundary is already broken. If dependencies are unsigned or provenance is missing, the server can be tampered with before deployment. And if logging omits identity-linked telemetry, responders cannot reconstruct which tool was called, with which scope, from which identity. In other words, secrets management, observability, and supply chain integrity are operationally inseparable for production MCP.

Practical implication: pair secret scanning, runtime redaction, signed images, and identity-linked audit logs in the same release gate.

Threat narrative

Attacker objective: The attacker wants to use the MCP server as a trusted bridge into downstream applications, data stores, and internal tooling without needing separate access to each target.

1. Entry occurs when a remote MCP server accepts unauthenticated traffic, static API keys, or a weak OAuth flow that lets a client establish tool access without strong identity assurance.
2. Escalation occurs when broad server-level permissions, shared tokens, or unscoped downstream credentials let a low-privilege client invoke tools far beyond its intended task.
3. Impact occurs when the server becomes an open proxy to downstream systems, allowing data access, command injection, credential theft, or cross-system abuse at production scale.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Tool-level authorisation is the control that separates useful MCP from dangerous MCP. A valid token does not equal permission to every tool, and server-level access is structurally too coarse for production. This is the same discipline NHI teams apply to service accounts: scope must be explicit, revocable, and tied to task boundaries. The practical conclusion is that tool permissions need their own lifecycle, review cadence, and audit trail.

Secrets sprawl becomes more dangerous when MCP is the broker. The article’s controls around embedded credentials, runtime retrieval, and downstream secret storage reflect a deeper point: once the server can call other systems, it inherits their blast radius. Ephemeral downstream credentialing: a server that caches broad, long-lived credentials turns every tool into a standing privilege path. That is not a configuration flaw, it is a governance failure that multiplies across connected systems. Teams should assume compromise of one MCP component can expose many others.

Supply chain trust is now part of runtime trust for MCP. Signed images, provenance, and curated registries are not separate from IAM. They determine whether the code enforcing identity policy is itself trustworthy. For practitioners, the right question is no longer whether the server works, but whether the build, package, and deployment path can be trusted to preserve the intended access model.

Observability is the only way to prove MCP governance after the fact. If logs do not preserve identity, scope, tool name, and downstream target, then investigators cannot distinguish legitimate delegation from abuse. That makes audit logging a governance control, not just a detection feature. Teams should expect to prove who did what through the MCP layer, or accept that the layer is effectively unauditable.

From our research:

• 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.
• That pattern aligns with 52 NHI Breaches Analysis, where exposed credentials and weak lifecycle controls repeatedly expand blast radius after initial access.

What this signals

Ephemeral tool trust: MCP forces teams to think about every tool call as a time-bound identity event, not a durable application session. That shift matters for IAM and NHI programmes because scope, revocation, and auditability all need to work at invocation time, not just at login.

The programme signal is clear: server owners will need release gates that combine OAuth validation, secrets scanning, and provenance checks before production exposure. If those controls sit in different teams, MCP will be deployed faster than it can be governed.

For practitioners

• 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.
• Gate production on provenance and logging Require signed container images, verified provenance attestations, and audit logs that preserve user identity, tool invocation, and downstream target for every request.

Key takeaways

• MCP server security fails when identity, scope, and downstream access are treated as separate problems.
• The strongest warning sign is the prevalence of static keys, hard-coded secrets, and unscoped tool access in production-ready deployments.
• Teams that want safe MCP adoption must make authentication, authorisation, secrets, logging, and provenance part of the same control chain.

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.
• 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.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• 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.

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.

👉 Stacklok’s full post covers the test cases, control checks, and failure modes in operational detail.

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.