MCP security checklist
MCP Security Checklist
A production-minded checklist for approving MCP servers before agents can read data, call tools, write records, browse systems, or trigger workflows.
TL;DR
MCP is safe enough for production only when it is governed like a permissions and execution boundary. Before connecting agents to MCP servers, verify server identity, OAuth audience binding, least-privilege scopes, tool approval rules, schema-change monitoring, sandboxing, secrets handling, audit logs, and incident response.
Before installing a server
- Inventory the server. Record owner, publisher, transport, version, package source, endpoint, scopes, tools, prompts, resources, and data classes.
- Prefer first-party servers. Use official provider-hosted servers where possible, especially for CRM, file storage, data warehouse, identity, and collaboration systems.
- Review tool metadata as untrusted. Tool names, descriptions, schemas, prompts, resources, and outputs can carry instruction-like content.
- Pin versions and definitions. Hash server packages, container images, and tool schemas. Re-approve when descriptions, scopes, or destinations change.
- Block unsafe STDIO configuration. Do not let users or external content control command names, arguments, shell interpolation, or startup paths.
Before production
Auth
Use HTTPS for remote MCP. Validate bearer tokens on every request. Enforce OAuth audience binding and reject tokens issued for a different resource.
Scopes
Split read, write, delete, export, and admin actions. Avoid broad scopes such as all files, all database actions, or global admin.
Approvals
Require explicit human approval for destructive, external, financial, privileged, or data-sharing actions. Show exact server, tool, arguments, and destination.
Sandboxing
Run local servers in containers, VMs, or restricted processes. Limit filesystem access, network egress, environment variables, and metadata-service access.
Runtime monitoring
| Log field | Why it matters |
|---|---|
| User, host, client, server | Shows who initiated the tool path and which surface mediated it. |
| Tool name and schema hash | Detects rug pulls, schema drift, and newly exposed capabilities. |
| Arguments hash and data class | Preserves reviewability while reducing sensitive log exposure. |
| Approval actor and policy | Separates auto-approved, user-approved, and admin-approved actions. |
| Destination and result class | Flags exfiltration chains such as read private data, transform it, then send it outside. |
Threats to test
- Tool poisoning. Add hidden or conflicting instructions to a tool description and verify the client treats metadata as untrusted.
- Indirect prompt injection. Return hostile instructions from a webpage, ticket, file, or database record and verify they cannot override policy.
- Schema drift. Change a tool description, argument, or destination after approval and verify the system blocks or re-approves it.
- Token misuse. Try replaying a token against the wrong MCP resource and verify audience validation rejects it.
- Cross-server leakage. Read restricted data from one server and attempt to send it through another server without approval.
What security review should ask
Can we revoke this server quickly? Can we tell which user approved a sensitive action? Can the agent chain two harmless-looking tools into a harmful outcome? Can a server change its tool definitions after approval? Can data from one business system be smuggled into another without a human noticing?
If the answer is unclear, keep the server in read-only or draft-only mode. Production MCP should earn write access one workflow at a time.
FAQ
Can MCP expose sensitive data?
Yes. MCP can expose data through resources, tool results, prompts, logs, or cross-server tool chains. Treat every server as a data access path and every tool call as auditable activity.
Should MCP actions require approval?
Read-only actions may be policy-approved after review. Destructive, external, privileged, financial, or data-sharing actions should require explicit approval with exact arguments visible.
Are MCP roots a security boundary?
No. Roots help define intended filesystem scope, but isolation should be enforced with operating-system permissions, sandboxing, path validation, and container or process restrictions.
Sources checked
Last reviewed May 12, 2026. Use these primary sources to verify protocol behavior, platform claims, and security posture before procurement.