When an MCP server security review is the right choice, and when a pentest is
If you have exposed an MCP server to agents or clients and must decide what to commission, start by separating two questions: does the server behave correctly as an MCP component, and can an attacker break into the HTTP endpoints behind it? An MCP security review tests protocol behavior against the MCP security best practices (protocol version 2025-11-25), covering confused deputy risks on proxy servers, token passthrough, server-side request forgery, session hijacking, local server compromise, OAuth authorization URL validation and scope minimization. A conventional API penetration test instead exploits the HTTP endpoints the server exposes, probing authentication, object-level authorization and input handling as an attacker would.
Choose the MCP review as the primary engagement when the server is new, when it brokers tokens to upstream services, or when it runs locally on user workstations. Token passthrough is a protocol-level decision that an endpoint scan will not reveal: the reviewer checks that the server rejects any token not explicitly issued for it, and that the server's own configuration, not just its responses, enforces that rule. For local servers, the reviewer also checks that one-click client setup shows the exact command and requires explicit user approval, and that the server runs with minimal default privileges. Ask the provider to confirm which of these checks are in scope before you sign.
Choose the API penetration test as the primary engagement when the server fronts a mature backend with many routes, customer data and existing authorization logic that agents can reach through tools. Broken object level authorization, broken function level authorization and server-side request forgery appear in both the OWASP API Security Top 10 2023 and the MCP guidance, so one tester working both sides avoids paying twice for the same ground. In many cases, the right answer is to combine them: run the MCP review first to settle protocol and token decisions, then a penetration test against the production-like deployment to confirm how those decisions hold up under attack.
How the method changes for remote and local MCP servers
A remote MCP server is reached over the network and usually sits behind an OAuth-protected endpoint, so most of the test resembles a conventional API assessment with MCP-specific checks added. The testing team needs to know who issues tokens, which authorization server validates them, and whether the MCP server checks that each token was explicitly issued for it. The MCP authorization specification forbids token passthrough, which means a server must not accept tokens that were not issued for that server. Testers should therefore send tokens minted for other audiences and confirm they are rejected. The server-side request forgery, session hijacking and authorization URL validation items in the MCP guidance also need network-facing tests.
- Token audience checks: Confirm the server rejects tokens issued for other resources, and that it does not forward client tokens to downstream APIs.
- Authorization URL validation: Test whether the OAuth flow accepts unvalidated redirect or authorization URLs.
- Scope minimization: Check that tools request and receive only the scopes they need.
- Session handling: Test session identifiers for hijacking and reuse across users.
- Outbound requests: Probe any tool that fetches URLs for server-side request forgery.
Confirm with the vendor or platform team which authorization server, token lifetimes and downstream services the MCP server trusts, and whether the deployment has its own API gateway controls that the test should include.
A local MCP server runs as a process on a user's machine, started by a client application, so the main risks sit in how the client configures and launches it. The MCP security guidance says clients offering one-click configuration must show the exact command to be executed and require explicit user approval. It also says servers should run sandboxed with minimal default privileges. A review of local servers therefore tests the client's install and approval flow as well as the server code. Standard API penetration tests rarely reach this layer because no network endpoint may exist at all.
- Command display: Check that one-click installs show the exact command, arguments and environment before anything runs.
- Explicit approval: Confirm the client requires a deliberate user action and does not auto-start servers from a shared configuration.
- Sandboxing: Verify whether the server runs with restricted file, network and process access by default.
- Local transport exposure: Check whether any local listener is reachable by other processes or other users on the machine.
- Configuration files: Review where client configuration and stored credentials are kept and who can read them.
Confirm with the client vendor which sandboxing options exist, whether enterprise policy can block or allowlist servers, and how updates to a local server are signed and approved.
Most organizations run both kinds of server, and the split changes the scope document. A remote server belongs in the same engagement as the APIs it calls, with the authorization server and downstream services named as in-scope or out-of-scope. A local server usually needs a workstation-based test with a standard build image, a chosen client version and an agreed set of configurations. The two tracks share findings, such as token handling in a tool that runs on either deployment, so the report should map each finding to the deployment where it appears. Illustrative example: a company that allows staff to install a local server for document search and also hosts a remote server for CRM access would test the local client policy and the remote OAuth flow in one engagement, but with different test environments.
- Separate test environments: Use a staging remote endpoint and a managed workstation image for the local track.
- Shared findings: Record which deployment each finding applies to, since a fix may differ.
- Client versions: Pin the client and server versions tested, because guidance and behavior may change.
- Sign-off owners: Name who approves local server installs and who owns remote endpoint fixes.
- Retesting: Agree whether both tracks are retested after the client or server is updated.
Before scoping, ask the client vendor and your platform team which deployment models are in use, and get written confirmation of the controls each one enforces.
MCP security review vs API penetration test side by side
This table compares an MCP server security review with a conventional API penetration test on goals, scope, method, access, findings, gaps and deliverables. Read it to decide which exercise your MCP server needs, or whether one engagement can cover both. Neither exercise replaces the other, and the main takeaway is that MCP-specific risks such as token passthrough and local server execution sit outside a standard API test unless the scope names them.
| Dimension | MCP server security review | API penetration test |
|---|---|---|
| Primary goal | Check the server against the MCP security best practices, especially token handling, delegated authority and local execution | Find exploitable weaknesses in the API's authentication, authorization and input handling |
| Standards anchor | MCP security best practices (protocol version 2025-11-25) and the MCP authorization specification | OWASP API Security Top 10 2023 and the OWASP Web Security Testing Guide v4.2 |
| Primary method | Design and code review of the server, its OAuth flow and tool definitions, supplemented by targeted testing | Hands-on testing of endpoints, with manual work to chain authorization and logic flaws |
| Typical access | Source code, configuration, client setup and a test identity; a local server may also need a test machine | Documentation or an API schema, test accounts at several privilege levels, and a non-production target |
| What it finds | Token passthrough, confused deputy risks in proxy servers, SSRF in metadata fetches, session hijacking, weak OAuth URL validation, excessive scopes, unsafe one-click local installs | Broken object and function level authorization, broken authentication, excessive data exposure, unrestricted resource use, SSRF |
| What it misses | Most endpoint-level logic flaws and load behavior unless the review includes them in scope | Whether the server rejects tokens issued for other services, or whether a local install runs with minimal privileges |
| Deliverables | Findings mapped to MCP best practice sections, configuration and authorization design notes, remediation list | Findings with reproduction steps, severity, mapping to OWASP API Top 10 categories, retest guidance |
| Main effort drivers | Number of tools and scopes, whether the server is remote or local, how many upstream services it calls, and the OAuth design | Number of endpoints and roles, authentication complexity, and whether test data and a staging copy are available |
| Confirm before scoping | Whether the server is remote or local, and which upstream APIs it holds tokens for. Ask the provider to confirm its current MCP specification version | Which API version is in scope, which roles need test accounts, and whether the MCP server is in or out of the target list |
Which risks each approach finds and misses
MCP servers sit between an AI client, an identity provider and the APIs behind them, so the risks cluster at the seams. Each card names the approach that should lead for one risk and what the other approach tends to miss, so one engagement can cover both without assuming either one is complete.
Token passthrough
An MCP server that forwards a token it received from the client to a downstream API, without checking that the token was issued for the MCP server itself, is passing through a credential it should never have accepted. The MCP authorization guidance forbids this, so the MCP server review should lead, checking the token audience and where tokens are stored and forwarded. A conventional API test tends to miss it because the downstream API sees a valid token and behaves normally. Check whether the server validates the aud claim before it calls anything.
Confused deputy on proxy servers
An MCP proxy that calls a third-party API with a static client identity can let one user's consent be reused by another client, so the proxy acts on behalf of an attacker. The MCP review should lead, because it has to trace consent, client registration and authorization URLs across the proxy. An API penetration test sees only well-formed requests and may report nothing. Ask the team to show how consent is recorded per client and how authorization URLs are validated before the redirect.
Server-side request forgery
Tools that fetch URLs on a user's behalf can be steered toward internal addresses, cloud metadata endpoints or local services. Both approaches cover this risk, and the API penetration test usually leads here because SSRF is listed as API7 in the OWASP API Security Top 10 2023. The MCP review adds the tool-level view, checking which tool parameters reach outbound requests. Test every tool that accepts a URL, path or hostname, not only the HTTP endpoints.
Broken object level authorization
When a tool or endpoint accepts an identifier and returns data without checking that the caller owns that object, one user can read another user's records. This is API1 in the OWASP API Security Top 10 2023, so the API penetration test should lead, with object IDs swapped across accounts. The MCP review tends to miss it because the model may only call the tool with IDs it was given. Confirm that each MCP tool performs the same ownership check as the REST endpoint it wraps.
Broken function level authorization
A tool that the model can call may expose administrative functions that the user interface never shows, or a scope check may be missing on one tool in a set. This is API5 in the OWASP API Security Top 10 2023. The API test should lead by calling privileged functions with low-privilege tokens, and the MCP review should confirm that each tool declares and enforces the scopes it needs. Ask for the full tool list and the scope required by each entry.
Local server compromise
Local MCP servers run with the user's privileges, so a crafted install command or a server with broad file access can compromise the workstation. The MCP review should lead, checking that clients show the exact command and require explicit approval, and that servers run sandboxed with minimal default privileges. A network-facing API test does not reach this surface at all. Confirm which servers run locally, which files and credentials they can read, and whether one-click installation is enabled.
Where the OWASP API Top 10 overlaps with MCP risks
Most of an MCP server's exposure is ordinary API exposure, so a conventional API test already covers much of it. The OWASP API Security Top 10 2023 items that map directly are API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization and API7 Server Side Request Forgery. For an MCP server, the tool handlers are the endpoints. Test each tool with two identities and confirm that a caller cannot read or change another tenant's resources by changing an ID argument, that tool-level permissions are enforced on the server rather than only in the client, and that a tool which fetches a URL cannot be pointed at internal addresses (API7). Resource consumption (API4) matters because agents can call tools in loops, so confirm rate limits, payload size caps and timeouts exist on the server side.
The MCP-specific checks sit where the API list is silent. The MCP security best practices (protocol version 2025-11-25) forbid token passthrough: an MCP server must not accept tokens that were not explicitly issued for that server. An API test may confirm that a bearer token is validated, but it will not necessarily confirm the token's audience. Send a token issued for another service and confirm rejection. Also check OAuth authorization URL validation and scope minimization, and test session handling for session hijacking. For local servers, check that clients show the exact command before one-click installation and that the server is sandboxed with minimal default privileges. These checks need a host-level review, which a standard API engagement often omits. Confirm early whether the server runs locally, remotely or both, because the scope changes with that answer.
If an agent calls the server, the same findings carry agent risk. The OWASP Top 10 for Agentic Applications for 2026 lists ASI02 Tool Misuse and ASI03 Identity and Privilege Abuse. Test whether an agent can be steered into calling a destructive tool with arguments the user never approved, and whether the credentials it holds let it exceed the privileges of the human who started the task. If the server has no agent in front of it, these items can usually be left out of scope, but confirm that with the team that owns the client. Record the agent-facing findings in the same report so that the API fixes and the agent fixes are tracked together.
What you receive from each engagement
This table sets out the deliverables you can expect from an MCP server security review and from a conventional API penetration test, so you can compare what each produces. The exact format, depth and sign-off steps are agreed in the written scope before work starts, so treat the rows as a starting point for that conversation.
| Deliverable | MCP server security review | API penetration test |
|---|---|---|
| Primary findings | Issues mapped to sections of the MCP security best practices, such as token passthrough, confused deputy, SSRF, session handling and local server setup | Issues mapped to the OWASP API Security Top 10 2023 categories and the test cases each one exercised |
| Reproduction steps | Step-by-step requests, tool calls and client configurations that show each issue, where the review confirms it in a running server | Step-by-step HTTP requests and responses with the account, role and object IDs used, so your team can replay each exploit |
| Risk ratings | Severity agreed in scope, with a note on whether the rating assumes a remote or local deployment and which clients connect | Severity agreed in scope, with a note on the authentication state and data exposed by each endpoint tested |
| Coverage record | Which MCP best practice sections, tools, transports and authorization flows were reviewed, and which were out of scope | Which endpoints, roles, authentication paths and business flows were tested, and which were excluded |
| Remediation guidance | Fix direction for the server, the authorization server and the client, including scope minimization and token validation changes | Fix direction for the API code, gateway policy and identity configuration, usually written for the development team |
| Retest | Confirmation that each agreed finding is fixed, retested against the same MCP server version or a version named in scope | Confirmation that each agreed finding is fixed, retested against the same API build or a build named in scope |
| Format and sign-off | Report format, delivery channel, and any separate review notes are set in the written scope; confirm these before work starts | Report format, delivery channel, and any separate executive summary are set in the written scope; confirm these before work starts |
Running the review and the pentest in sequence
Running the authorization design review first, the API penetration test second and the targeted MCP checks third means each stage tests what the previous one confirmed, so findings are fewer, clearer and easier to retest.
Agree the environment and rules of engagement
Before any testing, the client and the testing provider agree in writing which MCP server, API endpoints, staging or production environment, test accounts and tokens are in scope, and which actions are off limits. NIST SP 800-115 provides a rules of engagement template in Appendix B that can anchor this document. The step is done when both parties sign off the scope, the test identities and the escalation contact, and the client confirms who can stop the test if production is affected.
Review the authorization model design
The provider reviews the design documents, OAuth flows, scope definitions and tool permission mappings before any live requests are sent. The goal is to establish who the caller is, which identity the MCP server uses downstream, which scopes each tool requires and where the server obtains and validates tokens. The client supplies architecture diagrams, the identity provider configuration and a list of tools with their backing APIs. The step closes with a written list of authorization assumptions that the penetration test must check.
Map the MCP server API surface
Using the design review as input, the testers enumerate the endpoints the MCP server exposes and the backend APIs it calls on the user's behalf. They record which requests carry the caller's token, which ones use a service account and where object identifiers appear in tool arguments. The client confirms which backend APIs are reachable from the test environment. The step ends with an inventory that the later API tests can be measured against.
Run the API penetration test
The testers run the conventional API test against the agreed environment, covering the risks in the OWASP API Security Top 10 2023 that apply to the inventory, such as Broken Object Level Authorization, Broken Authentication, Broken Function Level Authorization and Server Side Request Forgery. Because the design review has already named the authorization assumptions, testers can target them directly rather than rediscovering them. The client provides test accounts with different privilege levels and monitors for service impact. The step closes with validated findings and evidence for each request tested.
Check token handling and local configuration
The MCP-specific checks come after the API results are known. Testers verify that the server rejects tokens not issued for it, which is the token passthrough requirement in the MCP authorization specification, and they test the confused deputy and session hijacking cases described in the MCP security best practices. For local servers, they review how one-click installation shows the exact command, whether user approval is required and whether the server runs with minimal privileges. The client provides the client configuration files and installation steps. The step closes when each best-practice item is marked as passed, failed or not applicable, with evidence.
Triage findings and agree fixes
The provider and the client review the combined findings together, separating issues that come from the API layer, the authorization design and the MCP layer, since each usually has a different owner. Duplicate symptoms are merged so that one root cause is tracked once. The client's engineering team confirms reproduction steps and proposes remediation. The step closes with a remediation list assigned to owners, with the risk rating each finding received and any items the client accepts as residual risk.
Retest the fixes and confirm closure
Once fixes are deployed to the agreed environment, the testers rerun the specific checks that failed and the authorization cases that were changed, rather than repeating the whole engagement. They confirm that the fix addresses the root cause and that adjacent endpoints were not broken by it. The client confirms the deployed version and configuration. The step is complete when each closed finding has a retest record and the report shows the final status of every item in scope.
What drives cost and duration for each approach
Both an MCP server security review and an API penetration test are priced from the written scope, so the same handful of variables move the cost of each. The cards below cover the inputs that change effort, which parts of the work are one-time, and which parts recur when the server or its clients change.
Tool and endpoint count
Every MCP tool is an action an agent can take, and every API endpoint is a route a tester must reason about. A server with a few read-only tools is a small review. A server that exposes write actions, file access or outbound requests across many tools needs each tool traced from client input to backend call and back. Ask the provider how it counts tools, resources and prompts, and whether the quote assumes a fixed inventory or a discovery phase.
Authentication and token model
Token passthrough is the item most likely to add scope. Reviewing whether the server accepts only tokens issued for it, how OAuth authorization URLs are validated, and how scopes are minimized takes more time than checking a single bearer token on an API. Confirm whether the engagement includes an identity provider configuration review or only the server's own handling of tokens and sessions.
Local versus remote deployment
A remote MCP server is tested as a networked service, similar to a conventional API. A local server runs on a user's machine, so the review also covers how clients present one-click configuration, what command runs, and whether the server is sandboxed with minimal default privileges. Local reviews need a representative workstation or a build of the client, which adds setup work that remote reviews do not.
Client integrations in scope
Each MCP client (desktop assistant, IDE plugin, agent framework) can handle consent prompts, token storage and tool approval differently. Testing one client against the server is a bounded task. Testing several clients, or confirming how a server behaves behind a proxy that forwards requests for multiple clients, multiplies the test cases. Agree the list of clients and versions in writing before work starts.
Test environment availability
Active testing of an MCP server or API needs a non-production instance with realistic data, working identity integration and the tools wired to test backends. If that environment is missing, the first part of the engagement is building it, and that work is billed separately from testing. Ask who provisions the environment, who supplies test accounts at each privilege level, and what happens if a tool writes to a live system.
Retest and server change scope
The initial review is a one-time cost. Retests after fixes are usually scoped as a smaller, separate piece of work, and an MCP server that adds tools, changes its auth flow or updates its protocol version may need a new review of the changed surface. Ask whether retest rounds are included, how long they remain valid, and how changes to tool definitions are handled between engagements or under an ongoing retainer.
Questions buyers ask before commissioning MCP or API security testing
Does an API penetration test alone cover MCP server risks?
Usually only in part. A conventional API test covers many of the same weaknesses, including broken object level authorization, broken authentication and server-side request forgery, which map to the OWASP API Security Top 10 2023 entries API1, API2 and API7. The MCP security best practices (protocol version 2025-11-25) add risks an API test may not probe: token passthrough, where a server accepts tokens not issued for it, confused deputy behavior in proxy servers, session hijacking and local server compromise. Ask the tester to show, in writing, which MCP-specific items are in the test plan, and whether the MCP guidance is used as a checklist.
What does the client team need to provide for an MCP review?
Expect to supply access and context, not just a URL. Typical inputs are the server source or build artifacts, a description of the tools and resources it exposes, the authorization server configuration and the scopes it requests, test accounts with the roles you need checked, and a non-production environment where the tester can send exploit traffic. For local servers, also provide the install and configuration steps your users follow, because the guidance on one-click configuration and user approval is part of the review. Confirm the rules of engagement in writing before testing starts, following the structure of the rules of engagement template in NIST SP 800-115, Appendix B.
Can our own engineers run an MCP security review internally?
Yes, for a first pass, and many teams do. The MCP security best practices are a usable checklist for code and configuration review: check that the server rejects tokens not issued for it, validates OAuth authorization URLs, requests minimal scopes, blocks server-side request forgery paths, and runs local servers with minimal default privileges. Internal reviewers often miss the attack side, though. NIST SP 800-115 treats review techniques as passive, while penetration testing uses real exploits, and an independent team gives different evidence. Consider an internal review for routine changes and an independent test for the release that exposes a new server to users.
How long does an MCP review take, and what drives the effort?
No duration is fixed by a researched source, so ask each provider for its estimate against your written scope. The main drivers are the number of tools and resources the server exposes, how many authorization flows and identity providers it touches, whether it is a remote or local server, how many user roles must be tested, and whether it proxies calls to upstream APIs. A server that wraps a single read-only API takes far less effort than one that chains several downstream services with delegated tokens. Ask the provider to list the components in scope so you can compare quotes on the same basis.
What should we ask for in a quote for MCP or API testing?
Ask for a written scope that lists each target, each component and each test category, so you can see what is included and what is excluded. A useful quote states the test type (review, penetration test or both), the layers covered (authorization, token handling, transport, local install), the access you must provide, the reporting format, the retest terms and who performs the work. Ask how the MCP checks are mapped to findings and whether retest work after fixes is included or billed separately. DeployOpen does not publish a price list. Its fixed-scope quotes follow from the written scope, so a clear scope is what makes a quote comparable.
Is a combined MCP and API engagement cheaper than two separate tests?
It can be, because the two tests share setup, access and reporting, and NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. Savings depend on overlap: if the MCP server sits in front of the same APIs you already test, shared authentication, test data and environment setup reduce effort. Savings shrink when the MCP server uses a different identity model, runs locally on user machines, or needs a separate test plan. Ask the provider to price the combined scope as one line and as two separate lines, so the saving is visible rather than assumed.
How often should we retest after an MCP server changes?
Retest after any change that touches authorization, token handling, tool definitions, upstream API access or the install path for local servers, and keep a regular scanning cadence between tests. NIST SP 800-115 suggests regularly scheduled scanning interspersed with periodic penetration testing, and CIS Controls v8.1 Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques testers used. Set a retest trigger list in your change process, not only a calendar date. Confirm with your provider whether retesting after fixes is in the original quote or a separate retainer, since ongoing testing is offered as a retainer.
How DeployOpen scopes and delivers MCP and API security testing
DeployOpen plans, tests and documents MCP server reviews and API penetration tests inside your own infrastructure, so the server, its OAuth configuration and its logs stay in your environment. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope names each MCP server, API and client in the engagement, with environments and accounts.
- Scope states whether the MCP review covers remote, local or both server deployment models.
- Scope lists authentication roles, token issuers and test accounts so authorization checks can be run.
How we build
- Test environments are set up in your infrastructure, with a staging copy available where production testing is restricted.
- Tests cover the MCP security best practices alongside the OWASP API Security Top 10 2023 categories in scope.
- Local server checks review how clients present install commands, approvals and default privileges.
How we hand over
- Reports list each finding with reproduction steps, affected component and suggested remediation.
- Findings are mapped to MCP and OWASP API references so engineering and security teams can track them.
- Handover includes a debrief and a retest plan for fixes agreed in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
- Retainers can cover retesting when MCP servers or API gateways change protocol version or configuration.
- Confirm with DeployOpen during quoting which retainer scope and response expectations apply to your team.
