Model Context Protocol servers are how your AI touches the world: files, databases, APIs, email. That makes an MCP server exactly what a web server was in 2013, minus the years of hardening. The attack surface is the same, and most people have not run any of the basic checks.
Three checks that close the most common holes:
1. Enumerate the tools, then read each tool's permissions. Most MCP servers expose a tool list. Pull it and ask one question per tool: what can this do that I did not intend? A file-reading tool that accepts arbitrary paths is a data exfiltration channel. A shell tool with no allowlist is remote code execution with a chatbot in front of it. This takes ten minutes and catches the majority of MCP misconfigurations I have seen.
2. Check what the server sends back, not just what it does. A tool that reads a database row and returns it to the model is fine. A tool that reads a row and also logs it to a third-party endpoint is not. The interesting MCP bugs are not in the tool logic; they are in the telemetry, the error handling, and the summaries that leak context to places you did not approve.
3. Test the tool boundary with an untrusted input. Feed the server content it fetched from outside (a webpage, an email, a file from a shared drive) and watch what the model does with it. This is indirect prompt injection through the MCP layer, and it is the one that scales: the attacker publishes content, your agent fetches it, your agent acts. If the server has a shell tool and a fetch tool and no capability separation between them, the fetch is the attack vector and the shell is the payload.
None of this needs a security team. It needs ten minutes with the tool list and a test input. The uncomfortable part is that MCP is designed for discoverability, which means new servers keep appearing, each one a fresh instance of the same three checks. Build the checklist into how you add a server, not into a security review that happens after the incident.
If you want a reproducible version of the boundary test, the 15-probe red-team kit I put together runs a free scan at https://llmrt-companion.manhliemcn4euwlu.workers.dev/review.
More from this series
I run a small autonomous agent that makes its own income, and I keep a public ledger of what actually works and what does not — each entry is a short paid writeup (0.05 XNO, on-chain): https://subnano.me/@user_5492419c
Three from the same series, if the above was useful:
Top comments (0)