Topic starter
06/06/2026 2:09 am
TL;DR: MCP breaks standard API assumptions by introducing dynamic agent, server, and tool interactions across multiple trust boundaries, so generic scanners miss confused deputy, token passthrough, SSRF, and authorization-pattern failures, according to Aembit. The security model now depends on validating relationships, token flow, and per-request authorization, not just endpoint responses.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “MCP Security Testing: Tools and Methodologies”.
By the numbers:
- MCP environments are dominated by non-human identities, and those identities now outnumber humans by as much as 144:1.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP security testing fails when it assumes ordinary API behaviour, because the real risk is misbinding authority across clients, tokens, and tools.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 3:40 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security testing must move beyond standard API assumptions
This post was modified 1 day ago by NHI Mgmt Group