MCP security checklist: the short version
A defensible MCP deployment should pass all eight checks below before it reaches production.
Model Context Protocol connects AI agents to files, APIs, databases, browsers, command runners, and other systems that can act. A server can be legitimate while one tool is overprivileged. A token can be valid while its audience is wrong. A response can match its schema while its text tries to redefine the agent's instructions. An approval can be genuine while the executed action has drifted from what the user reviewed.
- Inventory every MCP server, package, version, owner, transport, tool, and data destination.
- Expose only the tools and scopes required for the current task; separate read authority from write authority.
- Authenticate every inbound request, validate token audience, and require per-client consent.
- Pin and review tool names, descriptions, schemas, manifests, and other agent-readable metadata.
- Treat tool results and resource content as untrusted input before they return to the model.
- Sandbox local servers and generated server code with minimal filesystem, process, and network access.
- Enforce outbound allowlists and validate every discovery URL and redirect hop against SSRF.
- Bind human approval to the exact action, arguments, destination, and current tool definition; then recheck after changes.
The point is not to claim that one product secures the entire protocol. The point is to show what each security layer is expected to stop, how to verify it, and where a content-layer input filter or firewall fits. The rest of this guide explains the attack behind each practice and gives a concrete verification test.
1. Inventory and pin every MCP server before enabling it
MCP server security starts with knowing exactly what code, configuration, transport, tools, and destinations you are trusting. Maintain an inventory that records the server source, package and version, integrity or signature evidence where available, owner, transport, exposed tools, requested scopes, credential access, filesystem access, and outbound destinations.
This control addresses two connected classes in the MCP Attack Atlas: capability drift and rug pulls — a server changes what a previously approved tool does (GLS-MCP-002, GLS-MCP-003) — and registry and manifest metadata poisoning — a manifest asserts a capability or policy it should not (GLS-MCP-013, GLS-MCP-POISON-201).
Do not treat a marketplace listing, GitHub star count, familiar package name, or successful installation as a security review. Pin versions or immutable artifacts where possible. Record the expected tool list and hash or version the reviewed definitions. Require review when a server adds a tool, changes a description, broadens a schema, requests a new credential, or introduces another destination.
Verification test: export the current server and tool inventory, compare it with the approved baseline, and fail the deployment if a server, version, tool, schema, scope, command, or destination changed without a recorded decision.
2. Minimize tool exposure and separate read from write
Every MCP client should receive only the tools and scopes needed for its current task, with read and write authority separated by default. A support agent that needs to read a ticket should not inherit permission to delete tickets, modify billing, search every customer record, or call unrelated servers.
This practice maps directly to scope creep and stale consent in the Atlas (GLS-MCP-014, GLS-MCP-015): yesterday's approval quietly covers today's wider action. It also reduces the damage if a tool result, prompt, or token is compromised.
Use allowlists rather than exposing an entire catalog. Start with low-risk discovery and read operations. Elevate narrowly when a user requests a privileged action. Keep tool availability task- and session-bounded, and expire elevated access instead of letting it become the new default. Enforce authorization at the server for every operation; a model's decision to call a tool is not authorization.
Verification test: attempt each write operation with a read-only identity, a token from another task, and a token from a previous session. All three should fail at the server, even if the client sends a syntactically valid tool call.
3. Authenticate every request and validate token audience
MCP authentication must prove who is calling, which server the token was issued for, and which operation that identity may perform. The official MCP security guidance explicitly forbids token passthrough: an MCP server must not accept a token that was not issued for that server.
For remote servers, validate issuer, audience, signature, expiration, and scopes on every protected request. Use exact registered redirect URI matching. Use short-lived, single-use OAuth state values and set them only after the user has approved consent. MCP proxy servers should maintain consent per client instead of assuming that prior consent to a shared upstream client covers every newly registered MCP client.
Authentication does not neutralize hostile content. A correctly authenticated server can still return a poisoned tool description or result. That is why identity controls and content controls belong in the same architecture, not in competing product categories. This practice also constrains the Atlas classes for negotiation and disclosure pretexts (GLS-MCP-011, GLS-MCP-012) and scope creep and stale consent (GLS-MCP-014, GLS-MCP-015): a valid protocol exchange must not downgrade constraints, disclose unnecessary capabilities, or convert one consent decision into broader authority.
Verification test: send the server a valid token issued for a different audience, a token with an excessive scope claim, a replayed state value, and a request carrying only a session or state handle. Each request should be rejected and logged with enough context to investigate it.
4. Review tool descriptions, schemas, and manifests as executable influence
Tool metadata is part of the agent's security boundary because the model reads names, descriptions, schemas, manifests, and annotations before deciding what to do. A field that looks descriptive to a developer can behave like an instruction to the model.
This practice maps to tool shadowing and line jumping — a tool claims an identity or trust level that is not its own (GLS-MCP-004, GLS-MCP-005, GLS-MCP-006) — and registry and manifest metadata poisoning (GLS-MCP-013, GLS-MCP-POISON-201).
Keep descriptions functional and bounded. Reject imperative language that tells the agent to ignore policy, broaden access, hide an action, trust another destination, or treat the tool as more authoritative than it is. Use strict schemas that reject unknown fields where feasible. Version-control reviewed definitions instead of loading mutable descriptions from an untrusted registry on every run.
A content-layer input filter or firewall belongs here. Sunglasses can inspect agent-readable files, instructions, configuration, tool descriptions, manifests, and related metadata for known hostile patterns before that content enters the agent's decision context. The dedicated MCP tool poisoning guide explains this attack path in depth.
Verification test: compare the live tool definition with the reviewed definition, then insert a harmless test string that attempts to broaden scope or override policy inside a description or annotation. The security pipeline should flag or reject the change before the model sees it.
5. Validate tool results before they re-enter the model
Every MCP tool result should be treated as untrusted input, even when it comes from an authenticated and approved server. Tool output can contain natural-language instructions, forged provenance, hidden redirects, markup, structured fields, or encoded content that tries to control the next step.
The Atlas documents result-side mechanisms including tool output shadowing, forged provenance, structured-output schema trapdoors, multi-stage encoding camouflage, and stream reassembly desynchronization. The broader shipped MCP coverage also includes handoffs, callbacks, and credential lures (GLS-MCP-APT-209).
Validate the declared structure, but do not stop there. Schema validity only proves that the value has the expected shape. It does not prove that a text field is safe to treat as policy. Normalize content before inspection, preserve the source of each field, bound response size, and keep data separate from control instructions. Require a new decision before a result can change scope, select a new destination, request credentials, or trigger another tool.
Verification test: return a schema-valid result containing an instruction to ignore prior rules, a link to an unapproved host, and a claim that a privileged follow-up action is already authorized. The client should preserve the data value without promoting those claims into agent authority.
6. Sandbox local servers and generated server code
Local MCP servers should run with the minimum filesystem, process, environment, and network access required for their stated function. A local server is executable code running with the client's privileges; a one-click configuration can therefore become a code-execution path.
This control maps to generated server code execution in the Atlas (GLS-MCP-008, GLS-MCP-009), including shell interpolation and bypassable command allowlists. The official MCP guidance recommends showing the exact command before installation, requiring explicit consent, highlighting dangerous operations, and sandboxing local servers. It also notes that direct stdio use is not inherently vulnerable; the elevated risk appears when a proxy architecture can spawn processes and a separate flaw exposes that capability.
Use containers, operating-system sandboxes, restricted service accounts, or equivalent process isolation. Pass only the environment variables the server needs. Mount only approved directories. Deny arbitrary subprocess creation. Prefer no network access when the tool does not require it, and use explicit egress policy when it does.
Verification test: run the server under its production identity and attempt to read a non-approved file, enumerate inherited secrets, spawn an unapproved command, and contact an unapproved domain. Every attempt should fail outside the model layer.
7. Restrict egress and harden discovery against SSRF
MCP clients and servers should permit outbound connections only to approved destinations and should validate every discovery URL, resolved address, and redirect hop. OAuth and protected-resource discovery can lead a client through attacker-controlled metadata to localhost, private networks, cloud metadata services, or a redirect chain that ends there.
This practice supports the Atlas classes for transport and origin exposure (GLS-MCP-007, GLS-MCP-010) and handoffs, callbacks, and credential lures (GLS-MCP-APT-209). It also addresses the SSRF threat defined in the official MCP security guidance.
Require HTTPS in production. Block private, loopback, link-local, and reserved ranges unless a narrowly documented local-development exception applies. Validate redirects one hop at a time. Account for DNS rebinding and time-of-check/time-of-use gaps. Route server-side discovery through an egress proxy or network policy where practical.
Verification test: provide discovery metadata that points directly to a private IP, redirects to a cloud metadata endpoint, and resolves to a public address before changing to a private address. The client should block all three paths and record the rejected destination.
8. Bind approval to the exact action and recheck after change
Human approval is meaningful only when it is bound to the exact tool, arguments, destination, side effects, and definition that will execute. A generic “allow this server” decision should not silently authorize every future capability, and a preview of one action should not approve a different payload after normalization or retry.
This practice constrains scope creep and stale consent (GLS-MCP-014, GLS-MCP-015) and Atlas mechanisms such as approval-hash collision, approval-channel desynchronization, consent-token confusion, and decision-trace forgery.
Show the user what will happen in plain language without truncating dangerous details. Make high-risk approval single-use and short-lived. Bind it to a canonical action representation with explicit domain separation. Invalidate it if the tool definition, arguments, destination, identity, or side effects change. Keep an audit record that connects the request, decision, executed action, and result.
Verification test: approve a read action, then change one argument, destination, tool version, or operation to a write before execution. The approval must fail closed and require a new review.
Which MCP security tools do you actually need?
No single MCP security tool owns the whole trust boundary; a strong deployment combines complementary controls.
| Security layer | What it should decide | What it does not prove |
|---|---|---|
| Server inventory and registry policy | Which servers and versions may be installed | That a permitted server's current output is safe |
| Identity and OAuth | Who connected, token audience, scopes, consent | That returned content should control the next action |
| Gateway and tool allowlist | Which servers and tools are exposed | That descriptions, schemas, and results are trustworthy |
| Sandbox and process policy | What local code can access or execute | That agent-readable content is non-hostile |
| Egress controls | Which destinations can be reached | That an allowed destination is appropriate for this action |
| Human approval | Whether a person approved an exact sensitive action | That a changed action still matches the approval |
| Content-layer filter/firewall | Whether agent-readable instructions, metadata, and outputs match hostile patterns | Authentication, authorization, process isolation, or network enforcement |
| Logging and monitoring | What happened and whether behavior drifted | Prevention by itself |
If you searched for an MCP scanner, Sunglasses fits as the local input filter/firewall layer: it can scan files and agent-readable content, but its security promise is to filter or block hostile content before the agent reads or acts on it. It should sit beside — not replace — identity, gateway, sandbox, egress, approval, and monitoring controls. For server-level hardening specifics, see How to Secure MCP Servers for AI Agents; for the broader server/scope/outbound picture, see MCP Security for AI Agents.
A production-ready MCP security checklist
Use this checklist as a release gate, not as a one-time architecture exercise.
- Every server has a named owner, approved source, pinned version or immutable artifact, and review date.
- The deployed server and tool inventory matches the approved baseline.
- Tools are allowlisted per task; read and write authority are separated.
- Every protected request validates identity, issuer, audience, expiration, and operation-level authorization.
- Consent is stored per client, and redirect URIs use exact matching.
- Tool names, descriptions, annotations, manifests, and schemas are reviewed and versioned.
- Unknown schema fields are rejected where feasible.
- Tool results are normalized, source-labeled, size-bounded, and inspected before model reuse.
- Local servers run with minimal filesystem, environment, process, and network access.
- Discovery and OAuth URLs reject dangerous schemes, private ranges, unsafe redirects, and rebinding paths.
- High-risk approvals bind to the exact tool, arguments, destination, definition, and side effects.
- Logs connect the request, identity, consent, approval, execution, and result without exposing secrets.
- Any server, tool, schema, scope, credential, command, or destination change triggers re-review.
- Test fixtures cover manifest poisoning, tool shadowing, scope drift, unsafe code execution, origin exposure, negotiation pretexts, and callback/credential lures.
The practical standard: a secure MCP deployment makes authority explicit at every transition — install, connect, describe, call, return, approve, and act. The protocol documentation supplies essential implementation rules. OWASP supplies a broad defensive checklist. The MCP Attack Atlas adds the adversarial test: which concrete attack class is this control supposed to catch, and have we verified that it does?
That is the bar. Do not trust a server because it installed cleanly. Do not trust a tool because it is authenticated. Do not trust a result because it matches a schema. Do not trust an approval after the action changes. Reduce authority, preserve provenance, inspect agent-readable content, and fail closed when the evidence no longer matches the decision.
Sources: Model Context Protocol — Security Best Practices · OWASP MCP Security Cheat Sheet · Sunglasses MCP Attack Atlas