An MCP server security checklist helps teams decide whether a server is safe enough to connect to an AI agent, coding assistant, internal workflow, or production automation. The risk is not only the server package itself. The real risk is the authority the server gives to an agent: reading files, calling APIs, changing records, sending messages, running commands, or exposing private context.
Use this checklist before adding a new MCP server to Claude, Cursor, Codex, a support agent, or an internal operations workflow. It turns security review into a repeatable launch process: define the job, restrict permissions, protect credentials, test prompt injection, add approval gates, and keep evidence for future reviews.
Pair this checklist with the Agent Security Guide at /guides/agent-security-guide/, the Agent Permission Builder at /tools/agent-permission-builder/, the Permission Builder guide at /guides/agent-permission-builder/, and the MCP Security Checklist Generator at /tools/mcp-security-checklist-generator/.
Key takeaways
- Review an MCP server by the actions it enables, not only by its README or popularity.
- Treat prompt injection as a permission problem whenever untrusted content can influence tool calls.
- Keep a launch record with allowed scopes, denied scopes, credential handling, approval gates, tests, and owners.
Check credentials and least-privilege scopes
Credentials should be scoped to the smallest useful permission set. An MCP server that reads GitHub issues should not receive a token that can delete repositories. A database MCP server used for reporting should not have broad write access. If the server only needs public data, avoid private credentials entirely.
Never paste secrets into prompts, logs, generated reports, or long-term memory. Store them in the platform secret manager or local environment and reference the storage mechanism without exposing the value. Rotate credentials when server scope changes or when a review finds a risky permission.
- Use read-only tokens for first launches whenever possible.
- Restrict filesystem paths, database tables, API endpoints, and network destinations.
- Keep secrets out of model context and audit reports; write [REDACTED] instead.
- Record the credential owner and next review trigger.
Test prompt injection and untrusted content paths
MCP servers often connect agents to untrusted content: web pages, tickets, issues, docs, files, emails, or user-submitted data. A malicious instruction inside that content should not be able to override the user, change permissions, reveal secrets, or cause unrelated tool calls.
A practical test set should include benign tasks, malicious instructions, ambiguous authority, missing permissions, and tool failures. The Agent Security Guide explains the broader threat model; this checklist turns it into a launch gate for each MCP server connection.
- Verify tool outputs are treated as data, not authority.
- Test pages or files that ask the agent to reveal secrets or ignore policy.
- Test cross-customer or cross-project data boundaries.
- Confirm the agent refuses or asks for approval when scope is unclear.
Add monitoring, rollback, and review evidence
Security review is not finished at launch. Production MCP workflows need logs that show which server ran, which tool was called, what input summary was used, whether approval happened, and what the result was. Logs should be useful for incident response without storing raw secrets or unnecessary private data.
Keep a short review artifact for each server. It should include the reason the server exists, approved scopes, blocked scopes, tests passed, known limitations, owner, and next review date. The Agent Permission Builder can generate a starting policy, while Pro reports can turn that policy into reusable acceptance evidence.
- Log tool name, caller, environment, approval status, and safe input/output summaries.
- Keep a kill switch for high-risk servers and scheduled agents.
- Review scopes after adding tools, changing credentials, or moving to production.
- Link evidence to the workflow pack or launch checklist that uses the server.
Implementation checklist
- Define the MCP server's workflow, owner, environment, and user-facing job.
- List enabled tools and classify them by read, write, external, destructive, production, financial, and memory impact.
- Restrict credentials, filesystem paths, API scopes, network destinations, and data access to least privilege.
- Test prompt injection, ambiguous authority, approval bypass, missing permissions, and tool failure before launch.
- Record approval gates, monitoring signals, rollback steps, known risks, and next review date.
FAQ
What is an MCP server security checklist?
It is a repeatable review process for deciding whether an MCP server has safe tool scope, credentials, approvals, monitoring, and prompt-injection defenses before an agent uses it.
Is an MCP server safe if it is popular?
Popularity is not enough. You still need to review the actions it enables, the credentials it receives, the data it can access, and the workflow where it will run.
Should MCP tools be read-only by default?
For first launches and public demos, read-only or draft-only tools are usually safer. Add write and external actions only with clear approval gates and rollback steps.
How does the Agent Permission Builder help?
It turns the workflow, tools, data, and autonomy level into a permission policy with risk level, allowed scopes, approval gates, and default-deny rules.