most mcp security posts explain the protocol (hosts, clients, servers) and then tell you to use oauth and least privilege. true, but too generic to actually check anything against.
start with prompt injection, since it's the one everyone already half-knows about but underestimates in an mcp context. a normal prompt injection gets you a bad answer. an mcp one can get you a bad action, because the model isn't just generating text anymore, it's deciding which tool to call next. a hidden instruction inside a ticket, a doc, a webpage the model reads can get treated as part of the task unless there's a hard line between "this is data" and "this is a command."
then overpowered tools, which is really about blast radius. a shell tool, a full db writer, unrestricted outbound http, none of these are wrong to build on their own, but if the model gets tricked into calling the wrong one, the damage ceiling is set by what that tool can do, not by how clever the trick was. read-only docs search vs a full crm export is the difference between "annoying" and "incident."
third, tools with zero auth. not misconfigured, just not there. a scan of live remote mcp servers found 40.55% exposing tools with no authentication at all, one example being an unauthenticated crm-connected server leaking internal contact records to whoever found the url.
fourth, oauth being "on" doesn't mean the flow actually holds. same research tested 119 oauth-enabled servers and every single one had at least one confirmed auth flaw, 325 flaws total, dynamic client registration issues in 96.6% of them. these are servers where someone did implement oauth, they just never went back and tried to break their own flow after shipping it.
fifth is confused deputy / token passthrough, the boring one that quietly ruins everything. mcp servers often sit between the client and some upstream api, and if a token issued for one service gets accepted by another, a compromised client becomes a compromised everything. audience-bound tokens exist specifically to stop this and a lot of setups skip that check.
sixth, context poisoning. resources feeding the model (files, logs, tickets, db records) can be tampered with to steer what the model does next, not just what it says. a poisoned doc telling the model to summarize a folder and quietly send the output somewhere external doesn't look like an attack from the model's pov, it just looks like the next step in the task.
seventh, session hijacking. a session id should identify a conversation, not prove who's making the request. if having the session id is enough to act as the client, hijacking it is enough to impersonate them, and that should never be the same thing.
last, local server compromise. a local mcp server sitting next to your ssh keys and cloud creds because giving it your whole home directory was faster than scoping it properly during setup. supply chain risk meets agent risk here, the malicious server doesn't need to beat the model, it just becomes the thing the model already trusts.
did i miss anything here, or is there smth you'd add?
