MCP server security testing

MCP server security testing: why buyers commission it now

If your organization is launching a Model Context Protocol (MCP) server, or a customer questionnaire, an insurer or an internal policy now asks for evidence that an MCP server or client is safe to connect to enterprise identity and data, this test provides that evidence. It checks how the server handles authorization, tokens, OAuth discovery, sessions, tool scopes and local execution against the MCP security best practices, and it delivers a written report with reproducible findings, risk ratings and retest guidance that your security team and assessors can use. Scope is agreed in writing before work starts, so you know exactly which servers, clients, identity providers and environments are covered.

MCP servers create trust boundaries that older web and API tests do not fully cover. The server sits between a language model and your systems, so it holds or brokers OAuth tokens, discovers authorization endpoints at runtime, decides which tools an agent may call, and in local deployments runs as a process on a user's machine. Each of these is a place where a mistake grants more access than intended. The MCP guidance names several of these risks directly, including confused deputy attacks on proxy servers, token passthrough, server-side request forgery during OAuth discovery, session hijacking and local server compromise. The OWASP Top 10 for Agentic Applications 2026 (ASI02 Tool Misuse and ASI03 Identity and Privilege Abuse) and the OWASP Top 10 for LLM Applications 2026 (LLM03 Excessive Agency) describe the same pressure from a risk perspective, and MITRE ATLAS gives testers a shared technique vocabulary for mapping results.

Before you commission a test, confirm three things with the provider: which MCP protocol version the server targets (the current reference for this test is the 2025-11-25 version of the MCP security best practices), which tools and token audiences the server exposes, and whether any local servers are distributed to end users. Those answers shape the test plan, the evidence your auditor or customer will see, and whether a retest is needed after fixes. Ask for a written statement of which controls were tested, which were reviewed by configuration only, and which were out of scope.

Which MCP weakness categories the test examines

This table compares the MCP weakness categories covered by the MCP security best practices (protocol version 2025-11-25), showing what each looks like in a deployment, why it matters, and what the tester checks. Read each row as a test area to confirm in scope, and note how agent goal hijack and tool misuse connect to the OWASP agentic list.

Weakness category	What it looks like in an MCP deployment	Why it matters and what the tester checks
Confused deputy on proxy servers	An MCP proxy calls third-party APIs with a static client identifier, so a user's consent for one client can be reused by another client without fresh approval.	Shows whether a user's consent is tied to the correct client and whether the proxy checks client identity before forwarding requests to upstream services.
Token passthrough	The MCP server accepts a token that was issued for another service and forwards it to downstream APIs instead of using a token issued for itself.	The specification forbids this pattern. Testers check that the server rejects tokens not explicitly issued for it and that audience values are validated on every request.
SSRF during OAuth discovery	The server fetches URLs supplied during metadata or authorization discovery, which can point at internal addresses or cloud metadata endpoints.	Testers review how the server validates and restricts outbound destinations during discovery and whether internal network reach is limited by design.
Authorization URL validation	The client or server follows authorization endpoints without checking scheme, host or redirect targets against an allowlist.	Testers check that authorization URLs are validated before use, that redirects are constrained, and that the user sees where they are being sent before approving.
Session hijacking	Session identifiers are predictable, reused across users, or accepted without binding to the authenticated principal.	Testers review session generation, expiry, rotation and binding, and confirm that a session identifier alone is not treated as proof of identity.
Local server compromise	A local MCP server is installed through one-click configuration and runs with the user's full privileges, or the client hides the command it executes.	The guidance requires the client to show the exact command and obtain explicit approval, and to run servers sandboxed with minimal default privileges. Testers confirm these controls exist and hold.
Scope minimization and tool misuse	Tokens carry broad scopes such as full mailbox or repository access, and tools can be invoked beyond the task the user asked for. This maps to OWASP ASI02 Tool Misuse.	Testers check that scopes match each tool's purpose and that agent goal hijack (ASI01) through manipulated tool descriptions or outputs is covered in the same test.

How MCP server security testing runs, phase by phase

The sequence moves from agreed scope and design review to controlled testing, evidence-backed reporting and retesting, so each finding is tied to a named server, client or control and the fix can be verified.

