MCP tool filtering is not access control for AI agents

At a glance

What this is: This analysis explains why MCP tool filtering is not true access control for AI agents, because real authorisation still lives in downstream IAM and policy engines.

Why it matters: It matters because identity teams need to place enforcement at the resource owner, not at the protocol gateway, when AI agents act through MCP into cloud, CRM, and database systems.

👉 Read P0 Security's analysis of why MCP tool filtering is not access control

Context

Model Context Protocol gives AI agents a uniform way to call tools, but the protocol itself does not decide whether a specific action is allowed. In enterprise deployments, an MCP gateway often sits between the agent and the tool server, which creates the appearance of a control point even when the real authorisation decision is still happening elsewhere.

The core governance gap is simple: tool naming and argument filtering are not the same as policy enforcement. For AI agents, the identity question is not whether a call can be forwarded, but whether the downstream resource owner can still apply its own IAM rules to the exact operation the agent is trying to perform.

This is why the article keeps returning to runtime access control, not protocol mediation. Once a tool call hides a full command language, query language, or fan-out operation inside a single request, gateway-side rules can only approximate authorisation and are prone to drift from the system that actually owns the privilege model.

Key questions

Q: What breaks when MCP tool filtering is used as access control for AI agents?

A: It breaks at the authorisation boundary. Tool filtering can reject obvious categories, but it cannot reliably evaluate the final effect of raw command strings, query languages, or batched operations. The downstream system still owns the real privilege model, so gateway-only rules create a false sense of control instead of enforcing actual access decisions.

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. In those cases, the downstream service already knows the full permission model and can evaluate the request more accurately than a proxy rule engine can. Gateway rules are useful for admission and logging, not for final authorisation.

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. If the gateway needs constant policy parity work, it is no longer just brokering requests. It is acting as a stale second IAM system.

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.

Technical breakdown

Why MCP tool names do not define the real permission boundary

An MCP tool name is only a routing label. If a server exposes one tool that accepts a raw command string, query, or SQL statement, then the entire downstream action space is compressed into one parameter. A gateway can say yes or no to the category, but it cannot inspect every possible outcome hidden inside that string with the same fidelity as the resource owner’s own policy engine. That is why a tool-name allowlist is not authorisation. It is a coarse admission check wrapped around a much larger permission problem.

Practical implication: Treat MCP tool filtering as request triage, not as the enforcement layer for privileged operations.

Why nested query languages create a shadow IAM problem

When a gateway tries to parse CLI syntax, SOQL, or SQL before authorising a call, it must replicate another system’s semantics, quoting rules, and edge cases. That quickly becomes a shadow IAM model, because the gateway is attempting to restate the downstream system’s own privilege logic in a parallel rule engine. The result is always incomplete or stale relative to the native policy source. In practice, the more expressive the downstream language, the less trustworthy gateway-side argument filtering becomes as an authorisation control.

Practical implication: Place the decision where the native policy language already exists, not in a duplicate rule engine at the gateway.

Why fan-out breaks envelope-level authorisation

A single MCP request can expand into many downstream operations, especially when a tool batches commands or paginates through resources. The gateway sees one envelope, but the resource owner sees many discrete actions with potentially different privilege implications. That means authorisation applied only at the MCP layer can never fully account for the final effect of the call. The protocol can describe the request, but it does not expose every internal operation that request triggers across the target system.

Practical implication: Use session-scoped credentials so every downstream operation is governed by the resource owner’s own checks, not by a proxy’s approximation.

Threat narrative

Attacker objective: The objective is to make an AI agent perform privileged downstream actions that exceed the intended scope of the original request.

1. Entry occurs when an agent reaches production tools through an MCP gateway that authenticates the caller but does not own downstream policy enforcement.
2. Credential abuse emerges when the gateway relies on static or broadly scoped credentials, giving every session the same effective privilege surface.
3. Escalation happens when opaque command strings, nested queries, or batched operations expand one approved call into multiple privileged downstream actions.
4. Impact is the ability to change cloud, CRM, or database state beyond the intent originally approved for that agent session.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Shadow IAM appears whenever a gateway tries to re-implement downstream policy: Once a proxy starts parsing AWS CLI, SQL, or SOQL to infer intent, it has taken on a second authorisation system it does not own. That system will drift, because the real service changes underneath it and the gateway never has full semantic parity. The implication is not merely operational burden, but a broken governance assumption: the proxy cannot stay authoritative over permissions it does not control.

Just-in-time, session-scoped credentials are the real runtime control plane: The article correctly places enforcement at the resource owner because AI agents act through non-human identities that can be scoped per session. That aligns with NHI governance, where standing privilege is the problem and ephemeral access is the control. The practitioner takeaway is to think in terms of minted access, not filtered intent.

Fine-grained tools help auditability, but they do not move the trust decision: Narrow tool schemas reduce ambiguity, yet the authorisation question remains the same whether the call is one field or six. The key control is still whether the downstream operation is allowed under native IAM for that specific resource, branch, account, or record. Teams should resist the false comfort of cleaner schemas when the enforcement model is unchanged.

Protocol mediation and privilege enforcement belong to different layers of the stack: MCP gateways should authenticate, log, and broker approval, but downstream systems must enforce the operation itself. That separation is especially important as agentic AI expands into cloud and SaaS systems where resource ownership, conditional access, and effective permissions already exist. The field now needs governance models that preserve that separation rather than blur it.

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

Runtime access control has to follow the privilege, not the protocol: When an AI agent reaches cloud or SaaS systems through MCP, the relevant control is the resource owner’s IAM engine, not the proxy that forwarded the call. That is the governance shift practitioners need to absorb before agentic access becomes normalised across production workflows.

Opaque command wrappers turn identity into a session problem, not a static account problem: Once a tool hides the real operation inside a string or batch envelope, the safest control is a credential that exists only for that one task. Session-scoped access reduces the damage radius when the agent’s intent or the downstream effect turns out to be broader than expected.

For practitioners

• 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.
• Audit tool schemas for hidden fan-out Review each MCP tool for raw command strings, query languages, batch mode, and pagination paths that can expand one call into many privileged actions.
• Test for shadow authorisation drift Compare gateway rules against the downstream system’s actual permissions model whenever the tool wraps an existing command language or API permission boundary.

Key takeaways

• MCP gateways can broker AI agent requests, but they cannot replace downstream authorisation when the tool hides complex commands or fan-out behaviour.
• Gateway-side filtering becomes fragile when it has to interpret command languages, nested queries, or batching that the resource owner already governs natively.
• Session-scoped credentials and native IAM are the controls that keep agentic access bounded when protocol mediation cannot see the full effect of a request.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Shadow IAM: Shadow IAM refers to identity and access paths created outside the central identity program, usually through local SaaS accounts, ad hoc OAuth grants, or application-specific permissions. These entitlements often survive offboarding because they are not governed by the same lifecycle controls as directory-backed access.
• Session-Scoped Credentials: Session-scoped credentials are temporary access tokens tied to a specific workflow or user session. They limit how long an AI agent can act, reduce credential reuse, and support fine-grained control across tools. In regulated environments, they help keep automation aligned to the original authorization boundary.
• Fan-Out Architecture: Fan-out architecture is a processing pattern that splits work into many parallel tasks so a system can handle high volume without a single bottleneck. For security pipelines, it supports scalable ingestion, independent retries, and workload isolation across queues, workers, and analysis stages.

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

👉 The full P0 Security post details where runtime enforcement belongs and why session-scoped credentials matter.

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 building or maturing an IAM programme, it is worth exploring.