The OWASP MCP Top 10 is useful because it gives teams names for risks that sit between an AI application and the systems the application can actually use.
But there’s a trap in treating MCP01 through MCP10 as ten checklist items.
A Model Context Protocol deployment is a chain of trust:
User → agent → MCP client → MCP server → tool → downstream system → business action.
Testing only the server, OAuth configuration, or individual tools can leave important authorization and context failures untouched.
The better approach is to convert each OWASP MCP category into a test objective, an enforcement question, and an evidence requirement.
MCP01, MCP02 and MCP07: identity and authority
Token Mismanagement & Secret Exposure, Privilege Escalation via Scope Creep, and Insufficient Authentication & Authorization all converge on a similar question:
Does the identity reaching the downstream system still represent the authority of the originating user?
A defensible assessment should examine:
- token audience and scope
- token storage and lifecycle
- refresh and revocation
- delegated identities
- service identities
- user roles
- tenant boundaries
- tool-level authorization
- downstream resource authorization
The important negative test is not whether a valid user can call a valid tool.
It is whether combinations that should be prohibited are actually rejected.
For example:
- valid user, wrong tenant
- valid role, privileged tool
- approved tool, unauthorized object
- valid MCP server, excessive downstream scope
The useful deliverable is an identity-and-authorization matrix showing both successful permitted actions and rejected prohibited actions.
That evidence is far more meaningful than a line saying “MCP07 tested.”
MCP03, MCP05 and MCP06: tools and workflow integrity
Tool Poisoning, Command Injection & Execution, and Intent Flow Subversion deal with a different boundary.
MCP tools are not passive API definitions. Names, descriptions, schemas, metadata, parameters, and external context can influence what an AI system chooses to do.
Testing should therefore ask:
- Can tool metadata change after approval?
- Is tool provenance recorded?
- Are execution-capable parameters constrained server-side?
- Can external content alter the intended workflow?
- Are high-impact actions independently authorized?
- Can an approval step be bypassed by changing the flow rather than directly attacking the endpoint?
The goal is not to build an impressive prompt-injection demo.
The goal is to verify that business intent survives untrusted input.
If the organization expects an agent to update a support ticket but never modify production infrastructure, that separation should be enforced outside the model.
MCP04 and MCP09: the declared inventory may not be the real inventory
Software Supply Chain Attacks & Dependency Tampering and Shadow MCP Servers introduce an operational problem.
Security teams may have a list of approved production MCP servers while local, development, experimental, or externally managed servers continue to exist.
Some may still retain credentials.
Some may connect to production services.
Some may use dependencies or SDK versions outside the approved baseline.
A test should reconcile the declared inventory with the reachable inventory.
That means examining:
- servers
- environments
- SDK versions
- dependencies
- package sources
- registries
- installation paths
- update mechanisms
- credentials
- connections to production resources
The remediation here may be partly technical and partly governance.
Removing one obsolete server is easy.
Creating ownership, registration, approval, and revocation processes across dozens of teams is not.
That difference matters when findings are prioritized.
MCP08 and MCP10: can you explain what happened afterward?
Lack of Audit and Telemetry and Context Injection & Over-Sharing are often underestimated because the system may appear to work normally.
The question is whether the organization can reconstruct an event after something goes wrong.
A useful audit path should correlate:
originating user → agent → MCP server → selected tool → authorization result → downstream effect.
Recording only the API request or only the MCP server event may leave the security team unable to establish who initiated an action or why it was permitted.
Context boundaries deserve the same attention.
Testing should examine whether data can cross:
- tenants
- users
- sessions
- tasks
- environments
- data classifications
The correct evidence is not “logging enabled.”
It is a reconstructed end-to-end trace plus documented gaps.
What should be in scope before testing starts?
An MCP assessment becomes much more reliable when the scope identifies the actual architecture before testing begins.
At minimum, document:
- MCP clients and servers.
- Production, staging, development, and local environments.
- Protocol and SDK versions.
- Every exposed tool.
- Human, workload, delegated, and service identities.
- Roles and tenant boundaries.
- Read, write, administrative, and irreversible actions.
- Credential issuance and revocation.
- Tool registries and update mechanisms.
- External content or RAG sources.
- Downstream APIs, databases, SaaS systems, and cloud resources.
- Logging and emergency-disable controls.
This inventory determines the real workload.
The fact that the OWASP framework contains ten categories does not mean every deployment requires the same testing effort.
Architecture drives remediation cost
Consider two systems.
System A has five MCP servers, but every tool is read-only and operates under one tightly controlled internal workflow.
System B has two servers but several user roles, multiple customer tenants, write-capable tools, shared identities, external context, and administrative downstream APIs.
System B can easily require more testing.
The multiplication is across:
servers × tools × identities × roles × tenants × data classes × action types.
That is also why remediation effort varies dramatically.
A missing logging field may be a configuration fix.
Replacing a shared production service identity with user-bound authorization can require architectural work across IAM, APIs, product logic, and operational processes.
Pentest reports should distinguish between those two classes of remediation.
Where MCP testing fits with broader AI security
OWASP MCP Top 10 testing is protocol-focused.
It does not replace:
- AI/LLM penetration testing
- API penetration testing
- prompt injection testing
- agentic workflow testing
- software supply-chain review
For an MCP-enabled AI agent, those layers intersect.
A broader AI penetration test may examine prompts, retrieval sources, model behavior, tool permissions, APIs, identities, and downstream effects.
The MCP assessment adds focused evidence around the standardized protocol and tool boundary.
Teams using reusable agent skills may also need separate coverage of skill provenance, permissions, sequencing, update paths, and runtime isolation.
The architecture determines the frameworks, not the other way around.
Business impact still determines priority
Technical severity alone does not tell leadership what should block production.
The most useful findings answer questions such as:
- Could one customer’s authority reach another customer’s data?
- Can a lower-privileged user trigger a higher-impact tool?
- Can an unregistered server retain production access?
- Can tool behavior change after security approval?
- Can the organization revoke compromised access quickly?
- Can investigators attribute a sensitive action afterward?
- Would remediation require a configuration change or an IAM redesign?
Those answers influence release timing, enterprise security reviews, audit evidence, engineering workload, and residual-risk acceptance.
That is ultimately what the OWASP MCP Top 10 should enable.
Not ten checked boxes.
A defensible statement about which identities, tools, contexts, and actions were actually tested.
Originally published with the complete MCP01-MCP10 buyer matrix and current framework-version context: https://www.pentesttesting.com/owasp-mcp-top-10-testing/
The current canonical article also notes that the OWASP MCP project remains a beta framework and that reports should record exact framework and protocol versions rather than make an open-ended claim of “OWASP MCP Top 10 compliance.”
Top comments (0)