Agree scope, accounts and roles in writing
Before any testing, DeployOpen and the client record which MCP servers are in scope, whether each is remote or local, which MCP clients connect to them, which identity providers and resource APIs sit behind them, and which test accounts hold which roles. The client confirms the environment, including whether a non-production copy is available, and the rules of engagement cover permitted hours, traffic limits, data handling and who to contact if something breaks. The step is complete when the signed scope names every server, client, account and boundary, and the client has confirmed which environment testing will use. Ask for the rules of engagement to be part of the written scope rather than a separate informal note.
Review authorization design and token handling
Before live testing, the team reads the design documents, configuration and code paths that govern how the server validates tokens, checks token audience, handles OAuth authorization URLs and discovery metadata, and decides which scopes it grants. This is a desk review, so no exploitation happens yet. The output is a list of design questions and suspected gaps, each mapped to a section of the MCP security best practices, such as token passthrough, confused deputy risks in proxy servers, and scope minimization. The step is done when the client has answered those questions and the test plan lists which categories will be exercised on which components.
Build the test plan by weakness category
The team turns the design review into a test plan organized by weakness category: authorization and audience checks, token passthrough, confused deputy behavior, server-side request forgery during OAuth discovery, session handling, scope design and local server sandboxing. For each category the plan states the objective, the component under test, the expected secure behavior and the evidence that would show a control holding or failing. The client approves the plan so that the test window, test identities and any unsafe actions are agreed in advance. The step closes when the plan is signed off and every in-scope server and client appears under at least one category.
Run controlled tests against each category
Testers exercise each category against the agreed environment, starting with the lowest-impact checks and escalating only within what the rules of engagement allow. Work covers how the server responds to tokens issued for other resources, whether it forwards client tokens upstream, whether it fetches URLs it should not reach during discovery, whether sessions can be bound to the wrong user, and how local servers start and what privileges they receive. Testers record each request, response and configuration state with timestamps. The step is complete when every planned check has a result of held, failed or not testable, and any unplanned impact has been reported to the client's named contact.
Triage findings and confirm severity
Each candidate finding is reproduced by a second tester where practical, checked against the environment's configuration and classified by impact on the client's data and systems. Duplicates and results caused by test-environment artifacts are removed. The team also notes controls that held, because clients and auditors need to see tested areas that passed as well as failures. The step is done when every finding has a reproduction path, a severity rationale and an owner on the client side.
Deliver the report with reproducible evidence
The report describes each finding, the affected server or client, the category it falls under, the evidence that reproduces it and a recommended fix with its trade-offs. Evidence is written so that the client's engineers can rerun the check in their own non-production environment without the tester present. The report also states scope, dates, test accounts used by role, limitations and any areas that were not tested. The client receives a findings register that can feed a remediation tracker. The step is complete when the client acknowledges receipt and the report has been reviewed in a readout with the engineers who will apply the fixes.
Retest the fixes and close findings
After the client applies remediation, DeployOpen repeats the original reproduction steps against the changed configuration and checks that the fix does not break the intended behavior, such as legitimate token flows or approved scopes. Each finding is marked closed, partly fixed or still open, with the retest evidence attached. Retests are scoped in writing like the original test. The step is done when every in-scope finding has a retest outcome and the closed items are recorded with their evidence, which the client can use in a customer or compliance response.

Which MCP servers and clients can be in scope

Scope for an MCP engagement depends less on the protocol than on where each server runs, what it can reach and who it serves. The decisions below change which controls are tested, which accounts and environments are used and what evidence the report can support, so each one should be settled in writing before testing starts.

Remote servers using OAuth

A remote MCP server that delegates sign-in to an authorization server is tested for token audience, token handling and how it discovers and validates authorization endpoints. The test checks that the server accepts only tokens issued for it and does not forward client tokens to downstream services, which the MCP security best practices forbid through token passthrough. Confirm in writing which authorization server, client registrations and test identities are in scope.

Local servers on user machines

Local servers run as processes on developer or employee laptops, often with access to files, shells and credentials. The test covers how the server is launched, what privileges it inherits, whether it is sandboxed with minimal default rights and whether it can be reached by other local processes or web pages. Confirm the operating systems, device images, and whether testing includes managed endpoints or only a lab build.

