Should organisations test MCP security separately from traditional penetration testing?

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.

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?