Quick answer

MCP security acceptance testing checks which identities may use connected tools and what those tools can actually affect. A successful demonstration is insufficient. The system must also reject calls from the wrong identity and enforce removed permissions. This guide provides ten test scenarios that can be included in an assessment scope.

The intended audience is engineering teams building assistants and security teams evaluating integrations. Protocol references are pinned to version 2025-11-25. Record the version implemented by your deployment. HTTP services and local stdio processes have different security boundaries.

Map the authority behind the connection

Separate the user from the agent application. Then identify the MCP server and the downstream service. Finally identify the record or document affected by an action. For each boundary write down which component decides whether the action is permitted.

This map makes an important mismatch visible: a user interface might display only one customer's records while the service account behind it can access every customer. Testing must reach the service enforcing the final operation.

For HTTP authorization the server must validate that the access token was issued for that server. A downstream service needs its own appropriate authorization flow. Local processes also require operating system controls over files and network access. See the versioned MCP authorization specification.

Prepare an inventory that supports testing

For every tool record its name and version. Identify the data it reads and the objects it changes. Record its service identity and allowed network destinations. Mark sensitive fields separately. A screenshot of the tool menu is not an inventory of effective permissions.

A support assistant may need order lookup without needing refund creation. Start with the business requirement and remove unnecessary functions. This reduces both assessment complexity and the consequences of an incorrect call.

Descriptions and annotations from an untrusted tool server are not enforcement mechanisms. A tool advertised as read only should be tested against a controlled attempt to change state. The MCP tools specification explains the trust limitations of tool annotations.

Ten proposed acceptance cases

The following is an original DSET worksheet for this guide. It is not an official certification scheme. Run the cases within written authorization using synthetic identities and data.

No Test condition Acceptance criterion Evidence
1 Protected call without credentials No operation or protected data access Request identifier and denial
2 Test token issued for another service Incorrect audience rejected Audience validation result
3 Write call with a reading role Backend state unchanged Before and after comparison
4 Synthetic cross customer object selection Customer boundary enforced Results for both identities
5 Existing session after permission removal Access ends according to the defined policy Revocation and last acceptance times
6 Test instruction inside a tool description Description grants no new authority Tool version and policy decision
7 Discovery points outside the approved network scope Destination blocked Network policy evidence
8 Local tool accesses an unrelated test file Operating system boundary holds Process identity and denial
9 Parameters change after approval Previous approval cannot authorize the changed action Approved and executed summaries
10 Error handling and tracing No credentials appear in logs Redacted error sample

Download the MCP acceptance worksheet. It includes blank fields for the owner and result. An untested row must not be reported as a pass.

A fictional support workflow

An assistant reads a synthetic ticket for customer A. The ticket contains text requesting an unrelated action. The assistant then proposes calling an invoice tool for customer B. This is a teaching example rather than a DSET client case.

There are two observations to record. Did the model follow the untrusted instruction? Did the downstream service permit access to the other customer's invoice? A sound authorization boundary should still reject the second action when the model makes a poor decision. Success at one layer does not remove the need to inspect the other.

Protocol security also includes sessions and destination discovery. These boundaries cannot be assessed solely through a chat transcript. See MCP security best practices.

Decide whether the deployment is ready

Use pass and fail and insufficient evidence as distinct results. An average score should not hide a broken customer boundary. Mark a case as not applicable only with a reason tied to the architecture. The absence of a local process may exclude the local file case. An unexamined token validator is not equivalent to a pass.

After a fix repeat the denied operation and a legitimate neighboring workflow. A control should block unauthorized behavior while preserving the required authorized action. Define which changes trigger reassessment. Adding a new tool or expanding a service account can invalidate earlier conclusions.

The delivery package should include the tool inventory and the identity flow. Findings should identify the affected version. Request identifiers and timestamps should permit reconstruction. Store remediation ownership and retest evidence alongside each finding. Do not include raw credentials in the report.

Frequently asked questions

Does an offline MCP server need assessment?

Yes. A local process may still read confidential files or reach internal services. Adapt the scope to its actual capabilities.

Does OAuth solve every permission problem?

No. Object and action authorization still matter after authentication. A valid session is not permission to access every customer.

Are reading tools harmless?

No. Reading another customer's document can disclose sensitive information. Test customer separation and the necessity of returned fields.

How long does an assessment remain valid?

There is no universal duration. Record the evaluated version and changes that require retesting.

Scope an assessment with DSET

A tool inventory and two example user roles are useful starting inputs for DSET cybersecurity assessment scoping. The KAOS product overview provides additional technical context. This guide makes no claim that the proposed tests have already been performed on a client system.

Continue with transaction bound agent approval and RAG customer isolation testing.

Editorial note: The worksheet is an original proposal for this DSET Engineering Team guide. Sources were checked on 11 October 2026. Revalidate protocol and deployment assumptions when performing an assessment.