MCP Security Testing
Model Context Protocol servers turn model output into real actions and data access. That makes their tools, and the APIs behind them, a live attack surface. This page explains the MCP risk model, the authorization flaws that matter most, and how Operator tests every tool and proves each finding.
Written by Berk Dusunur, Founder & CEO, Planck Proof · Updated September 2026
MCP is an API surface with a new envelope
An MCP server exposes typed tools to an AI application. Each tool reads data or takes an action, usually by calling a backend API. The security question is the same as for any API: is authentication and authorization enforced on every tool and every backend call. Operator treats the server's tool list the way it treats an OpenAPI spec, as the source of truth for what to test.
Real capability, real risk
MCP tools can read records, move money, or change state. A missing check on a tool is not a cosmetic bug, it is unauthorized capability in the hands of whoever drives the agent.
Broad service credentials
Tools often call backend APIs with broad service privileges. If the tool does not scope the caller, that privilege leaks straight through to the caller.
BOLA and BFLA, again
The dominant MCP risks are the same authorization flaws that top the OWASP API list, surfaced through the tool layer instead of raw HTTP.
Authorization at the tool and the API behind it
The critical property is that authorization holds at two layers: the tool invocation itself, and the API the tool calls. A server can gate tools correctly yet call a backend that leaks objects across users, or scope its backend yet expose a tool a caller should never reach. Operator tests both.
It also checks whether a tool exposes more capability than its description implies, since an over-broad tool is an authorization problem waiting to be found. Where product context matters, a human directs the agent at the tools and flows that carry the most risk.
- Tool-level authorization, can a caller invoke a tool they should not.
- Object-level authorization on the API behind each tool.
- Authentication and token handling across the tool boundary.
- Injection into tool parameters that reach backend logic.
- Over-broad tools that expose more than they advertise.
Why generic tooling misses MCP flaws
The same reason scanners miss API authorization applies here, with a protocol layer on top that most tools do not speak.
A successful tool call looks fine
A generic tool sees a tool return a result and treats it as healthy. It has no way to know the result belongs to another user, or that the tool should have been forbidden to the caller.
Detection needs two identities
Proving an MCP authorization flaw requires multiple identities and testing at both the tool and backend layers. Fixed scripts run as one identity against one layer, so the crossing that reveals the flaw never happens.
This is why MCP servers are a natural fit for agentic API penetration testing that reasons about identity across layers.
From tool list to proven findings
Point Operator at your MCP server and provide one credential per role or tenant. The agent enumerates the server's tools and their input schemas, invokes each across identities, and follows the calls into the backend APIs to test object-level authorization. Findings are reported against the specific tool or backend operation, each with reproducible evidence.
Because the run is driven by the declared tool list, it reruns cleanly as tools change, so a flaw introduced by a new tool is caught the week it ships.
- Tool list as the test plan, every tool exercised.
- One credential per role unlocks authorization testing.
- Follows tools into backends to test the API behind them.
- Findings mapped to tools and backend operations.
- Reproducible evidence for every finding.
What a proven MCP finding looks like
A simplified illustration with safe placeholder values. A standard user invokes a tool and reaches another user's record through the backend.
tool: get_customer_record
arguments: { "customer_id": "CUST-3120" }
caller: <standard-user-session>
result: 200 OK
{ "customer_id": "CUST-3120", "owner": "user-B", "ssn_last4": "6677", "balance": 8100.00 }
The caller never owned customer record CUST-3120, yet the tool returned it because the backend API did not scope the object to the caller. The finding ships with the tool call, the result, the baseline showing the record belongs to another user, reproduction steps, and a CVSS v3.1 vector, so the access is reproducible and the fix is verifiable on retest.
Common questions about MCP security testing
What is MCP security testing?
MCP security testing evaluates a Model Context Protocol server, the tools it exposes to an AI agent, and the APIs those tools call. Because MCP tools can read data and take actions on a user's behalf, the security question is whether the server enforces authentication and authorization on every tool and backend call. Operator tests each tool and proves every finding.
Why do MCP servers need penetration testing?
An MCP server turns model output into real actions and data access. If a tool does not check who is calling it, or the API behind it does not enforce object-level authorization, an agent or a user driving the agent can reach data and actions beyond their permission. These are ordinary API authorization flaws exposed through a new surface, often with high impact because tools run with broad privileges.
What flaws does Operator test for in MCP servers?
Operator tests tool-level authorization, object-level authorization on the APIs behind each tool, authentication and token handling, and injection into tool parameters. It also checks whether a tool exposes more capability than its description implies. Each finding is tied to a specific tool or backend operation.
How is MCP testing different from testing a normal API?
The protocol differs, but the risk model does not. An MCP server lists its tools and input schemas, which Operator uses the way it uses an OpenAPI spec. The main additions are the tool invocation layer and the fact that tools often chain into privileged backend APIs, so authorization must be verified at both the tool and the API behind it.
How is each MCP finding proven?
Every finding ships with the exact tool call or request, the response, reproduction steps, and a CVSS v3.1 vector, tied to the specific tool or backend operation. Because the evidence is reproducible, engineers confirm and fix it on the first pass and verify the fix on retest.
Prove whether your MCP tools are safe
Point Operator at your MCP server and it will test every tool and the APIs behind them, then hand you reproducible evidence. See also agentic AI penetration testing and API authorization testing.