When I run a fast security pass on an MCP server, the same handful of issues show up again and again. None of them are exotic. They are the kind of thing a busy team ships and forgets.
1. The tool description is the attack surface
An MCP tool's description is fed to the model as instructions. If a server lets a third party influence that text (a fetched page, a record from a shared DB, a webhook body), that text can carry instructions the agent will follow. Treat every tool description and every tool result as untrusted input, not as trusted configuration.
2. Over-broad scopes by default
A server that asks for read-write on everything because it was easier than scoping is a standing liability. Scope each tool to the minimum it needs, and make the scope visible in the tool description so the human approving it can see what they are granting.
3. No allow-list on outbound calls
A tool that can fetch arbitrary URLs is a server-side request forgery primitive. Pin an allow-list. If the tool genuinely needs the open web, say so loudly and rate-limit it.
4. Secrets in tool results
Error messages and debug fields leak tokens constantly. Scan every outbound payload for secret-shaped strings before it leaves the process, and fail closed if the scan errors.
5. No idempotency on state-changing tools
Agents retry. A create-order or send-message tool with no idempotency key will double-fire under normal retry behavior. Require a client-supplied key and dedupe on it.
How I check these fast
I built a 48-hour audit pass that walks an MCP server against exactly this checklist plus a longer internal one, and returns a written report with the concrete fixes. The free live demo shows the format and a sample finding.
Free live demo: https://www.miloantaeus.com/mcp-rugpull-demo.html
Top comments (0)