MCP security testing must move beyond standard API assumptions

At a glance

What this is: This article explains why Model Context Protocol security testing fails when treated like ordinary API testing, with trust-boundary checks and per-client authorization emerging as the central requirement.

Why it matters: IAM and security teams need MCP-specific validation because agent, server, and tool relationships change how consent, token handling, and authorization must be tested across NHI and autonomous workflows.

By the numbers:

• MCP environments are dominated by non-human identities, and those identities now outnumber humans by as much as 144:1.

Context

MCP security testing is about validating how identity and authorisation behave across a protocol built for agents, servers, and tools rather than fixed request-response APIs. Standard scanner logic breaks when consent is per client, token handling is constrained by protocol rules, and trust boundaries move between components during execution.

The governance gap is that traditional API testing checks endpoints in isolation, while MCP risk emerges from relationships between identities, tokens, and downstream actions. That makes this an NHI control problem first and an API testing problem second, because the subject is not just traffic inspection but whether non-human identities are allowed to act through the correct authority at each hop.

For practitioners, the article points to a testing model that must simulate multiple clients, trace token flow, and verify request-level authorization under protocol-specific constraints. The starting point is atypical only if a team still assumes that ordinary API auth tests are enough to cover agent-orchestrated access.

Key questions

Q: What breaks when MCP security is tested like a standard API?

A: Standard API testing misses relationship-based failures such as confused deputy abuse, token passthrough, and trust-boundary violations between clients and servers. MCP security depends on per-client consent, exact token audience validation, and request-level checks, so endpoint-only scans can report false confidence while the protocol remains exploitable.

Q: Why do confused deputy failures matter so much in MCP environments?

A: Because the protocol lets one client request actions through another client’s authority if consent is not bound to the specific application. That turns a user approval into a reusable privilege path, which is exactly what attackers exploit when they can cross client boundaries without being challenged.

Q: How do teams know whether MCP token handling is actually safe?

A: By verifying that every hop validates the token directly against the authorisation server and rejects passthrough, incorrect audience values, and session-only substitutes. If a control only proves that a token exists somewhere in the flow, it has not proven that the right boundary enforced it.

Q: How should security teams govern MCP access in agentic workflows?

A: Security teams should govern MCP access as delegated identity, not simple application connectivity. That means binding consent to the client, validating the token audience, refusing passthrough, and constraining each tool call to the narrowest possible scope. If those controls are not enforced per request, an authorised login can become an unauthorised action path.

Technical breakdown

Why standard API scanners miss MCP trust-boundary failures

Standard API scanners assume a stable client talking to a stateless endpoint, with authentication and authorisation largely inferred from request and response behaviour. MCP breaks that model because the useful security question is not only whether one endpoint responds correctly, but whether the server preserves the right relationship between client, user consent, token audience, and downstream tool use. The protocol’s attack surface lives in those relationships. A scan that never simulates multiple clients, token forwarding paths, or consent mismatches will miss the failures the protocol is designed to constrain.

Practical implication: Test MCP flows as relationship checks, not endpoint checks.

Confused deputy and token passthrough are protocol-level control failures

The confused deputy problem appears when a legitimate client is tricked into using authority it should not apply on another client’s behalf. Token passthrough is a separate but related failure where a server forwards credentials instead of validating them directly at each trust boundary. In MCP, both failures matter because the protocol explicitly expects per-client consent and direct token validation. Generic OAuth or API tests often confirm that a token exists, but not that the correct actor is using it for the correct purpose.

Practical implication: Verify per-client consent and direct token validation at every hop.

Per-request authorization and SSRF protections are mandatory in MCP

MCP security also depends on rejecting session-only thinking and unsafe metadata handling. If a server relies on a browser session or shared login state instead of validating tokens on each request, it weakens the protocol’s authority model. Likewise, metadata fields such as discovery URLs and token endpoints must be treated as hostile input because they can drive SSRF if internal, loopback, or rebinding destinations are accepted. In practice, MCP testing has to cover both authorization decisions and input-driven network fetches, because the exploit path often crosses both.

