The Model Context Protocol gives agents a standard way to call tools, read resources and use prompts. That standardisation is useful, and it also gives every connected server a path into your agent's context. This checklist is the minimum to review before an MCP server reaches production.
For the architecture behind these controls, see MCP Security Mechanisms & Layers and MCP Security for AI Agents. The MCP security hub links the full cluster.
The 12 controls
| # | Control | Why it matters | How to test |
|---|---|---|---|
| 1 | Authenticate every transport | An unauthenticated MCP endpoint is a public tool API. | Call without a token; expect 401. |
| 2 | Per-caller identity | Shared service accounts hide who did what. | Two callers should get different permissions. |
| 3 | Tool allowlist and scopes | New tools should be inert until granted. | Call an ungranted tool; expect denial. |
| 4 | Schema validation | Malformed arguments break tools and can smuggle payloads. | Send wrong types, extra fields and oversized input. |
| 5 | Input screening | Tool arguments can carry prompt injection. | Use the injection test cases from the detection guide. |
| 6 | Output filtering | Tool results can leak secrets or instructions. | Return a canary token; expect it to be blocked or flagged. |
| 7 | Secrets isolation | The agent should never see raw credentials. | Search logs and model context for secret patterns. |
| 8 | Rate limits and quotas | Agents can loop and exhaust resources. | Run a burst; expect 429 and a clear error. |
| 9 | Token budgets | Long tool outputs can blow context and cost. | Send a large response; expect truncation or rejection. |
| 10 | Audit logs | You need to reconstruct what the agent did. | Check caller, tool, args hash, result status and timestamp. |
| 11 | Network isolation and TLS | Servers should not expose internal services. | Scan for open ports and plaintext endpoints. |
| 12 | Versioning and incident response | Tools change; a rollback path is required. | Deploy a breaking change; verify rollback and alerting. |
Three controls teams forget
Tool descriptions are attack surface. A malicious server can hide instructions in a tool description. Treat descriptions as untrusted input and review changes.
Tool results are untrusted input. An MCP server that reads the web can return an injection. Screen results before they enter the model context.
Approval is a control, not a UX detail. Irreversible actions need a human approval step outside the model's reach.
Minimum test suite
- unauthenticated call;
- caller A tries caller B's tool;
- malformed arguments;
- oversized input and output;
- injection in a tool argument;
- injection in a tool result;
- rate-limit burst;
- audit log completeness;
- rollback of a tool version;
- secret scan of logs and context.
FAQ
What is MCP security? The controls around Model Context Protocol servers and clients: authentication, authorization, input/output validation, isolation, rate limits and audit.
Is TLS enough? No. TLS protects transport; it does not stop an authorized caller from invoking a dangerous tool.
Should every tool require approval? No. Reads can be automatic; irreversible writes, sends and deletes should require approval.
How do I test an MCP server? Use the ten tests above, add them to CI, and run them whenever a tool or description changes.
Next step
Turn the table into a review checklist for every new MCP server. Pair it with least privilege for agents and the observability guide.