MCP Security Assessment: A Practical Test Plan

Sources checked: 11 November 2026. FailSafe Research.

An MCP assessment needs a test plan before it needs individual test cases. The plan names the tools, identities and data boundaries in scope, states what evidence each area produces, and sets the budget and stop rules for the run. The areas below can be covered depending on architecture and agreed scope. The examples use a fictional helpdesk assistant with a ticket search tool, a customer-record lookup tool and a document export tool, running in staging.

What does the plan record before testing starts?

Inventory the deployed agent, its MCP servers, each tool's purpose, and the identity whose credentials the tool uses when it acts. Record versions and owners, and note which components require a third party's permission before active testing. Use the MCP scope worksheet to keep the inventory in one place, and the scope and evidence worksheet for the wider deliverable set: case ledger, findings, remediation and retest.

Who can call which tool, with whose credentials?

Tool authorization has two halves: which caller the runtime authenticates, and which credential the tool server uses downstream. In the fictional example, the ticket search tool answers queries from support staff, while the customer-record lookup runs under a shared service account. The plan records, for each tool, the expected caller group and the credential's permitted scope, then tests an allowed pairing and a denied pairing. The synthetic walkthrough on the MCP security page shows the evidence format: caller, resource owner, expected permission, server decision.

MCP test areas and the evidence each produces

Test area	Question it answers	Evidence to record
Tool authorization	Which caller and credential may use each tool?	Caller group, credential scope, server decision for an allowed and a denied pairing.
Confused deputy	Can untrusted input aim a legitimate permission elsewhere?	Proposed call, named object, server decision, and a working legitimate control.
Tool output handling	Where does tool output travel, and is it labeled external?	Downstream stages reached, labeling state, context telemetry or an inconclusive label.
Secrets and logs	Do credential scopes and telemetry support the other tests?	Token scopes per tool, log coverage of decisions and ingestion, redaction checks.

How do you test a confused-deputy path?

A confused deputy is a legitimate identity tricked into misusing permissions it genuinely holds. In the fictional example, a synthetic ticket filed by an outside reporter contains text asking the assistant to look up a different customer's record. The service account is allowed to read customer records; the question is whether untrusted ticket text can aim that permission at an object the human caller could not request directly. Record the proposed tool call, the named object, the server's decision, and a legitimate control lookup that must keep working. This differs from server-side tool poisoning, where the tool definition itself is altered; that area is covered on the pillar page.

Where does untrusted tool output go?

Tool results become model context, so the plan needs to trace them. For each tool, record whether its output is labeled as external content, which downstream stages receive it, and whether telemetry can show that denied content never entered context. If the deployment lacks context-ingestion telemetry, label the affected conclusion inconclusive rather than passing it. The evidence rules in the NEAR AttackBench assessment article apply here: keep separate labels for a proposed action, an executed action and an observed impact.

What about secrets and logs?

Review the credentials in tool configurations: which service account each tool uses, what scope its token carries, and whether that scope matches the tool's documented purpose. In the fictional example, a document export tool configured with an organization-wide token where a single-workspace token would suffice is a finding worth recording even without an executed misuse. For logging, check that permission decisions, sanitized tool arguments and context ingestion appear in telemetry, and that secrets stay out of those logs. Gaps here turn other findings inconclusive.

What does the retest cover?

After a reviewed fix deploys, repeat the original denied case, the legitimate control and the approved alternate paths on the recorded build. State which variants remain untested. A new tool version or a changed approval rule can invalidate earlier results even when the model version is unchanged.

Teams with a deployed MCP configuration can discuss scope and evidence requirements before scheduling a run. This test plan is a planning aid from FailSafe; the areas included in an engagement depend on the architecture and the agreed scope.