Notifications
Clear all
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.
NHIMG editorial — based on content published by Aembit: MCP security testing and how to verify the specification’s critical controls
By the numbers:
- Non-human identities now outnumber humans by as much as 144:1.
- That ratio grew 56% in just one year.
Questions worth separating out
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 MCP systems make identity governance harder for NHI teams?
A: MCP systems make governance harder because non-human identities can move through several consent and tool layers before any user-facing action occurs.
Q: How do security teams know whether MCP authorization is actually working?
A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently.
Practitioner guidance
- Test consent as a relationship, not a checkbox. Simulate multiple client applications with different privilege levels and verify that each client receives and retains only its own consent grants.
- Validate token flow at every trust boundary. Trace tokens through the MCP stack and confirm that each server validates them directly against the authorization server rather than relaying them.
- Lock down discovery, redirects, and local execution paths. Block internal IPs, loopback targets, and link-local addresses in discovery fields, enforce exact redirect URI matching, and sanitize local file and command inputs.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step test cases for confused deputy, token passthrough, SSRF, and session-hijacking scenarios.
- Concrete validation checks for redirect URI matching, OAuth state handling, and audience restriction enforcement.
- Observability requirements for MCP events, including the specific log fields needed for SIEM correlation.
- Guidance on local-server transport choices, including when stdio reduces exposure and when it does not.
👉 Read Aembit’s analysis of MCP security testing and trust-boundary failures →
MCP security testing: are your controls catching trust-boundary failures?
Explore further
06/06/2026 3:40 am
Relationship testing is now a first-order identity control for MCP. MCP does not fail mainly at the endpoint layer. It fails where a trusted client, a token, and a tool all meet under different authorization expectations. That means the real governance object is the relationship between identity, client, and resource, not the request alone. Practitioners should treat per-client consent as a control boundary, not a UX detail.
A few things that frame the scale:
- Non-human identities now outnumber humans by as much as 144:1, according to AI Agents: The New Attack Surface report.
- A separate finding shows 80% of organisations report AI agents have already acted beyond intended scope, which is why protocol-level identity testing cannot be treated as optional.
A question worth separating out:
Q: Who is accountable when an MCP client grants access too broadly?
A: Accountability sits with the team operating the client, the server, and the authorization policy, because MCP failures usually come from broken relationship handling rather than a single bad request. Security and platform teams should document who owns consent registration, token validation, and local execution restrictions.
👉 Read our full editorial: MCP security testing must move beyond standard API assumptions