Practical implication: Enforce request-level token checks and block unsafe URL discovery paths.

NHI Mgmt Group analysis

MCP testing exposes a trust-boundary governance gap, not just an API hardening gap. The protocol changes where authority is evaluated because agents, servers, and tools all participate in the access path. That means the control surface is the relationship between identities and actions, not the individual endpoint response. Practitioners should treat MCP as a protocol that demands identity-aware validation at the boundary, not a broader version of REST testing.

Per-client consent is the named concept that most teams still under-test. MCP assumes the server can distinguish one client application from another and enforce what each client was authorised to do. The confused deputy problem shows why blanket user grants are not enough when a second client can piggyback on the first client’s authority. The implication is that consent becomes a client-specific governance object, not a single user approval event.

Token passthrough is a governance failure because it dissolves accountability between hops. If a server forwards tokens instead of validating them, it becomes impossible to prove which trust boundary actually accepted the credential. That breaks auditability, weakens authorisation intent, and creates a false sense of control when the token was never checked where it mattered. Practitioners need to see passthrough as an authority transfer problem, not a transport convenience.

MCP makes request-time authorisation more important than session state. The specification’s requirement for per-request token validation means session-only controls cannot stand in for real authorisation. That shifts governance from durable login state to immediate access decisions tied to the current request, current client, and current resource. Teams that keep treating sessions as the unit of trust will misread compliance and miss the actual attack path.

Identity-first testing is now part of MCP assurance because non-human identities dominate the environment. The article’s 144:1 ratio illustrates that the protocol is operating inside machine-heavy estates where tokens, attestation, and scoped access replace human-centric controls. That makes MCP testing a workload identity discipline as much as an application security exercise. Practitioners should align protocol testing with NHI governance rather than legacy user-login assumptions.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Per-client consent is becoming the MCP governance pivot. The protocol does not merely ask whether a user signed in. It asks whether the specific client, resource, and token path were authorised together, which is a much stricter control model for agent-orchestrated access.

Trust-boundary validation now has to replace endpoint-only testing. When agents, tools, and servers participate in the same workflow, the security question moves from response correctness to authority correctness. Teams should expect their testing and audit logic to follow the token and the client, not just the URL.

Session state is too weak to anchor MCP assurance. Request-level validation is the only control that survives client chaining, token forwarding, and dynamic tool orchestration. That makes MCP a useful forcing function for tighter NHI governance across machine-heavy estates.

For practitioners

• Simulate multiple MCP clients Build test cases with at least two clients carrying different consent levels, then verify the server rejects cross-client access when the same user identity is reused.
• Trace token flow at each hop Instrument the path from client to server to authorization server and confirm tokens are validated directly rather than forwarded through intermediaries.
• Test per-request validation Attempt requests that rely only on cookies or server-side session state and confirm they fail unless a valid token is checked on the current request.
• Validate discovery URLs and redirects Block internal IPs, loopback targets, link-local addresses, and DNS rebinding paths in OAuth metadata discovery fields before any fetch occurs.
• Constrain scopes to the workflow Review whether agents can perform write actions when their workflow only needs read access, and reject any scope expansion that is not operationally required.

Key takeaways

• MCP security testing fails when it assumes ordinary API behaviour, because the real risk is misbinding authority across clients, tokens, and tools.
• The protocol’s trust-boundary problems include confused deputy behaviour, token passthrough, SSRF paths, and session-state shortcuts that scanners often miss.
• Practitioners need request-level validation, per-client consent checks, and token-flow tracing to test MCP environments with any confidence.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
• Per-Request Verification: Per-request verification means every tool call or data action from an agent is checked at the moment it happens, not trusted because a session started correctly. This matters because agent behaviour can shift mid-task. Continuous verification helps detect misuse, prevents inherited session trust, and reduces the risk of hidden escalation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.