Model Context Protocol is becoming a default way to connect AI agents with tools, files, APIs, developer environments, and internal systems. That is useful, but it changes the security model. A tool description is no longer just documentation. A tool parameter is no longer just a form field. A local server is no longer just a developer convenience. In an agent workflow, each of those pieces can influence what the model decides to do next.
This checklist is for teams that want the benefit of MCP without treating every server, tool descriptor, and tool output as automatically safe. It is written for product builders, security reviewers, engineering leads, and founders who need a practical launch review rather than a theoretical protocol debate.
1. Inventory every MCP server
Start with a plain list. Which MCP servers are allowed? Who owns each server? Where does it run? Which agent or client can connect to it? What tools does it expose? Which data sources does it read? Which systems can it modify? If the team cannot answer those questions, it is too early to treat the integration as production-ready.
The inventory should include local developer servers, hosted vendor servers, experimental internal servers, and servers installed through templates or marketplaces. Shadow MCP servers are especially risky because they can quietly add tool capabilities that security and product teams never reviewed.
2. Review tool descriptions as attack surface
MCP tool poisoning is dangerous because malicious instructions can live inside tool metadata. The model may see a tool description that the user never reads. If that description tells the model to ignore prior instructions, hide a parameter, call another tool, or exfiltrate context, the attack is not obvious in the normal user interface.
Teams should review tool names, descriptions, schemas, examples, parameter labels, and error messages. Treat them like code comments that can execute socially through the model. Descriptions should be short, factual, and free of behavioral instructions that are not part of the tool contract.
3. Require descriptor integrity
A tool can be safe during review and unsafe later if its descriptor changes. This is the rug-pull version of MCP risk. A server may expose the same tool name while altering its description, parameter schema, endpoint behavior, or downstream target.
At minimum, record a descriptor hash at approval time and alert when it changes. Stronger programs can use signed manifests, pinned versions, deployment approvals, and automated diff review. The important point is that a tool descriptor should not silently drift after trust has been granted.
4. Separate read tools from write tools
Read-only tools and write-capable tools need different treatment. Searching documentation, listing available projects, or reading a ticket is not the same as sending an email, editing a file, creating a pull request, changing a customer record, issuing a refund, or running a command.
Give each tool a risk tier. A low-risk read tool can be available by default. A high-risk write tool should require policy checks, user approval, or a separate service account. Do not combine broad read access with broad external communication in the same agent unless there is a strong reason and strong monitoring.
5. Make parameters visible before approval
User approval is weak if the user cannot see the actual arguments the agent is about to send. A prompt such as “allow tool call” is not enough. The approval screen should show the tool name, destination, record identifiers, file paths, command text, external URL, payload summary, and whether the action is reversible.
This matters because several MCP risks depend on hidden or confusing parameters. If the agent is about to upload a file, the user should see the path. If it is about to call a CRM tool, the user should see the customer record. If it is about to run a shell command, the exact command should be visible and copyable.
6. Do not trust tool output as instruction
Tool output is often untrusted content. A search result, document, ticket, repository file, web page, or API response may contain instructions that target the agent. The agent should not treat that output as a new system instruction or developer command.
Good implementations label tool output as data, preserve source identity, and prevent retrieved text from changing tool permissions or goals. This is especially important when an agent reads public web pages, third-party issue trackers, shared folders, customer uploads, or external knowledge bases.
7. Limit local machine access
MCP is often used in developer workflows where the agent can inspect files, run tests, install packages, or execute commands. That is powerful and risky. A malicious README, markdown troubleshooting note, package script, or repository issue can steer a helpful coding agent toward unsafe actions.
Run coding agents in a sandbox where possible. Restrict file paths, protect secrets, avoid mounting home directories, require explicit approval for shell execution, and limit network access during untrusted repository analysis. Treat unfamiliar repositories as hostile until reviewed.
8. Control outbound communication
Data exfiltration often requires a destination. If an agent can read sensitive data and also send arbitrary HTTP requests, email messages, chat messages, or file uploads, the blast radius grows quickly. Outbound controls are one of the most practical ways to reduce MCP risk.
Use allowlists for external domains, block unknown webhooks, restrict file uploads, and log outbound requests. For internal tools, make sure service accounts cannot send data to destinations they do not need. Cost monitoring and unusual network patterns should be treated as security signals.
9. Keep MCP servers least-privileged
An MCP server should not run with broad production credentials just because it is convenient. Give it the smallest data scope and action scope that supports the workflow. Use separate service accounts for development, staging, and production. Rotate keys and remove tools that are no longer used.
Least privilege also applies to the agent client. If one workflow only needs ticket summarization, it should not inherit tools for database writes, terminal commands, customer refunds, or source-code changes.
10. Log the full decision path
When something goes wrong, the team needs to reconstruct the agent’s path. What user request started the run? Which tools were available? Which tool descriptions did the model see? Which tool outputs were returned? Which tool calls were proposed, approved, rejected, or executed?
Log prompts, retrieved sources, tool metadata versions, parameters, approvals, outputs, errors, retries, latency, and cost. Do not log secrets in plain text, but do preserve enough evidence for incident response and regression testing.
11. Test realistic attack cases
Do not only test happy paths. Build a small regression suite with poisoned tool descriptions, malicious web pages, hostile markdown files, confusing parameter names, lookalike tools, oversized outputs, and attempts to combine read tools with outbound communication tools.
The test should answer a practical question: can the agent be persuaded to reveal private data, call the wrong tool, hide arguments from the user, execute a command, or trust untrusted content as instruction? If yes, the release needs more controls.
12. Define a rollback plan
MCP incidents are easier to contain when the team knows how to disable a tool quickly. The rollout plan should include a kill switch, server allowlist changes, credential rotation, cache invalidation, logging export, customer communication ownership, and a clear path to restore safe operation.
Do not wait for an incident to decide who can revoke an MCP server. The owner, escalation path, and rollback command should be known before launch.
Practical launch rule
If an MCP-connected AI agent can read private data, call tools, run code, or communicate externally, it needs a security review before production. The review does not have to be slow, but it must be explicit: inventory, permissions, descriptor integrity, approval visibility, sandboxing, outbound controls, logs, tests, and rollback.
References
- OWASP Top 10 for Large Language Model Applications
- Model Context Protocol threat modeling and tool poisoning research
- Security analysis of MCP and prompt injection vulnerabilities
- AI-assisted development tools and prompt injection research
- AI Agent Security Hotwords in 2026
For a broader launch review, use the AI Agent Readiness Self-Assessment or the AI Agent Tool Risk Register Template.