MCP security best practices (2026)

The short version: validate all tool inputs, classify tools by destructiveness before connecting, scan servers against a known ruleset before use, and enforce runtime guardrails at the point of execution. The rest of this guide explains why each practice matters, and what BlueRock's scan data shows happens when teams skip them.

Data source: BlueRock MCP Trust Registry, as of June 2026, N=12,000+ MCP servers scanned. Part of the MCP Security cluster.

Why generic security checklists do not cover MCP

MCP servers sit at an unusual boundary: they translate agent intent into system action. A server can read files, query databases, run shell commands, or call external APIs, and an agent will exercise any capability it finds available. That means the attack surface is not static code; it is the intersection of what a server can do and what a connected agent decides to do at the app runtime.

Standard static analysis catches some of this. It misses the rest. When BlueRock scanned more than 12,000 MCP servers against 22 security rules mapped to the OWASP MCP Top 10, MAESTRO, and MITRE CWE, the numbers were direct: 6% have critical vulnerabilities, 42% have command injection flaws, and 33% have unbounded URI / SSRF vulnerabilities. These are not edge cases. They are the baseline of the current MCP ecosystem.

Best practices, grounded in the scan data

1. Validate and sanitize all tool inputs

42% of scanned MCP servers have command injection flaws. The root cause is consistent: tool parameters flow through to shell commands, SQL queries, or subprocess calls without sanitization. When an agent passes arguments to a tool, it is effectively constructing a request, and that request should never be trusted without validation.

Apply input validation at the server boundary, not inside the tool implementation. Treat every argument as untrusted. Use allowlists for parameter values where the domain is bounded; reject anything outside the expected shape before execution begins.

2. Restrict network fetch and outbound URIs

33% of scanned servers have unbounded URI or SSRF vulnerabilities. A server that accepts arbitrary URLs as tool parameters can be turned into a proxy for internal network scanning or credential harvesting, by the agent or by a malicious MCP server injecting instructions into the action path.

Allowlist outbound domains at the server level. Reject private-range IPs and loopback addresses before the request goes out. For servers that must fetch from user-supplied URLs, validate the resolved destination, not just the input string.

3. Classify tools by destructiveness before connecting

Not all MCP tools carry the same risk. A read-only database query and a schema migration tool are different threat surfaces. Treating them identically means either over-blocking (slowing developers) or under-restricting (expanding blast radius). BlueRock classifies MCP tools across six categories: read, write, destructive, admin, iam, and cost-impact.

Before connecting an MCP server to a production agent, classify each tool it exposes. Apply governance policy at the classification level: read tools can run freely, write tools require logging, destructive and admin tools require explicit human-in-the-loop confirmation or hard blocks for unattended agents.

4. Scan against a known ruleset, not just intuition

Custom code review catches what the reviewer thinks to look for. Systematic scanning catches what the data says is actually present. The 22 security rules in the MCP Trust Registry cover threat vectors in MCP server builds that traditional SAST scans miss: tool description poisoning, prompt injection via tool responses, denial-of-wallet patterns, transport layer gaps, and authentication failures.

Run every MCP server through a ruleset anchored to the OWASP MCP Top 10, MAESTRO, and MITRE CWE before connecting it to any agent. For internal builds, enable private repo scanning. Treat this as a gate in your CI pipeline, not a one-time check.

5. Apply runtime guardrails, not just pre-deployment rules

Static policies at deploy time degrade as agents acquire new capabilities and context. The 20,000+ new MCP servers published monthly means the ecosystem your agents connect to changes faster than any static rule set can track. Runtime enforcement catches what pre-deployment scanning cannot: behavior that emerges in production.

Enforce guardrails at the app runtime, before execution, at under 5 milliseconds of overhead. Block privilege escalation attempts, credential harvesting, and SSRF attacks at the MCP layer. Apply classification-aware policies so destructive and admin tools require explicit authorization, not just logging.

6. Maintain a durable agent identifier across the full action path

Incident response for agentic systems requires tracing what a specific agent did across its entire session: which tools it called, which data it accessed, what it executed. Without a persistent identity that survives across tool calls and MCP server boundaries, correlation is manual reconstruction from fragments.

Ensure your observability and governance stack maintains a durable agent identifier that persists across the full Agentic Action Path, from model decision through tool calls, MCP servers, data access, and execution to outcome. This is the prerequisite for meaningful post-incident analysis and policy enforcement.

Best practices at a glance

What MCP-specific threats look like in practice

The scan data surfaces six recurring issue categories worth knowing before you connect a server:

Unrestricted network fetch / SSRF. A server accepts a URL as a parameter and fetches it without validation. An agent, or an attacker injecting tool descriptions, can route requests to internal services.

Command injection. Shell commands constructed from agent-supplied parameters without sanitization. The classic case: a run_command tool that takes a string argument directly.

Denial of wallet / cost controls. No token limits, no circuit breakers, no cost-impact classification. An agent running a loop against an expensive tool can exhaust budget before anyone notices.

Dependency and supply chain risk. MCP server packages pulling in vulnerable transitive dependencies. Standard SAST on the server code misses what lives in the dependency tree.

Transport layer security gaps. Servers accepting unencrypted connections or with misconfigured TLS, exposing tool calls and responses in transit.

Authentication gaps. No verification that the caller is the expected agent. Open servers that any process on the network can invoke.

How BlueRock supports these practices

The MCP Trust Registry scans servers against 22 rules tied to OWASP MCP Top 10, MAESTRO, and MITRE CWE. It classifies tools as read, write, destructive, admin, iam, or cost-impact. For internal builds, private repo scanning covers servers that will never be public.

Guardrails enforce at the app runtime, blocking privilege escalation, SSRF, credential harvesting, and CLI-wrapper exploits before execution, at under 5ms overhead. The Trust Context Engine connects the two: it enriches execution with identity, trust attributes, and operational signals across the full Agentic Action Path, so both the scan findings and the runtime enforcement operate with full context, not fragments.

For MCP server selection, see how to choose the right MCP server for agentic development. For servers connected outside your review process, see how to detect shadow MCP servers. For the broader picture, start at the MCP Security pillar. For why gateways alone fall short, see why gateways can't secure agentic AI.

For a hands-on scan of your server, start with the MCP Trust Registry.