MCP tool filtering is not access control for AI agents

At a glance

What this is: This is an analysis of why MCP tool filtering fails as a substitute for runtime access control, and the central finding is that authorization must sit with the downstream resource owner.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly need to govern AI agents through real runtime permissions, not gateway-side approximations that drift from the systems they are trying to protect.

👉 Read P0 Security's analysis of MCP tool filtering and runtime access control

Context

MCP tool filtering has become a common answer to a harder problem: how to govern AI agents that can reach real infrastructure through a shared protocol. The issue is not whether a gateway can see the request, but whether it can make a correct access decision for a tool call whose real effect may be hidden inside a command string, query, or batch of downstream actions.

For identity programmes, this is a runtime access control problem, not a naming or routing problem. The article argues that tool-level allowlists and argument filters resemble authorization, but the actual decision still belongs to the system that owns the resource, where native IAM, policy inheritance, and effective permissions are already understood and continuously maintained.

The primary keyword here is MCP, but the practical focus is broader: AI agents, NHI governance, and just-in-time access. That combination puts pressure on how teams design session identity, approval, and enforcement when an agent is acting through a proxy rather than directly against the protected system.

Key questions

Q: How should security teams govern AI agents that use service accounts and MCP tools?

A: Start with ownership, then add runtime attribution and containment. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.

Q: Why do MCP tool allowlists fail to control agent access?

A: Because a tool name only tells you the category of action, not the effect of the specific request. One tool can hide harmless reads, privilege escalation, destructive commands, or batch operations, so a name-based allowlist cannot express the real authorization boundary.

Q: What do security teams get wrong about argument filtering in MCP gateways?

A: They assume that parsing the argument is the same as authorizing the action. In practice, the gateway would need to mirror the downstream system’s own policy logic, which creates shadow IAM that drifts from the real control plane and eventually makes the gateway unreliable.

Q: Who should own AI agent access decisions and lifecycle controls?

A: AI agent access decisions should be owned by the team that deploys and operates the agent, with identity governance and security functions enforcing policy and review. Ownership must be explicit because autonomous behaviour creates accountability gaps if nobody is responsible for the agent's permissions, monitoring, and offboarding.

Technical breakdown

Why tool names do not equal authorization in MCP

MCP exposes tools as requestable operations, but many servers collapse broad capability into a single tool name. A call such as call_aws can represent anything from listing buckets to attaching an AdministratorAccess policy, while a soqlQuery or execute_sql call can hide very different outcomes behind the same interface. A gateway can therefore decide only at category level unless it understands the full downstream grammar, which quickly becomes a second authorization system. That is not real access control. Real authorization depends on the specific operation, resource state, and effective permissions at the resource owner, not on the tool label.

Practical implication: treat tool filtering as request routing and audit support, not as the final authorization decision.

Why argument filtering turns into shadow IAM

Argument-aware filtering sounds stronger, but it inherits a parsing problem and a policy problem. The parsing problem is that CLI syntax, SOQL, and SQL all include quoting, escaping, wildcards, subqueries, and batch forms that a gateway must interpret perfectly before it can judge intent. The policy problem is that the gateway would still need to recreate native IAM logic, including permission boundaries, resource policies, branch protection, or service-specific evaluation rules. That creates shadow IAM, a parallel decision engine that is always behind the real one and will drift as the upstream service changes.

Practical implication: avoid duplicating downstream policy logic in the MCP layer unless the gateway can delegate the final decision back to the resource owner.

Why session-scoped identities matter more than shared service accounts

Most MCP deployments fail when one static identity is shared across all sessions or when a human’s own credentials are handed to the agent. Both patterns destroy scoping because every session inherits the same broad principal. Federation and just-in-time access change the model by minting a short-lived identity for the specific session, with entitlements shaped by approved intent. That is the only way to keep an agent from outliving the grant or reusing privilege outside the request that justified it. In NHI terms, the access grant becomes ephemeral, task-scoped, and revocable in the same window in which it was created.

Practical implication: move MCP access from shared standing credentials to federated, ephemeral identities tied to each approved session.

NHI Mgmt Group analysis

Tool-level filtering is not access control, it is request classification. The article shows that an MCP gateway can decide whether a request looks acceptable, but not whether the downstream action is actually permitted under the resource owner’s policy. That distinction matters because identity control only works when the enforcement point understands effective permissions, not just tool names or argument shapes. Practitioners should treat gateway filtering as a precondition to authorization, never as a substitute for it.

