Yes. Traditional pentesting finds infrastructure and application flaws, but MCP testing checks whether context handling, tool chaining, and validation logic can be manipulated. Both matter, but they answer different questions. Agentic systems need assurance over runtime decision paths, not only over exposed services.
Why MCP Needs Its Own Security Test Plan
MCP changes the security question from “can someone reach the service?” to “can the runtime be manipulated into doing the wrong thing?” That is a different assurance target. Traditional pentesting is still valuable for exposed interfaces, transport weaknesses, and obvious misconfigurations, but MCP adds context and action pathways that can fail even when the underlying service looks sound.
The practical issue is that MCP systems often sit between a model, tools, and downstream services. That creates extra places for policy drift, malformed context, confused-deputy behaviour, and unsafe delegation. Security testing therefore has to examine how the protocol behaves under adversarial inputs, not only whether the server is reachable or the endpoint is hardened.
What Traditional Pentesting Misses in MCP Workflows
Classic penetration testing is usually strongest at finding network exposure, authentication gaps, injection points, weak TLS handling, and misconfigured infrastructure. Those findings matter, and they should still be tested. But they do not fully answer whether the MCP runtime will preserve the right context, validate tool requests correctly, or prevent the model from being steered into an unintended sequence of actions.
That gap matters because MCP risk often emerges from composition. A single component may be secure in isolation, yet the chain of model prompt, tool selection, parameter handling, and downstream execution can still be unsafe. Security assurance has to follow the decision path, including validation rules, trust boundaries, and what happens when the tool output is ambiguous, malicious, or unexpectedly structured.
A useful comparison is that pentesting tends to validate the perimeter and the service surface, while MCP testing validates the behaviour of the orchestration layer. Both can be breached, but they fail in different ways and for different reasons. If you only test one, you can miss the other entirely.
How to Structure MCP Testing Without Treating It Like Generic AppSec
The most effective MCP test programs combine protocol-aware checks with adversarial workflow testing. That means examining authorization boundaries, token handling, tool invocation rules, parameter validation, and whether context can be poisoned or redirected across successive calls. MCP Security Guide is a useful reference point for the specific controls that tend to matter most, including OAuth-based authorization, token passthrough, tool poisoning, and gateway design.
The test plan should also include agentic failure modes. For example, can a malicious instruction change the chosen tool, alter the order of operations, or cause the system to act on stale or overbroad context? Those scenarios are materially different from the usual web application checks that focus on a single request-response boundary. They are closer to runtime assurance than to perimeter validation.
For teams that already have application security testing, the easiest mistake is to assume coverage transfers automatically. It usually does not. A standard web test may prove the endpoint rejects invalid input, but MCP testing asks whether a valid-looking sequence can still be abused to bypass the intended decision logic.
Risk and Threat Considerations
MCP introduces a higher-risk failure mode because the attack surface includes runtime decisions, delegated tool use, and chained trust. An attacker does not always need to break the underlying service if they can influence the context that drives it, which makes indirect manipulation and confused-deputy behaviour especially important.
Failure mechanism: A malicious or malformed prompt, tool response, or context update can steer the agent into invoking an unintended tool, forwarding excessive data, or accepting unsafe parameters that pass basic infrastructure tests.
Impact: The result can be unauthorized actions, data exposure, privilege abuse, or downstream compromise of connected systems, even when the exposed service itself appears properly configured.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tests must catch unsafe tool invocation and chaining. |
| ASI03 — Identity & Privilege Abuse | MCP can amplify delegated authority across agent actions. | |
| Recommendation — Test tool selection and chaining for abuse paths. Constrain agent authority and verify privilege boundaries. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP testing must verify action-level authorization, not just reachability. |
| API8 — Security Misconfiguration | MCP deployments can fail through gateway, token, or transport misconfiguration. | |
| Recommendation — Verify each tool action is authorized at function level. Harden MCP deployments and validate transport settings. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | MCP needs dedicated testing beyond routine pentesting to validate runtime behaviour. |
| IA-2 — Identification and Authentication (Organizational Users) | MCP assurance depends on correct authentication for human-controlled access paths. | |
| AC-6 — Least Privilege | MCP tool use must be limited to reduce delegated-action blast radius. | |
| Recommendation — Add MCP-specific adversarial test cases to evaluation. Verify authentication before allowing privileged MCP access. Minimize tool permissions and scope each action narrowly. | ||
| ISO/IEC 27001:2022 | A.8.29 — Security testing in development and acceptance | MCP requires testing that goes beyond standard vulnerability scanning. |
| A.8.9 — Configuration management | MCP weaknesses often arise from mis-set gateways, tokens, and trust paths. | |
| Recommendation — Include protocol-specific security tests in acceptance checks. Control MCP configuration changes and review trust settings. | ||
Practitioner Guidance
What to prioritise: Test the decision path first, not the banner. The highest-value MCP findings usually come from authorization mistakes, unsafe delegation, and context-handling flaws rather than from generic transport issues.
What to verify: Confirm that each tool call is constrained by explicit policy, that inputs are validated at the protocol boundary, and that a tool can only act within the scope the runtime actually intended. If the test cannot show why a call was allowed, the control is too weak to trust.
Decision rule: If the question is “can the system be reached?”, pentesting is appropriate. If the question is “can the agent be manipulated into taking the wrong action?”, MCP-specific testing is required, and it should be run alongside, not instead of, traditional testing.
Practitioner takeaway: Treat MCP assurance as runtime behaviour testing, because the control failure is often not exploitation of the server itself but manipulation of the context and tool chain that the server is meant to govern.
Related resources from NHI Mgmt Group
- Should organisations test MCP security with offensive methods or rely on static review?
- What is the difference between traditional penetration testing and ongoing bug bounty programs for SaaS security?
- When should organisations choose PTaaS over a traditional penetration test?
- When should organisations combine penetration testing with automated application security scans?