Topic starter
24/06/2026 11:30 pm
TL;DR: P0 Security argues that agentic applications connected through MCP need two separate control layers, one for tool exposure and one for underlying data authorization, because the LLM chooses tools and inputs at runtime. That makes runtime policy evaluation and just-in-time approval routing the real IAM gap.
Editorial analysis by NHI Mgmt Group, based on content published by P0 Security: “Technical Deep Dive: AuthZ Control Plane for Agents”.
Key questions
Q: What breaks when an agent only has tool-level access control but no data-layer policy?
A: Tool-level control can still leave the backend database overexposed if the MCP server’s service identity has broad permissions.
Q: Why do agentic systems need just-in-time access instead of standing role grants?
A: Agentic systems often need occasional elevated access for a specific prompt, but that access should not persist beyond the session or task.
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
- Define separate control planes for tools and data Do not let MCP tool exposure stand in for data authorisation.
- Make approval states requestable and time-bound Design just-in-time access so the agent can request elevated scope in-session, but only after explicit approval and only for the smallest usable scope.
- Evaluate agent-generated queries before execution Place a policy decision point in front of the database call and compare the requested table, column, and row operations with the user’s entitlement before any SQL runs.
Bottom line: Agentic authorisation fails when teams treat MCP visibility as equivalent to data permission, because the model still decides which actions to assemble at runtime.
What's in the full article
P0 Security's full analysis covers the implementation detail this post intentionally leaves at the architecture level:
- How the MCP server calls the access decision API during tool listing and query evaluation
- Policy Studio mappings for roles, tools, and requestable approval states
- Examples of table, column, and row-level constraints for Postgres-backed agent workflows
- The JIT request flow for human approval when an agent needs temporary elevated access
👉 Read P0 Security's analysis of agentic authz control planes for MCP-connected apps →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 8:25 am
Agentic authorisation is now a two-plane problem: tool discovery and data decisioning are no longer the same control. The runtime model can see, select, and request actions dynamically, so a static role-to-endpoint map leaves a gap between what the agent can name and what it should execute. Practitioners need to treat the tool catalog and the data policy engine as distinct governance surfaces.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between tool gating and data-layer authorisation in agentic apps?
A: Tool gating decides which MCP actions the agent can see and request, while data-layer authorisation decides whether the specific underlying data operation is allowed. The first shapes the agent’s menu of options. The second constrains the actual database impact of the chosen action. Both are needed because language-based tool descriptions alone cannot safely carry the full security decision.
👉 Read our full editorial: Authz control planes for agents expose the real IAM gap