MCP Server Hardening Checklist for Enterprise Deployments

Giving non-technical employees access to AI agents at enterprise scale requires a secure, approved path to tools shared across deployments. This MCP server hardening checklist explains that path through six layers of controls. MCP standardizes tool access, but enterprise teams must implement the identity, authorization, transport, and runtime protections that make it safe.

Why MCP's protocol design leaves authentication and authorization entirely to the implementer

MCP standardizes how agents discover and call tools across hosts, clients, and servers. It does not enforce the security around those calls. Authentication, authorization, and transport protection remain implementation responsibilities, even where the specification defines requirements for them. A working connection is therefore not proof of a protected connection.

Three architectural properties make that distinction especially important. Dynamic discovery lets tools appear at runtime without prior security approval, while chained execution can combine individually permitted calls into an unapproved operation. With bidirectional data flow, tool descriptions also become an attack surface. The July 28, 2026 specification revision moves the protocol core to a stateless architecture and tightens authorization toward OAuth 2.0 and OpenID Connect. Yet these changes increase the delegation of security decisions to server developers and platform operators.

The active threat landscape enterprises are walking into

JFrog’s disclosure of CVE-2025-6514 shows how a malicious endpoint could compromise a connecting client. The affected MCP transport proxy, mcp-remote, had over 400,000 downloads. It passed unsanitized authorization URLs to the 'open' npm package, which on Windows indirectly invokes PowerShell and enabled command injection. The flaw was in the proxy’s own input handling.

The Supabase Cursor agent incident illustrates a different failure. In a demonstrated proof-of-concept, injected instructions in support tickets supplied by users caused an agent with privileged service-role access to leak integration tokens. Rug-pull attacks instead take advantage of timing by showing benign tool descriptions during approval and changing them after consent.

Why the enterprise governance gap compounds the technical risk

Individual controls fail when no one governs how they combine. A confused deputy uses its own elevated credentials for an agent, giving it permissions it never earned. Token passthrough creates a parallel problem when a user’s downstream access exceeds what the AI use case needs. Chained calls can then expose data that no single-tool review considered.

The compliance boundary is wider than the model. The EU AI Act does not directly address multi-agent architectures in its recitals, but every agent that performs a high-risk function falls within that boundary. For MCP, the gateway must produce evidence of who called which tool, with what data, under what authorization, and when. Comprehensive audit logging therefore ties the technical controls directly to the Act’s evidentiary requirements.

Layer 1 checklist — identity and authentication at every MCP entry point

To close the foundational gap, implement OAuth 2.1 with PKCE (S256), resource indicators, token audience validation, and issuer validation under RFC 9207. Update clients for the July 2026 revision, which deprecated Dynamic Client Registration and requires credentials to be bound to their issuing authorization server. Never reuse credentials across authorization servers. Clients must validate the iss parameter when present, while authorization servers are recommended to include it and have the option to omit it.

Expose an /authorize endpoint on every MCP server that returns a token tied to a specific user and tool list, with a maximum lifetime measured in minutes. Treat long-lived static keys as legacy credentials that need rotation right away. Authorize each execution based on who the user is and the context of the request. Use token exchange so the LLM host obtains a short-lived, scoped token from the enterprise identity provider and the MCP server verifies it before execution.

Tie every MCP identity to the enterprise identity provider through SSO and SCIM so offboarding and service-account rotation propagate across servers. Issue just-in-time credentials for the duration of a specific task. Expiry closes the window for later credential reuse. Audit servers that pass user OAuth tokens downstream, and replace passthrough with server-side token exchange scoped to the MCP use case.

Layer 2 checklist — network isolation and transport hardening

Once identity controls are in place, restrict where connections can originate and how they travel. Require TLS 1.3 with ECDHE for forward secrecy on all agent-to-server traffic, including internal and development deployments. Bind TCP listeners to localhost or a specific internal interface, never 0.0.0.0. The NeighborJack vulnerability class comes from exposing a listener to peers on the same network, allowing them to connect and execute commands. The binding is a security decision.

Run servers in private subnets with strict inspection of traffic between services, and require mutual TLS for service-to-service communication. Treat every connection as untrusted until identity and context have been verified, even inside the perimeter. Use firewall allow-lists that name the agents and services allowed to connect. Deny all other traffic by default rather than relying on an internal address as proof of trust.

Keep discovering servers so network policy can cover those that would otherwise go unknown. Scan the internal network for MCP deployments missing from the approved inventory. Experimental servers can become a standing exposure. Developers or data scientists may leave them running with default credentials, permissive settings, and unsecured APIs outside normal governance.

Layer 3 checklist — secrets management and credential hygiene