Clients with one-click configuration

Clients and hosts that install servers from a one-click link or a shared configuration file introduce a supply chain and consent problem. The test checks whether the client shows the exact command it will execute and requires explicit user approval before running it, as the MCP guidance describes. Confirm which client versions, install paths and configuration sources are included, and whether the test covers the approval dialog itself.

Downstream APIs and data stores

Each server is only as limited as the systems it reaches. A server that wraps a ticketing API, a database or a cloud control plane can turn a single tool call into broad data access or changes. The test maps every backend, the credentials the server holds and the actions each tool can perform, then checks whether those permissions match scope minimization. Confirm which backends are in scope and whether test accounts with production-like data are available.

Server-side fetches and discovery paths

Servers that fetch metadata URLs, redirect targets or user-supplied resources can be pushed into requests toward internal addresses, which is the server-side request forgery risk named in the MCP guidance. The test checks which outbound destinations the server can reach and how it validates URLs during OAuth discovery. Confirm the network segments the server can see, and whether internal ranges and cloud metadata endpoints may be probed in a controlled way.

Roles and tenants for isolation

Multi-tenant or multi-role deployments need isolation testing, not only single-user checks. The test compares what one tenant, role or session can read and invoke against what another can, and checks that sessions cannot be reused across users. Confirm the number of tenants, roles and test accounts provided, and who approves cross-tenant test traffic before it starts.

How testing differs for remote servers, local servers and clients

Remote MCP servers are reached over HTTP, usually behind an authorization server, and they serve many users at once. Testing focuses on whether the server verifies who is calling and whether it accepts only tokens meant for it. The MCP security best practices explicitly forbid token passthrough, so a server must not accept tokens that were not issued for that server. Testers also check the OAuth discovery path, because metadata fetching can be abused to make the server request internal addresses.

Token audience and passthrough: Tests confirm the server rejects tokens issued for other resources and does not forward client tokens to downstream APIs.
Authorization URL validation: Tests check how the server and client validate authorization server metadata and redirect targets during OAuth discovery.
SSRF during metadata discovery: Tests check whether user-influenced URLs can reach internal networks or cloud metadata endpoints.
Session handling: Tests check session identifier entropy, binding to the authenticated user, expiry and resistance to session hijacking.
Scope design: Tests check whether tool scopes follow least privilege and whether high-impact tools require stronger authorization.

The report should show, for each control, the request sequence tested at a defensive level, the observed response, and the configuration change recommended. Ask the provider which MCP protocol version the assessment references.

What MCP server security testing costs and what drives it

This table compares the factors that change the effort behind an MCP security test, with a note on what each one means for scope and quote. Read it before you request a quote, because most of the price difference between two engagements comes from these choices rather than from the report. DeployOpen does not publish a price list, and a quote follows from written scope.

Cost driver	Why it changes effort	How to keep scope efficient
Number of MCP servers and clients	Each server has its own tool surface, configuration and authorization logic, and each client handles approval, token storage and session state differently.	List every server and client in the inventory, and mark which are in production, which are internal only and which are retired.
Remote versus local deployment	Remote servers bring OAuth discovery, token audience checks and SSRF exposure. Local servers bring sandboxing, one-click install flows and the exact command shown to the user.	Group servers by deployment model so each group gets one shared test approach with server-specific checks.
OAuth flows and identity providers	Each identity provider and grant flow adds authorization URL validation, redirect handling and token lifetime checks to the test plan.	Confirm which flows are live and which are disabled, and which identity provider tenants the test may use.
Number of tools and scopes	Every tool and scope needs a permission check against scope minimization, and tools that act on downstream systems need deeper review.	Ask for a scope table per server that shows each tool, its scope and its write or delete capability.
Roles and tenants to test for isolation	Testing whether one user or tenant can reach another's data requires test accounts for each role and tenant pair, which adds setup and verification work.	Limit isolation testing to the tenant boundaries that carry real risk, and state the number of roles in the written scope.
Downstream systems reached	Servers that call databases, SaaS APIs or internal services expose token passthrough and confused deputy paths that must be traced end to end.	Name each downstream system and whether the test may send traffic to it or only review its configuration.
Environments provided	A test needs a staging or sandbox copy with realistic configuration. Testing against production adds coordination, change control and monitoring steps.	Ask the client to provide a non-production environment with test identities and seeded data where possible.
Depth of source review	Reviewing server code for token handling, session identifiers and outbound request logic takes more time than black-box testing alone.	Decide in advance whether source access covers all servers or only the highest-risk ones.
Retest and recurring work	Retests check that fixes hold after changes. Continuous testing and retainers add recurring effort after the initial assessment and report.	Agree the retest window and the number of retest rounds in the written scope, and ask which parts recur under a retainer.

