Topic starter
12/07/2026 12:20 pm
TL;DR: P0 Security argues that MCP gateways can authenticate agent calls and filter tool names or arguments, but they cannot reliably authorise opaque command strings, nested query languages, or fan-out operations inside downstream systems. The practical control point remains the resource owner’s native IAM, with just-in-time, session-scoped credentials preventing shadow authorisation.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “From MCP Tool Filtering to Runtime Access Control”.
Key questions
Q: What breaks when MCP tool filtering is used as access control for AI agents?
A: It breaks at the authorisation boundary.
Q: When should teams prioritise native IAM over MCP gateway rules?
A: Teams should prioritise native IAM whenever the tool wraps an existing command language, query language, or privileged API.
Q: What signs show an MCP gateway is drifting into shadow IAM?
A: Common warning signs include parsing CLI syntax, mirroring branch or resource policies, and maintaining separate allowlists for tool names and arguments that must stay in lockstep with another platform’s permissions model.
Practitioner guidance
- Separate mediation from enforcement Use the MCP gateway for authentication, request logging, and approval brokering, but move authorisation to the downstream service that owns the resource and the policy.
- Eliminate standing broad credentials Replace shared service accounts and borrowed human logins with session-scoped credentials that expire with the approved task and cannot outlive the session.
- Scope access at the resource owner Define permissions in the cloud, CRM, or database control plane so the native IAM engine can evaluate the exact operation, resource, and context.
Bottom line: MCP gateways can broker AI agent requests, but they cannot replace downstream authorisation when the tool hides complex commands or fan-out behaviour.
What's in the full article
P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Examples of raw command strings, SOQL queries, and SQL statements that defeat tool-name allowlists
- The full explanation of why gateway-side argument parsing becomes a shadow IAM model
- The request flow for intent-based, just-in-time access and federated session credentials
- The distinction between gateway admission checks and native downstream authorisation
👉 Read P0 Security's analysis of why MCP tool filtering is not access control →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/07/2026 12:33 pm
MCP tool filtering is a request gate, not an authorisation boundary: The gateway can authenticate the caller and record the request, but it cannot reliably decide whether a raw command string or query will remain safe after the downstream system interprets it. That distinction matters because real privilege lives in the resource owner’s policy model, not in the protocol envelope. Practitioners should stop treating tool allowlists as equivalent to enforcement.
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: What should security teams do when an AI agent needs privileged downstream access?
A: They should issue short-lived, session-scoped credentials tied to the approved task and let the resource owner enforce the operation natively. That keeps the agent’s access narrow, limits blast radius, and avoids giving a gateway the impossible job of re-authorising hidden downstream behaviour it cannot fully observe.
👉 Read our full editorial: MCP tool filtering is not access control for AI agents