Notifications
Clear all
Topic starter
24/06/2026 11:30 pm
TL;DR: Agentic applications that connect via MCP need two separate control layers, tool visibility and data-layer authorization, because the LLM decides which tools to call and what inputs to use, according to P0 Security. That shifts the governance problem from static endpoint design to runtime access control, JIT approval routing, and policy evaluation for agent-driven actions.
NHIMG editorial — based on content published by P0 Security: Technical Deep Dive: AuthZ Control Plane for Agents
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read P0 Security's technical deep dive on authz control planes for agents →
Agentic authz control planes: what IAM teams need to know?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 8:25 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authz control planes for agents expose the real IAM gap