Which frameworks ask for AI and agent security testing

Several frameworks now expect evidence that AI systems were tested for exploitable weaknesses. None of them names MCP servers directly, so the card below explains what each one asks for and where MCP testing fits. Read the cards as a map to confirm with your auditor, not as a compliance determination.

EU AI Act resilience duties

Article 15(5) requires high-risk AI systems to be resilient against attempts to exploit vulnerabilities, including data poisoning, adversarial examples, model evasion and confidentiality attacks. Article 55(1) requires providers of general-purpose AI models with systemic risk to perform documented adversarial testing. For an MCP server, test the tool surface, token handling and session behavior that an attacker could use to reach the model or its data. Confirm with counsel whether your system is high-risk and whether you are a provider of such a model at all.

NIST AI 600-1 trustworthiness

NIST AI 600-1 is the Generative AI Profile of the AI Risk Management Framework, published on 26 July 2024 for voluntary use. It helps organizations build trustworthiness into the design, development, use and evaluation of generative AI. For MCP, it supports scoping tests around tools that act for users and reviewing how the server's outputs are trusted by the model. It is voluntary, so ask your auditor whether they expect it to be cited as the basis for your controls.

NIST AI 100-2 adversarial machine learning

NIST AI 100-2 E2025 is a taxonomy and terminology of attacks and mitigations against AI systems, covering evasion, poisoning and privacy attacks on predictive and generative models. It gives a shared vocabulary for test reports, so findings map to recognized attack classes. For MCP servers, use it to label tests of injected instructions in tool outputs and of data exposed through tool responses. Ask your testing provider to map each finding to the taxonomy's categories.

HITRUST agentic AI factor

HITRUST CSF v11.9.0 added an Agentic AI selectable factor to the HITRUST AI Security Certification, with a mapping to the OWASP Top 10 for Agentic Applications 2026. Agentic factors look at systems that take actions on a user's behalf, which describes most MCP deployments. Testing MCP servers against the agentic risks, including identity and privilege abuse and tool misuse, produces evidence for that mapping. Confirm with your HITRUST assessor which factors apply and which evidence they will accept.

OWASP agentic risk mapping

The OWASP Top 10 for Agentic Applications 2026 lists ASI02 Tool Misuse and ASI03 Identity and Privilege Abuse, which are the risks most tied to MCP servers. Many auditors and customer questionnaires now ask which of these items were tested and how. Map each MCP test case to an ASI identifier so the report answers that question directly. Ask the provider to show this mapping in the sample report before you commission the work.

What your team prepares before the MCP test starts

The most useful thing your team can do before an MCP test is put the scope in writing. Name each MCP server and each MCP client in the test, including local servers that developers run on laptops, and state which authorization server, resource endpoints and downstream APIs each one calls. Provide test accounts for every role and every tenant that the test should exercise, so testers can check whether one tenant's token or session can reach another tenant's data. Register OAuth clients for test use, with redirect URIs that point only at test endpoints, and confirm the scopes each client may request. Where your authorization server supports it, separate these registrations from production clients so that a test cannot be mistaken for real traffic. Non-production endpoints and sandbox data for every downstream API the MCP servers call should be ready before kickoff, because testing token audience, token passthrough and server-side request forgery during OAuth discovery usually requires calls that you would not want to make against live customer records. Also provide a network allowlist for the tester source addresses, and confirm which environments are reachable from them.

