MCP Security Best Practices: The Complete Checklist (2026)
Short answer: Securing the Model Context Protocol comes down to a small set of controls applied on the protocol path, not scattered across each server. In priority order: put a gateway in front, allowlist tools deny-by-default, validate every tool argument, require human approval for destructive actions, run DLP on arguments and results, cap rate and payload size, log everything, authenticate with OAuth, score session risk, and choose a fail-closed posture. The checklist below turns each of those into a concrete control—and links to the deep-dive that shows how to implement it.
Most MCP incidents are not exotic. They are a tool that should never have been callable, an argument nobody validated, a delete that ran without a human in the loop, or a secret that left in a tool result. The practices here are ordered so that the first few cut the most blast radius for the least effort.
The prioritized checklist
Start at the top. Each row mitigates a distinct failure mode; the deep-dive shows exactly how to enforce it.
| # | Best practice | Risk it mitigates | Deep-dive |
|---|---|---|---|
| 1 | Put a gateway on the MCP path | Opaque endpoints, no enforcement point | MCP firewall and gateway |
| 2 | Allowlist tools, deny-by-default | Unknown or shadow tools executing | Tool allowlist policies |
| 3 | Validate tool arguments | Malicious or malformed payloads | Validate tool arguments |
| 4 | Human approval for destructive tools | Irreversible actions running silently | Human-in-the-loop approvals |
| 5 | Block destructive shell/filesystem | rm -rf, mass deletes, disk writes | Block destructive shell commands |
| 6 | DLP on arguments and results | Secret and PII exfiltration | Protect sensitive data |
| 7 | Rate limits | Runaway loops, abuse, cost blowouts | MCP rate limiting |
| 8 | Request/response size limits | Oversized payload DoS, huge results | Request size limits |
| 9 | Audit logging | No evidence of what crossed the boundary | MCP audit log |
| 10 | OAuth / auth on the server | Unauthenticated or over-broad access | Add OAuth to an MCP server |
| 11 | Session risk scoring | Slow-burn multi-step abuse | Session risk scoring |
| 12 | Fail-closed enforcement posture | Controls silently bypassed on error | Fail-open vs fail-closed |
1. Put a gateway on the MCP path
Every other control needs one place to run. A gateway sits between clients and your upstream MCP servers, gives you a stable URL, revocable Bearer tokens, and a single wire where policy is enforced instead of documented. Without it, each server enforces its own rules inconsistently and you have no chokepoint. Read what an MCP firewall and gateway actually is before anything else—it is the foundation the rest of this checklist assumes.
2. Allowlist tools, deny-by-default
Decide which tools may run and reject everything else. Deny-by-default means a newly added, renamed, or shadow tool cannot execute until someone approves it—the safest default when upstream servers change under you. Maintain a catalog of allowed tools, resources, and prompts, and treat additions as a review event. See tool allowlist policies for how to structure the catalog and handle unknown tool names.
3. Validate tool arguments
An allowlisted tool name is not the same as a safe call. delete_file is allowed, but the path argument decides whether it deletes a temp file or your home directory. Enforce input contracts with JSON Schema: types, required fields, enums, string length, and bounds on nesting. Reject anything that does not match before it reaches the upstream server. The full pattern is in validate MCP tool arguments with JSON Schema.
4. Human approval for destructive tools
Some actions should never run fully autonomously. Route high-impact tools—deletes, payments, production writes, mass emails—to a human-in-the-loop queue where an approver allows or denies before the call proceeds. This is also the control auditors ask about most, because it produces a named decision-maker per sensitive action. See MCP human-in-the-loop approvals.
5. Block destructive shell and filesystem commands
Shell and filesystem tools are the sharpest edge in any MCP deployment. Even with argument validation, an agent can assemble a legitimate-looking command that wipes data. Apply a dedicated layer that recognizes destructive shell patterns and either blocks them or forces approval. Details in block destructive shell commands from AI.
6. DLP: protect sensitive data
Secrets and PII leak in two directions—inside tool arguments the model sends, and inside JSON results the tool returns. Data-loss prevention scans both, with monitor, block, or redact modes, and org-specific rules on top of the defaults. Crucially, your audit metadata should record rule identifiers and classes, not the raw matched secret. See protect sensitive data in MCP.
7. Rate limits
A single misbehaving loop can generate thousands of tool calls in minutes—exhausting budget, hammering an upstream API, or amplifying an attack. Token-bucket limits per server (and optionally per client) keep a runaway agent from doing damage quietly. Read MCP rate limiting for how to size limits without breaking legitimate traffic.
8. Request and response size limits
Size is its own attack surface. Cap the request body before you even parse the JSON, so oversized payloads cannot be used to exhaust memory. Bound results too—a tool that returns a multi-megabyte blob can blow up the model context and your logs. See MCP request size limits.
9. Audit logging
“We think nothing bad happened” is not an audit answer. Record structured rows for every request: session, method, scrubbed arguments, outcome, correlation ID, and timing. That history is what lets you investigate an incident, prove compliance, and tune your other policies. See the MCP audit log.
10. Authenticate: OAuth on the server
Authentication proves who is calling. For user-delegated access, add OAuth so tokens carry identity and scope, and so you can revoke access per user. For a server that already exists and just needs hardening, the same principles apply without a rebuild. See add OAuth to an MCP server and secure an existing remote MCP server.
11. Session risk scoring
Individual calls can each look fine while the session as a whole trends dangerous—reconnaissance, then escalation, then exfiltration. Session risk scoring accumulates signals across a session (tool categories, argument sizes, sequence patterns) and tightens controls as risk climbs, from monitor to block. See MCP session risk scoring.
12. Choose a fail-closed posture
A control that silently disables itself when the policy database is unreachable is worse than no control, because you trust it. Decide, per server, whether an enforcement error should fail-open (allow, prioritize uptime) or fail-closed (deny, prioritize safety)—and make that choice explicit rather than accidental. See MCP fail-open vs fail-closed.
How these controls layer together
No single control is sufficient. Allowlisting stops unknown tools but not bad arguments to known ones. Argument validation stops malformed payloads but not a valid-but-destructive delete. Human approval catches the destructive delete but does not scale to every call. DLP catches leaked secrets but not resource exhaustion. Rate and size limits catch abuse but not exfiltration. Together they form defense in depth on the MCP boundary, and a gateway is what lets you apply all of them in one place with one audit trail.
Guardian is not a replacement for upstream server hygiene or model safety inside the LLM host. It shrinks blast radius and produces evidence for what crossed the MCP boundary. For a threat-by-threat mapping of these controls, see how Guardian maps MCP threats to controls.
FAQ
What are the most important MCP security controls?
If you can only do a few things, do the top of the checklist: put a gateway on the path, allowlist tools deny-by-default, validate arguments, and require human approval for destructive tools. Those four cut the most blast radius. Everything else deepens the coverage.
Is deny-by-default enough on its own?
No. Deny-by-default stops tools you never allowed, but it says nothing about the arguments passed to tools you did allow. An allowlisted run_query or delete_file still needs argument validation and, for destructive cases, human approval. Allowlisting is the first layer, not the only one.
Should MCP enforcement fail open or fail closed?
It depends on the server, and the point is to decide deliberately. Fail-open favors availability; fail-closed favors safety when the enforcement layer cannot reach its policy. Set it per server rather than inheriting a silent default—see fail-open vs fail-closed.
Do I still need to secure the upstream MCP server?
Yes. A gateway shrinks blast radius and gives you evidence, but it does not patch or fix malicious upstream code. Keep upstream servers updated and authenticated—see secure a remote MCP server—and treat the gateway as the layer that governs what reaches them.
Explore features · Use cases · Open MCP Trail
Related articles
- MCP firewall and gateway explained — The enforcement point every control needs
- How Guardian maps MCP threats to controls — Threat-to-control table
- Tool allowlist policies — Deny-by-default catalogs
- MCP human-in-the-loop approvals — When tool calls wait for a person
- Protect sensitive data in MCP — DLP on arguments and results