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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on P0 Security's blog post: Agentic authorization control planes must separate MCP tool visibility from underlying data-layer policy enforcement.
Why it matters: It matters because IAM teams now have to govern both what an agent can see and what it can execute, rather than treating the chat layer as a simple front end.
👉 Read P0 Security's analysis of agentic authz control planes for MCP-connected apps
Context
Agentic applications change the authorisation boundary because the model chooses tools and inputs during the session, rather than following a fixed endpoint map. In that setting, the old assumption that access can be encoded once at the application edge stops holding for MCP-connected workflows.
This article is about agentic AI identity governance, not just application security. The problem is whether the control plane can constrain tool exposure, query scope, and approval routing strongly enough to keep runtime decisions inside policy.
The P0 Security analysis uses a simple but important pattern: one control layer filters which MCP tools are visible, while a second layer evaluates the data request itself. That separation is the core governance question for teams building agentic systems.
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. The model may only see approved tools, but the query it generates can still reach rows, columns, or actions that exceed the user’s entitlement. Real governance requires authorisation at both the tool surface and the data layer.
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. Just-in-time access preserves workflow flexibility while keeping the elevated privilege short-lived, requestable, and approval-bound. That reduces the chance that an agent can reuse broad permissions after the immediate need has passed.
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. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.
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.
Technical breakdown
Why MCP tool visibility is not enough
MCP tools describe actions in natural language, which means the agent can select from a wider runtime surface than a traditional API client. Tool visibility limits what the model can call, but it does not by itself constrain the underlying database action if the tool implementation still reaches broad backend permissions. In practice, the authorisation decision has to happen at two levels: first, whether the tool should be exposed at all, and second, whether the specific data request inside the tool call is allowed. That is why tool catalog control and data policy evaluation are complementary, not interchangeable.
Practical implication: treat MCP tool exposure and data authorization as separate controls, not as a single gate.
How data-layer policy evaluation works for agentic queries
A data-layer control plane evaluates the agent-generated request against table, column, or row scope before the query executes. That is different from simply wrapping an existing endpoint, because the policy has to understand the operations inside a free-form query and compare them with the end user’s entitlement. The article describes a model where the control plane allows or denies access but does not proxy the database communication itself. This makes the database remain the source of enforcement, while the control plane acts as the authorisation decision point for the agent’s query.
Practical implication: enforce authorisation at query scope, not only at tool selection time.
Just-in-time access changes the approval boundary
Just-in-time access adds a requestable state between denial and approval. In the article’s model, an LLM can identify that a tool or resource would help answer the prompt, then prompt the user to start an approval flow for short-lived access. That is useful for agentic systems because some access decisions cannot be pre-baked into static role mappings without either overexposing data or breaking legitimate workflows. The architectural point is that access requests become part of the agent session, but still require explicit human approval before the elevated scope is usable.
Practical implication: route elevated agent access through requestable, short-lived approval flows rather than persistent standing grants.
Threat narrative
Attacker objective: The objective is to get the agent to perform or disclose data actions beyond the end user’s authorised scope.
- Entry occurs when an agentic application is connected to internal data sources through MCP tools that expose action and input choices to the LLM at runtime.
- Escalation occurs if the tool layer allows the model to surface broader actions than the end user should reach, or if a backend service identity still carries permissions wider than the request needs.
- Impact occurs when the agent issues a query or write action that reaches data outside the user’s entitlement, turning a chat interaction into overbroad database access.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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
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.
Free-text tool descriptions create policy ambiguity: MCP collapses an API contract into language that the model interprets during the session. That means the authorisation model depends on how faithfully role constraints are reflected in tool naming, descriptions, and fallback enforcement. The practical lesson is that language becomes part of the control plane, not just documentation.
Just-in-time approval becomes the native escalation path for agents: if the agent can ask for access on behalf of the user, then approval routing is part of the identity flow, not an exception process. That aligns with NIST CSF PR.AA-05 and OWASP-NHI NHI-05, because standing access is exactly what these workflows are trying to avoid in favour of task-scoped privilege.
Runtime policy evaluation is the real boundary for agentic IAM: the more the agent can choose actions, the less useful predeclared entitlement alone becomes. The governance problem is no longer whether the user has a role, but whether the session can safely narrow that role to the exact query, table, or tool at the point of use. That makes policy evaluation the decisive control for agentic access.
From our research library:
- 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.
- Read next: AI Agent Authorisation Guide
What this signals
Agentic authz control plane: the emerging pattern is to split tool exposure from data decisioning, because free-text tool descriptions cannot safely carry the whole authorisation model. Programmes that keep relying on endpoint-centric permissions will find that the LLM can still assemble risky actions from apparently legitimate parts. The control point has moved to runtime policy evaluation, not the chat UI.
Access review cadences also change shape in agentic environments. A requestable privilege that is approved for one prompt may never be suitable as a standing entitlement, so governance teams should measure how often the same access path becomes re-requested and whether approvals are being reused as a shortcut.
For practitioners
- Define separate control planes for tools and data Do not let MCP tool exposure stand in for data authorisation. Map tool visibility, query scope, and write permissions as separate enforcement steps so the agent cannot infer wider access from a visible tool.
- 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.
- Limit service identities behind MCP servers Review the backend service account that connects the MCP server to the database and remove broad permissions that would let a single tool call exceed the user’s role.
- Separate tool approvers from data approvers If your workflow uses human-in-the-loop escalation, assign distinct approvers for tool access and underlying data access so a single approval path does not grant both by default.
Key takeaways
- Agentic authorisation fails when teams treat MCP visibility as equivalent to data permission, because the model still decides which actions to assemble at runtime.
- The architectural split that matters is tool exposure versus query authorisation, with a separate decision point needed before the database executes anything.
- Just-in-time approval is the right pattern for temporary elevation in agentic workflows, but only when the approval path is scoped, short-lived, and separate from backend service access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent runtime privilege decisions and scope enforcement. |
| ASI02 — Tool Misuse | MCP tool selection and input shaping are the core control problem in this article. | |
| Recommendation — Constrain agent privilege changes at runtime and block scope expansion that exceeds the user’s entitlement. Restrict tool exposure so the agent cannot invoke actions outside the approved tool set. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flow depends on authenticated sessions and requestable access around machine-mediated identity paths. |
| NHI-05 — Overprivileged NHI | The backend service identity can still overreach even when the agent UI looks constrained. | |
| NHI-10 — Human Use of NHI | Human approvers and human users both participate in the access-request workflow described here. | |
| Recommendation — Validate the session and identity path before granting requestable tool or data access. Reduce backend service permissions so the MCP server cannot exceed user-scoped access. Separate human approval decisions from machine execution paths and log both distinctly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about runtime authorisation decisions for tools and data access. |
| Recommendation — Apply entitlement controls at the point of use, not only at provisioning time. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived access and requestable approval depend on managed credentials and session controls. |
| Recommendation — Use authenticator management to keep elevated access short-lived and revocable. | ||
Key terms
- MCP Tool Gating: MCP tool gating is the control point that decides whether an AI agent can call a specific tool, and under what conditions. In Model Context Protocol environments, it enforces policy on tool access, input scope, user consent, identity, and risk signals so agent actions remain bounded, auditable, and least privilege.
- Data-Layer Authorization: Data-layer authorization is access control enforced where data is queried or served, not only where a request first enters the application. It is a stronger control point because it can limit overexposure even when upstream applications, APIs, or services are imperfect.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Requestable Access: Requestable access is a privilege state where a user or agent can ask for a tool or resource on demand instead of holding it permanently. The access remains inactive until approved, which makes it useful for just-in-time workflows, but it still needs clear approver ownership and session scope.
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
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org