MCP Servers Need Their Own Threat Model
Treating an MCP server like a REST API during a pentest misses the failure modes that actually matter: tool-selection abuse, over-broad tool scopes, and cross-tool data leakage.
Model Context Protocol servers look like ordinary backends from the outside — an endpoint, some auth, a handful of typed operations. Most security programs test them exactly like that, and it's not enough.
Three failure modes classic API testing misses
Tool-selection abuse. The agent, not a human, decides which tool to call and with what arguments, based on model reasoning over untrusted input. An attacker doesn't need to break your auth if they can convince the calling agent to invoke a destructive tool it technically has permission to call, just not for that purpose.
Over-broad tool scopes. MCP tools are frequently granted the same credentials the whole backend service has, because scoping them individually is extra work. That turns "read customer's own order history" into "read any customer's order history" the moment a tool's input isn't properly bound to the calling user's identity.
Cross-tool data leakage. A single agent session often has several tools available at once. Data pulled by one tool call can end up as context for the next, including tools that were never meant to see it — a quiet form of the confused deputy problem that doesn't show up in a tool-by-tool audit.
What we test for
Oxyne's MCP testing enumerates every tool a server exposes, fingerprints its actual scope against what it should be authorized for, and runs adversarial sessions designed to trigger each of the three failure modes above — not just malformed-input fuzzing against individual tool schemas. Findings get scored and chained into the same attack-path graph as the rest of your systems, so a low-severity tool-scope issue that combines with a web-side IDOR shows up as the real, higher-severity path it actually represents.
See the full methodology on the MCP Servers solution page.