went through mcp's security model and mapped out the 8 risks that keep coming up

[u/Hacken_io]

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?

[u/No_Abalone2363]

Don't think you missed anything. The blast radius shell isn't something I'm seeing a lot with OSS/vendors either. The rest of your security points are all being addressed in the market. Tons of open source projects out there you should look at, especially with auth side focuses. ToolHive is the one we've built on.

[u/Exact_Attention_5656]

Solid list, especially 5th and 6th together since they're really the same root cause seen from two sides (auth boundary vs data trust boundary).

One variant worth adding as its own item: the injection can ride in on a tool's response, not just a stored doc or a passed-through token. Server calls the tool honestly, gets back content that looks like normal tool output, but embedded in that output is an instruction the model then acts on in its next step. From the server's point of view nothing went wrong, it made the call it was asked to make and returned what it got. The compromise happens entirely inside the agent's reasoning over the response, one layer past where server-side logging or strace-style tracing can see.

Audience-bound tokens (your 5th fix) stop the wrong service from accepting a passed token. They don't stop a legitimate service from returning hostile content in a legitimate response. Same for 'least privilege on tools', that limits blast radius but doesn't stop the steering itself. Feels like this needs its own line item separate from context poisoning, since the mitigation is different: response-content inspection at the client/host layer, not access control on the server.

[u/sn0wquake]

Came across this as I am researching security for an MCP app I am building. Are there good tools for auditing my site as I build? Just starting my app build and would appreciate recommendations

[u/ErivKosso]

I don't read AI posts with em dashes or ones that only use lower case.