Authz control planes for agents expose the real IAM gap

At a glance

What this is: This is a technical deep dive on agentic authorization control planes and the key finding is that agent-facing tool access and underlying data access must both be gated at runtime.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern MCP tool exposure, scoped approvals, and database entitlements as one access path rather than separate control problems.

👉 Read P0 Security's technical deep dive on authz control planes for agents

Context

Agentic applications break the old assumption that the client can safely pre-select valid actions before execution. In an MCP-driven system, the model chooses which tools to call and which inputs to pass, so authorization has to move closer to runtime decision-making and not rely on UI logic alone.

That creates a direct identity governance problem for NHI, agentic AI, and data access programmes. Teams must treat tool visibility, database privileges, and approval workflows as linked controls, because a broad service identity or over-exposed tool can turn a chat interface into a path to unauthorized writes or data disclosure.

Key questions

Q: How should security teams govern MCP tool access for agentic applications?

A: Security teams should gate MCP tools by user role before the model can see them, then enforce a separate authorization decision at the data source. That prevents the agent from discovering or using capabilities it should never have had. The control goal is not just least privilege for the user, but least exposure for the model and the underlying service identity.

Q: Why do agentic apps need both tool controls and data controls?

A: Because tool controls only limit what the agent can attempt, while data controls determine what the agent can actually read or change. If the database or service account remains broad, a restricted tool can still become a route to unauthorized access. The two layers need to agree, or the weaker one defines the real privilege boundary.

Q: What breaks when an LLM can choose tools freely?

A: What breaks is the assumption that valid actions can be precomputed in the client. When the model chooses tools and parameters at runtime, forbidden calls become harder to prevent and easier to infer from error feedback. Teams need role filtering, narrow tool descriptions, and backend enforcement to keep the model from turning free text into excess privilege.

Q: Who should approve just-in-time access requests for agents?

A: Approval should go to the human or role that owns the underlying resource, not to the agent itself. If the request is for a tool, route it to the tool owner or delegated approver. If the request is for data, route it to the data steward or equivalent authority so the approval matches the actual privilege being granted.

Technical breakdown

Why MCP tool gating is different from classic API authorization

In a conventional web app, the frontend and backend jointly constrain which endpoints can be called, and the backend often enforces a narrowed version of a broad database permission set. With MCP, the LLM becomes the decision point for tool choice and parameter selection, so tool descriptions effectively become part of the authorization surface. If the model can see a tool, it may attempt to use it, even when the action would have been impossible in a deterministic UI flow. That is why role-aware tool filtering matters: it reduces the chance that forbidden capabilities are even presented to the agent.

Practical implication: expose only role-appropriate tools to the agent and do not rely on prompt instructions to suppress unauthorized tool use.

Why data-layer policy must sit beneath the agent interface

Tool filtering alone only controls the front door. Once an agent can generate SQL or other data operations, the underlying data source still needs its own policy boundary, ideally at table, column, or row level. P0’s model reflects a broader principle: the access decision and the data execution path should be separated so the authorization engine can say yes or no without proxying the data itself. That keeps the enforcement point close to the resource and prevents a permissive tool from becoming a universal data tunnel.

Practical implication: enforce database-level authorization independently of MCP tool choice so agent permissions cannot exceed the data policy.

How JIT and requestable access changes agentic governance

The introduction of a third state, requestable, is important because it reflects a middle ground between permanent access and outright denial. In this model, the LLM can identify that a tool or data scope is needed, request it on behalf of the user, and then wait for human approval before proceeding. That is a useful pattern for high-risk actions, but it also shows that approval workflows must now support machine-initiated requests with human review. The control plane becomes both a policy engine and a workflow router.

Practical implication: define which agent actions are requestable, who approves them, and how those approvals map back to the underlying tool or data entitlement.

NHI Mgmt Group analysis

Agentic authorization is collapsing the old assumption that action choice can be delegated without also delegating risk. The model is no longer just a presentation layer for deterministic workflows. When the LLM selects tools and inputs at runtime, access control must govern intent, visibility, and execution together. Practitioners should stop treating agent authz as a wrapper around existing IAM and start treating it as a separate control plane.