Agree on stop conditions and named contacts before the first session. Stop conditions should cover, at minimum, any sign that a test is reaching production data, any impact on a service that other customers depend on, and any unexpected change to a session, token or refresh flow outside the test accounts. For each condition, name a technical contact who can halt traffic and a business contact who can make the decision to continue. Confirm how the testers reach these people out of hours. Ask your provider to confirm in writing how it will pause and resume testing, and whether it will stop immediately or finish the current check. Decide, with your provider, whether session hijacking and token replay checks should run only against accounts you can revoke quickly.

Plan the change and notice side of the test with the same care as the technical side. Ask your team to freeze changes to the MCP servers, the authorization server and the downstream APIs for the test window, or to record any change made during it. Notify the identity team in advance, because the test will generate failed logins, token issuance, consent prompts and revocations that they may otherwise investigate as an incident. Tell the owners of each downstream API the dates, the source addresses and the rate limits the testers have been given, so they can distinguish test traffic from abuse. Agree how logs and monitoring are informed, including a time-bound suppression or tagging rule for alerts, a named analyst who knows the test window, and retention of the test logs so the findings can be traced to specific requests. Confirm with your security operations team whether the test should be treated as a known exercise, and record that decision in the rules of engagement.

What the MCP test report contains and how it supports customer reviews

An MCP test report is only useful if each part answers a question a reader actually asks: what was tested, what is wrong, whether it was fixed, and what can be shared outside the company. The cards below cover the parts of the report and the summary documents that sit alongside it.

Scope and method

The report opens with the agreed scope: which MCP servers, clients, transports and authorization servers were in play, which MCP security best practices were tested, and what was excluded. It also records the test accounts, roles and environments used. Check that the scope names each server version and whether local servers were included, because a finding without a stated version is hard to retest.

Findings with severity ratings

Each finding names the weakness category, such as token passthrough, missing token audience checks, confused deputy behavior in a proxy, or unvalidated OAuth discovery URLs. It states the affected component, the business impact in the client's terms, and a severity rating with the rating basis explained. Ask whether ratings follow a published method and whether the client can adjust them with reasons recorded.

Reproduction evidence without exploit code

Evidence shows that a weakness exists and what it allows, using request and response metadata, configuration excerpts, screenshots and timestamps. It does not contain working exploit code, payloads or step-by-step attack commands. Engineers can still reproduce the condition in their own test environment. Confirm that the client's security team can receive the evidence without the report itself becoming a sensitive attack guide.

Remediation mapped to MCP practices

Each recommendation names the change to make and the MCP best practice it addresses, such as rejecting tokens not issued for the MCP server, validating authorization URLs before fetching them, requiring user approval with the exact command shown for local servers, and narrowing scopes to what each tool needs. Ask for owners and suggested order of work, so the remediation plan can be assigned in a sprint.

Retest results and status per finding

After fixes, the retest section lists each original finding with a status such as resolved, partly resolved, not resolved or accepted risk, and the date and build tested. Accepted risks should carry a named owner and a review date. Ask whether retest covers the same MCP server version as production, since a fix made in a staging copy does not close a finding in live use.

Executive summary for risk owners

A short summary for executives and risk owners states the overall exposure, the highest findings in plain language, what is already fixed, and which decisions are needed, such as whether to pause a connector or accept a risk. It avoids technical detail so that it can go into a board or risk committee pack. Ask whether the summary and the technical body are issued together and carry the same version identifier.

Summary letter for customer reviews

A letter or attestation-style summary describes the testing performed, the period, the scope category and the status of findings, and can be shared with customers who run security reviews. It describes work performed. It does not replace an audit report, a certification or an attestation issued by an independent auditor or certification body. Confirm with your auditor or customer which wording, period and level of detail they accept before you send it.

Questions buyers ask about MCP server security testing

What drives the cost of an MCP server security test?

The cost follows from the written scope, and the biggest drivers are how many MCP servers are in play, whether each is remote or local, how many authorization flows and client types need checking, and how much of the surrounding system (identity provider, backend APIs, tool integrations) is included. Fees cover tester time for preparation, testing, analysis and reporting, plus any retest. Ask for the quote to list each server and client in scope, the authorization model you use, the environments provided, and what the retest includes. DeployOpen does not publish a price list, so the quote is built from that scope.

How long does an MCP server security test take, and what sets the schedule?

