Notifications
Clear all
Topic starter
12/07/2026 12:20 pm
TL;DR: Model Context Protocol gateways can authenticate agent calls and filter tools, but they cannot reliably authorize opaque command strings, nested query languages, or fan-out operations inside downstream systems, according to P0 Security. The real control point remains the resource owner’s native IAM, with just-in-time, session-scoped credentials preventing shadow authorization.
NHIMG editorial — based on content published by P0 Security: From MCP Tool Filtering to Runtime Access Control by Gergely Danyi
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Eliminate shared agent credentials Replace one static service account or borrowed human login with a federated session identity that is unique to the request.
- 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.
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.
👉 Read P0 Security's analysis of MCP tool filtering and runtime access control →
MCP gateways and runtime access control: where enforcement belongs?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
12/07/2026 12:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP tool filtering is not access control for AI agents