Shadow IAM is the real architectural failure in gateway-side policy engines. Once the gateway tries to interpret command strings, SQL, or SOQL for authorization, it begins recreating the cloud or SaaS provider’s own policy engine in parallel. That is a brittle control plane because it must stay in sync with another system’s permission model, resource inheritance, and edge cases. The implication is that the decision must remain with the resource owner, not with a proxy that is always one version behind.

Session-scoped identity is the correct NHI pattern for AI agents. The article’s most useful recommendation is not stricter filtering, but a different identity shape: federated, short-lived, and tied to the specific request. Shared service accounts and borrowed human credentials both create standing privilege in disguise, which is exactly what AI agents should not inherit. Practitioners should redesign agent access around ephemeral grants that expire with the task.

Just-in-time access is the control that matches agent runtime behaviour. Agents move too quickly and too variably for pre-provisioned, broad entitlements to remain safe for long. The right governance model assembles identity, credential, and scope at request time, then tears them down shortly after use. That approach does not merely reduce exposure. It aligns enforcement with the actual runtime window in which the agent operates.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• A separate finding from the same research showed 24,008 unique secrets exposed in MCP configuration files in 2025 alone.
• For a broader control view, the Ultimate Guide to NHIs and lifecycle processes for managing NHIs explains how ephemeral identity and offboarding reduce standing exposure.

What this signals

Runtime governance for AI agents will converge on identity lifecycle, not gateway syntax. As MCP adoption expands, security teams will be judged less on whether they can filter tool names and more on whether they can issue, scope, and revoke session identities fast enough for agent workloads. That makes lifecycle discipline the control plane, while the gateway becomes an observation layer rather than an enforcement boundary.

The practical signal for IAM and PAM teams is that agent access will need to look more like ephemeral privilege than like application onboarding. Where a shared account once hid complexity, it now hides risk. Programmes that can tie session approval to short-lived credentials, native downstream policy, and auditable offboarding will be the ones that avoid building a parallel authorization stack.

Shadow IAM: gateway-side policy engines that try to interpret downstream command strings will keep failing because they mirror a control plane they do not own. Teams should expect this pattern to appear first in cloud and database automation, then in SaaS integrations, and they should align reviews to native policy ownership rather than proxy-side rule counts.

For practitioners

• Delegate final authorization to the resource owner Keep the MCP gateway focused on authentication, logging, and approval orchestration, but let the downstream platform enforce the real permission decision. If the target system already has native IAM, use that policy source rather than duplicating it in the proxy.
• Eliminate shared agent credentials Replace one static service account or borrowed human login with a federated session identity that is unique to the request. Scope the credential to the approved task and expire it as soon as the session ends.
• Prefer just-in-time grants over standing privilege Issue short-lived access only after intent is approved, then revoke it on idle or completion so the agent cannot reuse the grant. This is especially important for tools that wrap AWS CLI, SQL, or SaaS query languages.
• Audit for fan-out hidden inside single tool calls Review MCP servers that batch commands or hide multiple downstream operations behind one call, because a single envelope may mask many effective actions. Map those fan-out paths to the controls that actually see the resulting API calls.

Key takeaways

• MCP gateways can broker access requests, but they cannot replace the resource owner’s own authorization logic.
• Tool-level filtering and argument parsing are fragile controls when one call can hide many real operations.
• Federated, short-lived identities are the practical way to keep AI agent access within a task-scoped boundary.

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 Identity: Session identity is a short-lived identity created for one specific execution context rather than reused across all agent activity. For AI agents and other NHIs, it is the practical alternative to shared service accounts because it can be scoped, audited, and revoked with the task itself.
• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.

What's in the full article

P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:

• How specific MCP server designs expose broad command surfaces through one tool call, including AWS CLI, SOQL, SQL, and GitHub-style fine-grained operations.
• The argument parsing pitfalls that make gateway-side authorization brittle when free-text command grammars include quoting, escaping, batching, and nested JSON.
• Why native IAM, branch protection, and resource-level policy evaluation are the real control points for downstream enforcement.
• How intent-based, just-in-time access is assembled with federated identity and short-lived credentials for agent sessions.

👉 The full P0 Security post covers the AWS, Salesforce, SQL, and GitHub examples in operational detail.

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.