The schedule is set by the number of servers, the complexity of the authorization design, and how quickly your team can provide access, test accounts and environments. Work usually moves through agreed scope, environment setup, testing, reporting and a readout, and the written scope states the expected milestones. Delays most often come from waiting for identity provider configuration, unclear ownership of tool backends, or late decisions on whether local servers run on a test machine. Confirm the start date, the access dates and the report date in the statement of work rather than relying on a general estimate.

What does the test need from our engineering and identity teams?

Expect to supply the MCP server endpoints, a description of the tools and scopes each server exposes, test user accounts for each role, access to the authorization server configuration and its metadata, and a named technical contact who can answer questions during testing. For local servers, the team needs to provide a test machine or a sandboxed build. Identity and platform engineers should be available to confirm token audiences, client registration and session settings. Agree these items before work starts so the schedule holds.

Can our in-house security team run an MCP server test themselves?

An in-house team can test parts of MCP authorization and session handling if it has OAuth and identity expertise and access to the servers, and many teams start there. An independent test adds value when the authorization server, the MCP proxy and the downstream APIs are owned by different teams, when a customer or regulator expects an external report, or when your team also builds the system it would be testing. Ask a provider to explain which checks they would repeat internally and which they would not, so you can judge the gap honestly.

How is retesting billed and scheduled after findings are fixed?

Retesting is usually priced separately from the first engagement and scoped to the findings you ask to have verified, so the quote should name the findings, the environment and the number of verification rounds. Ask whether retest time is included in the original fixed fee, how long after delivery it can be booked, and whether the retest produces an updated report that your auditor or customer can read. Plan the retest window before the initial report is delivered, because fixes to token audience checks or session handling often need a coordinated release.

Can MCP server testing run against production systems?

Production testing is possible only when the written scope, rules of engagement and change approval process allow it, and many MCP tests run in a staging environment that mirrors production authorization settings. Testers can avoid disrupting live tool actions by using test accounts and read-only or sandboxed tool backends where the design allows. Confirm which tools can perform writes, which data they touch, who is notified before testing begins, and how testing stops if a service degrades. Ask for these controls in the scope document, and confirm any cloud provider rules that apply to your hosting.

How does MCP server testing relate to AI agent and LLM application tests?

MCP server testing covers the protocol layer: how clients obtain and use tokens, how servers validate token audience, how OAuth discovery and redirect URLs are handled, how sessions are managed and how local servers are sandboxed. An AI agent test covers what the agent does with those tools, including goal hijack and tool misuse, while an LLM application test covers prompt injection, output handling and excessive agency in the surrounding application. Many engagements combine these, and the scope should state which MCP checks sit inside the agent test and which are delivered as a separate work item, so findings are not duplicated or missed.

How DeployOpen scopes, tests, reports and retests MCP servers

DeployOpen treats an MCP server as part of a larger system: the identity provider, the upstream APIs it calls, the clients that connect to it and the host it runs on. Each engagement is fixed-scope, with the scope, deliverables and timeline agreed in writing before testing starts.

How we scope

The written scope lists each MCP server, its transports, and whether it runs remote or as a local process on user machines.
We record the authorization server, the protected resources and the upstream APIs each server calls on behalf of users.
The scope names the tools, scopes and client applications in test, so findings can be traced to specific capabilities.

How we build

We test token audience handling, token passthrough, OAuth authorization URL validation and SSRF during discovery against the MCP security best practices.
We test session identifiers, session binding and hijacking resistance, and whether confused deputy paths allow a client to act with another user's rights.
For local servers, we review sandboxing, default privileges and the one-click configuration flow, including whether the exact command is shown and approved.

How we hand over

The report maps each finding to the relevant MCP best practice and to the OWASP Top 10 for Agentic Applications 2026 where it applies.
Each finding includes affected components, reproduction context, business impact and a prioritized fix, written for engineers and reviewers.
We agree in writing what the report can support, such as customer security reviews, and what an independent auditor would still need to assess.

How we support

After fixes are deployed, we retest the findings in the agreed scope and document which issues are closed and which remain open.
Ongoing support, upgrades and continuous testing for MCP servers are available as a retainer once the initial scope is complete.
Ask us to confirm in the quote how retesting is billed and whether scope changes, such as new tools or scopes, are included.