MCP Security Best Practices: Securing the Model Context Protocol in 2026

The Model Context Protocol won: it is the default way agents reach tools, databases, and services. Adoption at that speed always outruns hardening, and 2026 made the gap measurable. In January and February alone, more than 30 CVEs were filed against MCP servers, clients, and infrastructure: including CVE-2025-6514, a CVSS 9.6 remote code execution flaw in mcp-remote, a component thousands of setups relied on to reach remote servers. Meanwhile researchers cataloguing internet-exposed MCP servers found roughly half accepting connections with no authentication at all.

On top of the conventional vulnerability surface sit two threats specific to the protocol's design: prompt injection through content servers return, and tool poisoning through the descriptions agents use to choose tools. MCP is no less securable than any other integration layer, but it has to be secured on purpose, and mostly it has not been.

Every practice on the checklist assumes you know which servers exist and which agents use them. That assumption fails at the endpoint. Gateways see the traffic that routes through them: nothing more. The MCP server a developer added to their local Claude Code config yesterday routes through nothing: it runs on their machine, authenticates with their credentials, and appears in no gateway log, no OAuth grant, no SSO event.

Config-file audits do not close the gap either: they show what is declared on the machines you can inspect, not what is actually invoked, and they are stale the moment they finish. Closing the gap requires capture at the point of execution (per terminal, per session) where the agent actually makes the connection. That is the plane where agent observability operates, and it is why MCP inventory is an endpoint problem, not a network one.

Nexus instruments the agent side of the protocol. Its runtime hooks capture every tool action per session and per terminal, so which agents connected to which servers is a recorded fact with user, repo, and terminal attribution: including servers nobody registered. Policy is evaluated before the tool call executes: disallowed actions are denied in-flight with a stated reason, which turns the allow-list from a document into an enforced control. In the console, connectors and non-human identities appear in one inventory, so shadow servers surface as findings instead of surprises.

This is the enforcement half of a broader AI agent governance program; for the agent Nexus integrates with most deeply, see Claude Code security. For the routing layer itself, see the MCP gateway guide.

They solve different halves of the problem. An MCP gateway is a routing and management layer: one endpoint in front of many servers, with centralized auth, rate limiting, and logging for the traffic that flows through it. MCP security, as this page defines it, is the full set of controls: including the connections that never touch a gateway, which in practice means most local developer setups.

A reasonable architecture uses both: a gateway to consolidate and control sanctioned remote servers, and endpoint-level capture and enforcement for the ground truth of what agents actually do. If you are choosing between retrieval architectures first, start with RAG vs. MCP.