Topic starter
30/09/2026 7:10 pm
TL;DR: As organisations move AI agents into production, P0 Security argues that network, MCP, data and identity controls each govern a different part of the agent action chain, and none alone covers session identity, runtime policy and task-specific authorization end to end. The core problem is that control placement determines what the system can see, prove and restrict at runtime.
NHIMG editorial: based on content published by P0 Security: AI agents | Four approaches evaluating agentic access control approaches
Questions worth separating out
Q: Where does agentic runtime access control usually fail first?
A: It usually fails at the layer that cannot see the whole action chain.
Q: Why do AI agents need action-level authorisation instead of resource-level access?
A: Resource-level access tells you what an agent can reach, but not whether its runtime actions match its authorised purpose.
Q: What breaks when provenance is lost between the user, agent and tool?
A: Policy loses the ability to tie a request to the actor that initiated it and the credentials that executed it.
Practitioner guidance
- Map the agent action chain Document where each control layer acts across originator, agent, sub-agent, tool, MCP and target system so you can see where enforcement stops.
- Separate tool gating from target-system authorisation Treat MCP and gateway controls as invocation checkpoints, then confirm that the target system still evaluates the specific permission the task needs.
- Preserve session provenance across delegation Keep the originator, acting agent and downstream agent lineage visible through the session so policy decisions can follow the task end to end.
What's in the full article
P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:
- A deeper walk-through of how each control layer enforces policy at a different point in the agent action chain
- The native target-system permission example showing how blended identity can be translated into a specific runtime grant
- A more detailed comparison of when provenance, policy enforcement and short-lived access are preserved or lost
- The webinar context and source material behind the approach-by-approach evaluation
👉 Read P0 Security's analysis of agentic runtime access control approaches →
Agentic runtime access control: where do controls stop working?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/09/2026 7:11 pm
Control placement is now the primary design variable in agent governance. The article shows that the same agent action chain can be governed at transport, tool, data or identity layers, but each layer answers a different question. That means programme maturity is no longer about adding more controls, it is about knowing which decision each control is actually making. Practitioners should map controls to the exact point in the chain where they enforce, because coverage claims without placement clarity create false confidence.
A few things that frame the scale:
- The agentic AI market is already worth $5 billion and is projected to reach $50 billion by 2030.
A question worth separating out:
Q: How should security teams decide between network, MCP, data and identity controls for agents?
A: Use the control layer that matches the decision you need to make. Network controls govern connectivity, MCP controls govern tool invocation, data controls govern exposure, and identity controls govern who may do what inside the target system.
👉 Read our full editorial: Agentic runtime access control depends on where enforcement sits
