MCP Security Testing: Authorization, Tool Permissions and Data Exfiltration

MCP security testing should verify every delegation boundary between the user, AI client, MCP server, authorization service, tool and downstream system. A server can implement the protocol correctly and still expose excessive tools, accept over-broad tokens or let untrusted content influence privileged actions.

Map the trust chain

Boundary	Failure to test	Required evidence
User to client	The client misrepresents which action will occur	User intent, displayed approval and exact tool request
Client to server	A token or session is accepted for the wrong audience	Issuer, audience, scopes and server decision
Server to tool	The server exposes a tool beyond the authorized task	Tool allowlist, arguments and policy result
Tool to downstream API	The tool trusts model-supplied object identifiers	Principal, resource ownership and downstream authorization
Content to model	Documents or tool output inject instructions	Content provenance and resulting plan change
Run to audit trail	Investigators cannot reconstruct delegated actions	Correlated identities, approvals, calls and results

Conceptual scope and evidence model for the assessment described above.

Explore Penligent for authorized security testing

Use the MCP specification and its authorization guidance as protocol references, then test the actual deployment. Product-specific proxies, local transports, identity brokers and tool wrappers can create security behavior outside the core specification.

The linked authorization specification addresses HTTP-based transports; it does not prescribe the same OAuth flow for STDIO. For a local STDIO server, assess process identity, inherited environment credentials and the caller’s operating-system permissions. Bind every test to the transport and specification version actually deployed.

Authorization tests

Use a token issued for another resource or audience and confirm rejection.
Remove a required scope and verify that discovery and execution are both constrained.
Change the user or tenant while reusing client state and confirm isolation.
Revoke authorization and verify that cached sessions and long-running tasks stop.
Test redirect and callback handling with pre-registered safe values.
Confirm that the server does not forward a client token to an unrelated downstream service.

Authorization should be evaluated at the resource server and again at the downstream object or action. Tool names and natural-language descriptions are not access controls.

Tool permission tests

Tool class	Risk	Acceptance condition
Read-only search	Cross-tenant or overly broad retrieval	Results are filtered by trusted identity and policy
File access	Path traversal, secret access or unintended workspace scope	Resolved paths remain inside explicit roots
Command execution	Argument injection or privilege inheritance	Allowlisted operations run in isolated, least-privilege contexts
Messaging and tickets	Unapproved external side effects	The exact recipient and content require visible approval
Cloud administration	Broad credentials turn planning mistakes into infrastructure changes	Short-lived task-bound permissions and independent policy checks
Database action	Model-provided identifiers bypass row or tenant controls	Queries are parameterized and authorization is data-aware

Prompt injection and confused-deputy testing

Place synthetic instructions in documents, issue descriptions, web pages and tool output. Observe whether the client changes its plan, requests new tools or attempts to disclose data. The important result is not that the model repeated the text; it is whether an unauthorized resource or action became reachable.

The OWASP LLM Top 10 provides relevant risk categories, but each MCP finding should identify the concrete authority that was misused.

Secrets and local-server risks

Inspect environment variables, configuration files, logs, crash reports, command history and child processes. Confirm that a local MCP server cannot silently inherit unrelated developer credentials. Separate tools into dedicated workers when their permissions differ materially.

Test install and update provenance for servers and dependencies. A convenient one-line installation can introduce a supply-chain and credential boundary that deserves the same review as any other privileged developer tool.

Approval and stop behavior

For state-changing actions, the approval should show the exact operation, target, identity and material arguments. A generic approval to “continue” should not authorize a later email, cloud change or command. Cancel an active run and verify that queued tool calls, subprocesses and callbacks terminate.

Logging requirements

human user and client identity;
MCP server and tool version;
authorization issuer, audience and effective scopes;
tool name, normalized arguments and approval event;
downstream principal, resource and result;
redacted error and policy decisions;
cancellation, timeout and retry behavior.

Engagement acceptance test

Build a synthetic MCP environment with two tenants, a read tool, a state-changing tool and a decoy secret. Seed one excessive-permission condition and one indirect prompt injection. The tester should find the real authorization path, avoid accessing unrelated data, preserve an auditable chain and demonstrate a safe remediation retest.

Defensive acceptance model; validate the stated security property on the corrected deployment.

Explore Penligent for authorized security testing

Make the purchase measurable

MCP is an integration layer, so its security cannot be assessed by protocol parsing alone. Test delegated identity, resource authorization, tool permissions, content provenance, approvals and downstream effects as one chain. AI security teams can apply the same evidence model when evaluating Penligent or another testing provider.

The following Penligent overview introduces a general authorized testing workflow. It does not demonstrate that every assessment capability discussed in this guide is included in a particular product plan.