How to Secure MCP Servers in Production

MCP servers are the connective tissue between your AI agents and the systems they act on — filesystems, databases, APIs, code execution environments. Unlike a traditional API endpoint where a human initiates each request, an MCP server receives calls from an autonomous agent running at whatever pace the model decides. That changes the threat model considerably.

This guide walks through the four concrete steps to harden an MCP deployment before it goes to production, and closes with a look at what the CVE findings in Anthropic's own SDK mean for teams shipping today.

Why MCP Server Security Is Different from API Security

Traditional API security assumes a human on one end and a server on the other. Rate limits, CORS policies, and OAuth scopes are all calibrated for human-paced interaction. MCP changes that in two ways.

First, the caller is a model. It does not get tired, it does not notice that it is doing something unusual, and if the system prompt or tool descriptions have been tampered with, it will follow the tampered instructions faithfully. Second, the tool surface exposed to the model is often far broader than the task requires — a developer hooks up an MCP server with filesystem access to help with one workflow and forgets it can also read /etc/passwd or write to the deploy pipeline.

The practical consequence is that the perimeter you need to defend is the tool call layer, not just the network edge.

Step 1 — Audit Your Dependency Tree

Before you write a single line of policy, know what your MCP server is built on. Run npm audit for Node-based servers and pip-audit for Python-based ones. These tools catch package-level CVEs in your dependency tree and should be wired into CI so they block merges on high-severity findings.

Standard SCA (Software Composition Analysis) is a necessary starting point but it has a ceiling. It tells you what vulnerabilities exist in your packages; it does not tell you whether a malicious tool call can exploit them at runtime. Both layers matter.

The scale of the problem is worth understanding before you audit. Our May 2026 scan found that 75% of the top 400 MCP packages carry known CVEs. The full breakdown, including the unique CVE count and affected SDK versions, is documented in the State of MCP Security 2026 report.

Step 2 — Scope What Each Agent Can See

Once your dependencies are clean, the next question is what tools you actually want the agent to have access to. The default answer — "everything the MCP server exposes" — is rarely the right one.

Navil enforces access policy through a navil.yaml file checked into your repository alongside your agent configuration. A minimal policy looks like this:

# navil.yaml
policy:
  allow:
    - tool: read_file
      scope: "./src/**"
    - tool: run_tests
  deny:
    - tool: "*"
      default: true

The policy wraps your existing MCP server config — for example ~/.cursor/mcp.json or Claude Code's equivalent — without requiring changes to the server itself. Because the agent only receives the tools it is allowed to use, the schema it sees shrinks dramatically. In practice, this produces a 94% reduction in schema tokens, which also means lower prompt costs and less surface for prompt injection to exploit.

Step 3 — Enforce Policy at Runtime

Writing a policy in YAML is the intent. Enforcing it on every tool call is the guarantee. navil secure wraps your MCP server configuration and interposes on each call before it reaches the underlying server.

Setup takes under a minute:

pip install navil
navil secure

navil secure completes its initial configuration in approximately 47 seconds. After that, policy enforcement adds 2.7 µs per-message overhead at the p50 and 6.1 µs at the p99. Those numbers are well below the threshold where latency becomes a product concern, even for high-frequency tool calls.

The enforcement layer works with Claude Code, Cursor, Continue, OpenClaw, and custom MCP agents. The core is Apache 2.0 licensed.

Step 4 — Monitor Anomalies

Runtime enforcement blocks policy violations. Anomaly monitoring catches the things that are technically within policy but behaviorally suspicious — an agent that suddenly starts reading configuration files it has never touched before, or a burst of outbound API calls that does not match any known workflow.

Navil's detection library covers 568 patterns across 36 categories. Categories include prompt injection indicators, data exfiltration patterns, privilege escalation sequences, and lateral movement signatures. Every tool call that passes policy enforcement is also evaluated against this pattern library, and anomalies are logged with enough context to reconstruct what the agent was doing and why.

This is where runtime enforcement adds the layer that perimeter tools and SCA scanners cannot provide. A dependency audit tells you a CVE exists. Runtime monitoring tells you whether someone is trying to exploit it against your running deployment.

What the SDK CVEs Mean for Your Deployment

The most widely deployed MCP infrastructure is Anthropic's own. As of our May 2026 scan, @modelcontextprotocol/sdk (the Node.js SDK) carries 3 HIGH CVEs, and the mcp Python SDK also carries 3 HIGH CVEs. These two packages together affect 54–68% of the MCP ecosystem, meaning the majority of MCP servers in production today are built on dependencies with known, unpatched HIGH vulnerabilities.

The specific vulnerability classes include ReDoS (regular expression denial of service), DNS rebinding (allowing attacker-controlled servers to make cross-origin requests appear local), and cross-client data leaks (where session data bleeds across agent boundaries). Each of these has a concrete attack path against a production MCP deployment.

What this means practically: npm audit or pip-audit in CI will flag these. If your CI pipeline is not running those checks today, add them before the next deploy. If you are waiting on upstream patches, runtime enforcement gives you a compensating control — Navil can block the call patterns that would exploit these vulnerabilities even before the CVEs are patched.

Check your installed SDK versions against the advisory list in the State of MCP Security 2026 report. If you are on an affected version, the remediation path is: patch where a fix exists, and layer runtime enforcement regardless.

The four steps above — audit dependencies, scope tool access, enforce at runtime, monitor for anomalies — are not sequential checkboxes. They are complementary layers that together reduce the attack surface from "everything the model can ask for" to "exactly what the policy says, with every deviation logged."

To set up Navil on an existing MCP deployment, the quickstart takes less than five minutes. For a full list of supported agents, policy options, and integration patterns, see the features page.