Tool visibility is now an authorization decision, not a convenience feature. If an agent can see every tool, the system has already expanded the operational blast radius before any query runs. Role-based tool filtering is therefore closer to privilege design than user experience. The implication is that identity teams need explicit governance for which capabilities are exposed to the model, not just which backend APIs exist.

Data access policy has to remain authoritative even when the agent is trusted to generate the query. A permissive MCP tool that can issue arbitrary SQL turns the database into the true enforcement boundary, which is where the real risk sits. This is a classic NHI control problem amplified by agentic decision-making, and it aligns cleanly with OWASP-NHI and zero trust principles. Practitioners should treat the data source as the final policy gate, not the MCP layer.

Requestable access is the most useful part of this design because it formalises temporary exception handling. But it also exposes the governance gap many programmes still carry: approvals are often designed for human-paced requests, not machine-triggered escalation paths. The field should expect more pressure to unify PAM, JIT, and agent workflow routing under one policy model.

Authz for agents is a lifecycle problem as much as a runtime problem. The right question is not only whether the agent can act, but when its access should appear, disappear, or be re-approved as the session changes. That makes entitlement lifecycle, approver assignment, and policy drift central to NHI governance. Practitioners should review agent access as continuously managed privilege, not static configuration.

From our research:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For adjacent guidance, Ultimate Guide to NHIs provides the broader control model for lifecycle, visibility, and access scope.

What this signals

Tool visibility will become a governance control point, not an implementation detail. As agentic applications spread, teams will need to decide which capabilities the model can even discover, especially where MCP reaches internal data sources. That shifts procurement, platform architecture, and IAM design toward explicit exposure management rather than implicit trust in the chat layer.

With only 44% of developers following security best practices for secrets management, per The State of Secrets in AppSec, the same execution gap will show up in agentic systems unless policy and entitlement boundaries are made machine-enforceable.

Requestable access will need PAM-style governance for non-human workflows. The practical issue is not whether an agent can ask for more access, but whether approvers, scope, and expiry are built for machine-initiated demand. Teams that already manage privileged access will be better positioned to extend those controls to agent sessions and MCP-requestable resources.

For practitioners

• Restrict tool exposure by role Return only the MCP tools that match the authenticated user’s role, and keep disallowed tool variants out of the list_tools response entirely so the model never sees them.
• Separate tool policy from data policy Enforce a second authorization decision at the database layer for table, column, and row access, even when the agent has already passed tool-level checks.
• Treat requestable access as a governed workflow Define which tools and datasets can be requested, route approvals to the correct human approver, and make the approved scope explicit for the current session only.
• Review service identity permissions behind the agent Audit the database or API service account used by the MCP server so it cannot exceed the least-privilege boundary required for the agent’s approved actions.

Key takeaways

• Agentic authorization cannot rely on the same assumptions as conventional web authorization because the model, not the frontend, selects actions at runtime.
• The control problem is two-layered: MCP tool exposure shapes what the agent can attempt, and data-layer policy determines what it can actually do.
• Teams should treat requestable access, role filtering, and service-account scope as one governed path if they want agentic systems to stay within intended privilege boundaries.

Key terms

• MCP Tool Gating: MCP tool gating is the practice of limiting which tools an AI agent can see or invoke based on identity, role, or policy. It reduces the chance that the model can discover or attempt unauthorized actions, and it is most effective when enforced before tool enumeration reaches the agent.
• 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.
• Data-Layer Authorization: Data-layer authorization is the enforcement of access rules at the resource itself, such as a table, column, row, or database action. It matters because tool-level controls can be bypassed conceptually if the underlying service identity still has broader rights than the agent should inherit.
• Agentic Authorization: Agentic authorization is the policy and control model for software that chooses actions at runtime using an LLM or similar decision engine. Unlike static automation, it must govern tool discovery, execution timing, and approval paths together because the actor can vary its behavior within a single session.

What's in the full article

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

• Concrete MCP tool naming patterns for separate customer and admin roles
• Example policy studio mappings for tool-level and data-level filters
• Detailed requestable access flow for approvals and session-scoped grants
• SQL evaluation examples showing how agent-generated queries are checked

👉 The full P0 Security post covers MCP tool filtering, data-layer evaluation, and JIT approval routing in implementation detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.