Authentication does not protect a secret sitting in plaintext configuration. To secure the server’s role as a credential hub, remove API keys, OAuth tokens, and service-account keys from configuration files, environment variables, and source code. Agents should retrieve credentials at runtime through one managed secrets store.

Replace static, long-lived secrets with credentials that are issued when needed and expire on their own. Automate rotation to limit the exploitation window after exposure. Expired credentials are no longer useful to an attacker. Audit server configurations across development, staging, and production for plaintext secrets, because duplicate copies accumulate across environments and are easy to miss without a full inventory.

Scope each service account to the systems and data its designated tools require. An agent acting through an over-permissioned server inherits that server’s reach, regardless of how carefully the user authenticated. A warehouse account that can read every table can expose PII alongside the revenue figures the task actually needed.

Layer 4 checklist — tool governance and supply chain verification

The next layer governs what the connection makes available. Treat every tool description as untrusted input, since clients pass descriptions from servers into the model’s context without built-in validation. Tool poisoning manipulates what a tool claims to do. Prompt injection through tool results instead manipulates what the tool returns, so approval controls must be paired with runtime output handling.

Maintain a curated catalog of approved servers and tools, and require deployments to use only entries that passed security review. Before installation, check whether source code is available, review dependency audit trails, verify who the publisher is, and check for known CVEs. An unauditable package leaves a gap in that review. Enforce registry allow-lists against typosquatting, pin dependencies to verified versions, and validate integrity hashes during installation.

Approval must also account for changes after installation. Watch tool descriptions for changes and flag them for a human to review before agents continue with the changed definitions. Stale consent is not approval of new behavior. Scope every tool to its minimum required operations, with explicit justification and elevated review for shell access or filesystem writes.

Layer 5 checklist — runtime sandboxing and prompt injection containment

To limit damage when an earlier control fails, run each MCP server in its own isolated container with as few permissions as it needs. Deny filesystem and network access by default, then provide only explicit mounts and egress rules needed for the task. A server that has no reason to touch the host filesystem should have no mount for it. Isolation must restrict access to the host, other servers, and privilege escalation, rather than merely place the process inside a container.

Validate and sanitize tool results before they enter the model’s context window. This boundary is the point to separate returned data from attempted instructions. Once inside the context, injected text can look like legitimate content. Also treat every LLM-generated tool input as untrusted, especially where the server can execute shell commands or scripts.

Require explicit human confirmation for irreversible or high-impact calls, including sending email, modifying records, and invoking external APIs with write access. The MCP specification says a human should be able to deny tool invocations. Scope runtime permissions to the specific task. This makes the identity decision enforceable during execution instead of allowing the agent to fall back on the server account’s full permissions.

Layer 6 checklist — audit logging, OTEL tracing, and compliance evidence

To demonstrate that the other layers operate correctly, log every tool call with its agent, tool, parameters, authorization context, time, inputs, and outputs. A tool name or outcome alone is insufficient. Link each entry to the human who started the agent session as well as the service account used downstream. Preserve that attribution across chains of servers so investigators can reconstruct the sequence and its authority.

Write logs to append-only, cryptographically verifiable storage from creation. Evidence that can be altered cannot establish a trustworthy history. Implement OpenTelemetry (OTEL) distributed tracing across the full agent-to-MCP-to-system call chain to expose latency, failures, and unexpected call patterns. Pair that record with real-time detection that spots changed tool descriptions, unusual call sequences, calls outside the approved inventory, and amounts of data that do not fit the task.

The EU AI Act began its general enforcement phase on August 2, 2026, when Article 50 transparency rules and GPAI enforcement powers came into force. That deadline has passed, so evidence must be collected now. High-risk obligations are phased in through 2027–2028, so the dates must not be treated as one blanket enforcement deadline. Keep logs for as long as the applicable requirements demand, and provide exports in formats auditors can use. Logs must be available during an audit window to serve as evidence.

How do you operationalize the checklist and keep pace with MCP’s evolution?

A checklist applied only at deployment cannot govern tools and specifications that change afterward. To make these controls an operating practice, combine continuous server discovery with automated policy checks at each individual tool call. Evaluate the identity and context of that request. Session approval is too coarse for chained execution.

Track specification revisions through a process that maps each change to affected controls before deployments inherit deprecated patterns. The July 28, 2026 revision changed authentication requirements and introduced new stateless workflow concerns. Tracking identifiers that may be predictable put workflow and tenant isolation at risk, while tasks that are cheap to create can place heavy demands on server resources. A specification update therefore needs security review alongside compatibility testing.

For teams enabling non-technical employees, the practical response is a golden path that is secure by default. A unified platform covering authentication, tool governance, runtime detection, and audit logging reduces the integration gaps created by separate point tools. The selection criterion is coverage across all six layers and enforcement at tool-call depth, so broader access does not depend on broader standing permissions.