Topic 2: The threat model
Why MCP is not just another API
You already secure APIs. You validate input, you check auth, you rate-limit. All of that still applies to an MCP server, because an MCP server is an API. But MCP adds something an ordinary API does not have: a language model sits in the loop, and the model reads text supplied by the server and then decides what to do next.
Think about the trust you place in text at each layer of a normal web app. A browser treats a page's text as data to display, never as code to run (that separation is exactly what stops most injection). An API client treats a JSON response as values to parse. Neither one reads the response and then decides, on its own, to call another endpoint because the response told it to.
An MCP host does exactly that. The model reads:
- tool descriptions, to decide which tool fits the user's request,
- tool results, to decide what to do next,
- resource contents, which may be arbitrary files or web pages,
and all three are attacker-influenced surfaces. A tool description is written by whoever wrote the server. A tool result or a resource may contain text that came from the open internet, an email, or a shared document. The model does not have a hard wall between "instructions from my operator" and "data I am processing." That missing wall is the extra attack surface.
Here is the uncomfortable core of it. In a classic injection (SQL, XSS) the attacker smuggles code into a data channel. In MCP the "code" is natural language, the "interpreter" is a language model, and the model was built to follow natural language. There is no parser you can harden to zero. You cannot fully sanitize your way out, because the payload is indistinguishable from a legitimate instruction. So the defences in this module are not "block the bad string." They are structural: limit what any tool can do, require a human for anything irreversible or outbound, pin what you approved so it cannot change under you, and put a choke point in front where you can see and stop calls.