OWASP MCP Top 10 Testing: A Pentest Scope for the Protocol Layer
A CISO receives an enterprise security questionnaire with a new request: “Describe your testing against the OWASP MCP Top 10.” Engineering can show the OAuth configuration, the approved MCP server list, and the last AI penetration test report. What it cannot show is whether token handling was tested against MCP01, whether tool descriptions were treated as a security boundary under MCP03, or whether unregistered servers were searched for under MCP09.
That is the gap OWASP MCP Top 10 testing can close. It is not another prompt-injection checklist. It is a protocol-layer assessment of the identities, credentials, tools, context, servers, and downstream authority that connect an AI system to real business systems.
The timing matters. OWASP currently labels its MCP Top 10 project version v0.1 and Phase 3 beta, while the MCP specification itself changed materially in July 2026. A useful assessment therefore needs more than ten checklist rows. It needs a versioned scope, architecture-specific test cases, and evidence that both permitted and prohibited actions were exercised safely.
Why OWASP MCP Top 10 Testing Needs Its Own Scope
MCP sits between an AI application and the systems it can use. Depending on the implementation, an MCP server may expose customer records, code repositories, cloud resources, ticketing workflows, databases, communication tools, or administrative functions. That makes the protocol layer a boundary between model reasoning and enterprise authority.
A conventional API assessment still matters. So does OAuth, IAM, software composition analysis and model-level adversarial testing. None of them, by themselves, prove that an MCP-enabled workflow has the right identity, tool, context and authorization boundaries.
For organizations deploying tool-enabled agents, an AI penetration testing assessment for tool-enabled systems should therefore explicitly identify the MCP-specific trust path: user, agent, MCP client, MCP server, tool, downstream API, and resulting business action.
The framework helps buyers put names around failures in that path. OWASP's current beta identifies:
- MCP01:2025 - Token Mismanagement & Secret Exposure
- MCP02:2025 - Privilege Escalation via Scope Creep
- MCP03:2025 - Tool Poisoning
- MCP04:2025 - Software Supply Chain Attacks & Dependency Tampering
- MCP05:2025 - Command Injection & Execution
- MCP06:2025 - Intent Flow Subversion
- MCP07:2025 - Insufficient Authentication & Authorization
- MCP08:2025 - Lack of Audit and Telemetry
- MCP09:2025 - Shadow MCP Servers
- MCP10:2025 - Context Injection & Over-Sharing
The “2025” identifier should not be mistaken for a reason to ignore the framework in 2026. Those are the identifiers used by the current MCP Top 10 beta. Because OWASP says another release is planned, contracts and reports should record the exact framework version used rather than referring vaguely to “the OWASP MCP Top 10.”
OWASP MCP Top 10 Testing Matrix: MCP01-MCP10
A buyer does not need ten threat descriptions repeated from OWASP. The useful question is what each category changes in the assessment. The following matrix translates the beta framework into test objectives and evidence requirements without turning the engagement into an exploit tutorial.
| OWASP MCP risk | What the pentest should verify | Evidence the buyer should receive | Business failure being prevented | Typical remediation effort |
|---|---|---|---|---|
| MCP01 Token Mismanagement & Secret Exposure | Token lifetime, scope, audience, storage, revocation and whether credentials appear in logs, context, configuration or other unintended locations. | Credential-flow diagram, redacted token-lifecycle test results and confirmation of revocation and scope boundaries. | A compromised agent, client or server gaining reusable access to downstream systems. | Medium to high if identity architecture must change. |
| MCP02 Privilege Escalation via Scope Creep | Whether every server, tool and action receives only the permissions required for its business purpose, including temporary and inherited access. | Role-and-scope matrix showing successful permitted actions and rejected prohibited actions. | An agent turning a narrow workflow into broader repository, cloud, data or administrative access. | Medium, but higher where shared service identities are entrenched. |
| MCP03 Tool Poisoning | Whether tool names, descriptions, schemas and metadata are trusted blindly, can change after approval, or can alter tool selection and behavior unexpectedly. | Tool provenance inventory, integrity/change-control evidence and sanitized behavioral test results. | A trusted-looking tool steering an agent toward an unintended action or disclosure. | Medium when registry, signing or approval controls are missing. |
| MCP04 Supply Chain & Dependency Tampering | Server packages, SDKs, dependencies, registries, update paths and provenance controls for the exact components running in scope. | Version inventory, dependency/provenance findings and evidence that unapproved changes are detected or blocked. | A previously trusted connector becoming a path into sensitive systems after an update or dependency compromise. | Medium to high across decentralized MCP estates. |
| MCP05 Command Injection & Execution | Whether model-influenced or user-influenced values reaching execution-capable tools are constrained by server-side validation, allowlists, isolation and authorization. | Sanitized negative test cases, containment observations and affected trust-boundary documentation. | Untrusted input being converted into an unauthorized operating-system or administrative action. | Medium to high where tools expose broad execution primitives. |
| MCP06 Intent Flow Subversion | Whether untrusted content can change the intended workflow, tool selection, parameters or approval path, especially in multi-step agent processes. | Documented adversarial scenarios showing where intent was preserved, rejected or required additional approval. | A legitimate business request being transformed into a materially different action. | Medium because fixes often span prompts, policy enforcement and application logic. |
| MCP07 Authentication & Authorization | Whether human, client, workload and server identities remain distinguishable and whether every tool and downstream resource enforces authorization for the current user, role, tenant and action. | Identity-and-authorization matrix, denied-action evidence and protocol/OAuth configuration observations. | A valid login or token being treated as blanket authority across tools or customer data. | High when downstream services rely on shared identities. |
| MCP08 Audit & Telemetry | Whether the organization can correlate the originating user, agent decision, server, tool, authorization result and downstream effect. | End-to-end audit trace examples, logging-gap findings and incident-attribution assessment. | An incident occurring without enough evidence to determine who requested, authorized or executed the action. | Medium, often involving several logging platforms. |
| MCP09 Shadow MCP Servers | Whether local, development, experimental and unregistered servers can connect to production identities, data or agents outside the approved inventory. | Inventory reconciliation, unapproved-server findings and credential/access-path review. | Security controls governing approved integrations being bypassed through unsanctioned infrastructure. | Medium, with governance effort often exceeding the technical fix. |
| MCP10 Context Injection & Over-Sharing | Tenant, session and task isolation; data minimization; persistence; tool-output handling; and whether unrelated sensitive context becomes available to another workflow. | Context-boundary matrix and sanitized cross-user, cross-task and data-minimization test results. | Customer, employee, operational or hidden application information crossing an unintended boundary. | Medium to high if the context architecture must be redesigned. |
The remediation column matters for budget planning. An isolated logging defect and a shared production identity may both appear as findings, but they do not impose the same engineering cost. A good report should therefore distinguish quick configuration corrections from architectural changes requiring IAM, platform, or product work.
Why Existing Controls Do Not Close the Protocol Layer
The MCP Top 10 is most useful when it prevents a common procurement mistake: treating the presence of a control as proof that the control has the correct scope.
| Existing control | What it proves | What OWASP MCP Top 10 testing still needs to answer |
|---|---|---|
| OAuth / identity provider | A user or client can authenticate and receive credentials. | Are audience, scopes, delegation, revocation and originating-user authority correct for each tool? |
| Cloud IAM | Configured permissions are enforced. | Are those configured permissions broader than the agent's task or the user's authority? |
| API gateway | Routing, rate limits and centralized policy exist. | Are model-selected objects, parameters and actions authorized in their actual business context? |
| SAST / SCA | Code and dependency weaknesses can be identified. | Can trusted metadata, tool descriptions, context or runtime registration manipulate agent behavior? |
| Approved-server list | Known MCP servers have been selected. | Have shadow servers been discovered, and can an approved server later change behavior or dependency state? |
| Central logging | Events are recorded somewhere. | Can investigators reconstruct user to agent to MCP server to tool to downstream action? |
This is why the existing guide to MCP security testing before production treats the problem as a trust path rather than a server-only test. The Top 10 adds a useful framework overlay, but it does not remove the need to understand the architecture underneath it.
The July 2026 MCP specification reinforces the same point. Authorization behavior has continued to evolve, including additional issuer validation and changes in client-registration strategy. The pentest scope should therefore identify the protocol and SDK versions actually deployed rather than assuming that every “MCP implementation” has the same security properties.
Scope the MCP Server Pentest Around the Architecture
A weak statement of work says, “Test our three MCP servers against the OWASP MCP Top 10.” A strong one identifies every trust relationship that changes what those ten categories mean.
Before testing begins, the scoping package should identify:
- MCP clients, servers, environments and protocol/SDK versions.
- Every exposed tool and its owner.
- Read, write, administrative, irreversible and customer-impacting actions.
- Human, workload, service and delegated identities.
- User roles and tenant boundaries.
- Credential issuance, storage, refresh and revocation paths.
- Tool registries, installation and update mechanisms.
- External content, RAG sources and other untrusted information that can influence tool use.
- Downstream APIs, databases, SaaS platforms and cloud services.
- Audit, alerting, retention and emergency-disable controls.
If the main uncertainty is whether conversational manipulation itself was included in a previous engagement, our breakdown of what prompt injection testing changes in scope addresses that narrower question. MCP Top 10 testing goes further because successful manipulation only becomes one part of the risk once the agent has standardized access to external tools and authority.
Planning effort and budget
Pentest Testing Corp's currently published AI penetration testing price starts from $9,500. The final scope depends on integration depth, exposed APIs, tools, and the amount of adversarial testing required. For planning purposes, the existing MCP security guide uses the following non-guaranteed ranges once access is ready:
| Architecture profile | Indicative planning range | What usually drives effort |
|---|---|---|
| Limited AI integration | About 5-8 business days | Few servers and tools, narrow read-only access, limited identity combinations. |
| Integrated / RAG-enabled system | About 8-15 business days | Multiple data sources, write-capable tools, external content, several roles or workflows. |
| Complex agentic / enterprise system | About 15-25+ business days | Multiple servers, many tools, tenant combinations, privileged actions and substantial downstream authority. |
The number of MCP Top 10 categories does not determine price. Two deployments can both have ten categories in scope while requiring very different amounts of testing. The multiplication happens across servers, tools, roles, tenants, credentials, data classes, and action types.
Hypothetical Scenario: When “OAuth Is Enabled” Is Not Enough
Consider a hypothetical SaaS company preparing an enterprise launch of an AI support agent. The agent uses approved MCP servers for customer lookup, ticket updates, and internal documentation. OAuth is enabled, and the production servers are on an allowlist.
The security review nevertheless identifies four control questions.
First, an old development MCP server still holds a credential capable of reaching a production service. That creates an MCP09 shadow-server question and an MCP01 credential-lifecycle question.
Second, one tool's metadata can change after the initial approval process without triggering a new security review. The tool remains “approved,” but its behavior contract is no longer demonstrably the one that was reviewed. That is the type of condition MCP03 is intended to surface.
Third, several actions execute through a shared service identity. The user is authenticated correctly, but the downstream application cannot always determine whether that specific user was entitled to the requested object or action. That turns successful OAuth into an MCP02 and MCP07 authorization problem.
Finally, logs show the MCP server and downstream API call but do not reliably preserve the originating user and authorization decision. If something goes wrong, the organization may know what happened without being able to prove who requested it or why it was permitted. That is an MCP08 evidence problem.
No single observation means “MCP was compromised.” Together they reveal a weak trust path. The business consequences could include unauthorized customer-impacting actions, a delayed enterprise security review, expensive IAM redesign shortly before launch, and an incident investigation with incomplete attribution.
The remediation plan would be equally cross-functional: remove or isolate unapproved servers, rotate and narrow credentials, bind actions to the originating user's authority, place tool metadata under integrity/change control and correlate user, agent, server, tool and downstream events in the audit trail.
This scenario is hypothetical and illustrative. It is not a client case study and contains no working exploit sequence.
Map MCP Risks to Current OWASP, Agentic and NIST Guidance
Framework mapping needs a version label in 2026. The current OWASP GenAI LLM Top 10 is the 2026 edition, even though the MCP beta categories themselves still carry MCP01:2025 through MCP10:2025 identifiers.
For an MCP-focused assessment, the most useful cross-mapping is thematic rather than pretending every category has a perfect one-to-one equivalent.
| MCP control theme | Relevant current OWASP GenAI LLM risks | Relevant Agentic risks | NIST AI RMF use |
|---|---|---|---|
| MCP01, MCP02, MCP07: identity, tokens and privilege | LLM02:2026 Sensitive Information Disclosure; LLM03:2026 Excessive Agency | ASI03 Identity and Privilege Abuse | GOVERN ownership; MAP identities and authority; MEASURE authorization effectiveness |
| MCP03, MCP05, MCP06: tools, execution and intent | LLM01:2026 Prompt Injection; LLM03:2026 Excessive Agency; LLM10:2026 Improper Output Handling | ASI02 Tool Misuse and Exploitation | MAP tool/action paths; MEASURE prohibited behavior; MANAGE high-impact controls |
| MCP04, MCP09: supply chain and unapproved servers | LLM04:2026 Supply Chain | Agentic supply-chain and rogue-component concerns | GOVERN approved inventory; MAP third parties and dependencies; MANAGE change control |
| MCP08, MCP10: telemetry and context | LLM02:2026 Sensitive Information Disclosure; LLM08:2026 Hidden Context Exposure | Context and workflow integrity concerns | MEASURE evidence and monitoring; MANAGE response, remediation and reassessment |
The OWASP Agentic Skills Top 10 buyer test plan covers a neighboring but different layer. MCP governs the protocol/tool connection. Skills can determine how multiple tools are selected and sequenced into a workflow. An organization using both should scope both rather than assuming one framework subsumes the other.
For governance evidence, our NIST AI RMF evidence mapping guide provides the broader structure. In MCP terms, GOVERN defines ownership and the approved server policy; MAP inventories servers, tools, identities and downstream authority; MEASURE contains the test evidence; and MANAGE records remediation, residual risk and retesting.
NIST currently states that AI RMF 1.0 is being revised. That makes the same versioning discipline important here: reports should state which NIST release or profile was used instead of making an open-ended claim of “NIST compliance.” A penetration test supplies evidence for risk management. It does not create a compliance certification.
What Leadership Should Decide Before the Assessment
The most valuable scoping decisions are not technical test cases. They are decisions about what evidence the business needs and how much authority it is willing to expose.
- Pin the framework and protocol versions. Record the MCP Top 10 beta version, deployed MCP protocol/SDK versions, OWASP GenAI LLM version, and NIST reference used in the final report.
- Define the real MCP inventory. Include production servers, local or developer-operated servers that can reach production data or credentials, tool registries, and any externally managed MCP service.
- Classify actions by consequence. Separate read-only functions from data modification, external communication, privilege changes, financial actions, production changes and irreversible operations.
- Require positive and negative authorization evidence. A test should prove legitimate workflows succeed and prohibited combinations of role, tenant, object and action fail.
- Agree on report evidence before testing. Security, compliance and procurement may need different outputs: technical findings, architecture inventory, OWASP mappings, management summary, remediation ownership and retest status. Teams evaluating reporting depth can also review redacted sample penetration testing reports.
- Set material-change retest triggers. New servers, high-impact tools, changed scopes, identity redesign, registry changes, major protocol/SDK upgrades and new external-context sources should trigger reassessment rather than waiting automatically for the next annual test.
- Define the production gate. Decide which findings block launch, which can be accepted temporarily, and who has authority to accept residual MCP risk.
This is the difference between “testing against a Top 10” and using the Top 10 to make a defensible security decision. The framework gives the categories. The penetration-test scope has to connect them to the architecture, business impact, and evidence your organization actually needs.
Frequently Asked Questions About OWASP MCP Top 10 Testing
Is the OWASP MCP Top 10 final?
No. OWASP currently describes the MCP Top 10 as version v0.1 in Phase 3 beta and pilot testing. Organizations can use it now as a risk and scoping framework, but contracts and reports should record the exact version because category wording may evolve.
Does OWASP MCP Top 10 testing replace an AI penetration test?
No. MCP testing focuses on the protocol and tool boundary. A broader AI penetration test may also need to cover model behavior, RAG, direct and indirect prompt injection, memory, multi-step agent behavior and the traditional web, API or cloud surfaces surrounding the system.
Does OAuth satisfy MCP01 and MCP07?
No. OAuth can provide authentication and delegated credentials, but the assessment still needs to verify token audience, lifetime, scope, revocation and whether each downstream action is authorized for the originating user, tenant, object and operation.
Should development and local MCP servers be included?
They should be considered whenever they can obtain production credentials, access production data, influence approved agents or be used as a route around the official MCP inventory. Discovering those unsanctioned paths is part of the value of testing MCP09.
What evidence should we give an enterprise customer asking about the MCP Top 10?
A useful evidence package normally includes the framework version, tested architecture and inventory, scope/exclusions, risk-rated findings, sanitized proof, category mappings, remediation ownership, residual-risk decisions and retest status. The level of detail shared externally should match contractual and confidentiality requirements.
How often should MCP security be retested?
Use material changes as the trigger. New servers, tools, scopes, identities, registries, protocol versions or high-impact workflows can change the trust model even when the core AI model remains the same. An annual test can still be useful, but it should not be the only trigger.
How is an MCP server pentest different from a standard API pentest?
An API pentest remains important for authentication, authorization, input handling, business logic and downstream services. MCP-specific testing adds model-mediated tool discovery and selection, tool metadata trust, delegated identity, context boundaries, shadow-server discovery and the end-to-end relationship between an agent's decision and the resulting API action.
Conclusion
For a team rolling MCP into production, the useful question is no longer simply whether the servers authenticate successfully. It is whether leadership can prove that credentials are scoped correctly, tools remain trustworthy, prohibited actions fail, context stays within its intended boundary, unapproved servers are visible, and every high-impact action is attributable.
If an enterprise review, MCP rollout, or vendor questionnaire is creating that requirement, Pentest Testing Corp can scope an MCP-focused AI penetration testing assessment around your actual clients, servers, tools, identities, and downstream systems. You can also book a scoping call at https://calendly.com/shofiur-pentesttesting/30min.
