TL;DR: P0 Security argues that authentication, agent inventory and logging do not decide whether a requester, agent, tool and resource should be allowed to act together at runtime, so access decisions must evaluate the full chain of authority and revoke access when the task ends. In agentic systems, control shifts from who signed in to whether the assembled action was authorised at that moment.
At a glance
What this is: This article argues that agentic access control cannot stop at authentication because the real decision is whether the requester, agent, tool and resource combination is authorised at runtime.
Why it matters: It matters because IAM teams now have to govern delegated, multi-step action chains, not just sessions, permissions and logs for a single identity.
👉 Read P0 Security's analysis of runtime authorisation for agentic access control
Context
Agentic runtime authorisation is the control problem that appears when a human, service account, workload or another agent causes an agent to act through tools against a target resource. The core issue is no longer whether a session is valid, but whether the assembled chain of authority should be allowed to execute a specific action at that moment.
Traditional IAM checks were built for direct actor-to-resource decisions. Agentic systems break that assumption by inserting tools, downstream workflows and sometimes sub-agents between the initiator and the final action, which makes the effective authority larger than any single identity record suggests.
Key questions
Q: What breaks when agent security only happens after execution?
A: When security only happens after execution, unsafe prompts can shape context, risky tool calls can complete, and sensitive output can already be exposed. At that point, the control is investigative, not preventive. The main failure is losing the chance to intervene while the agent is still deciding.
Q: Why do agentic systems need runtime authorisation instead of static permissions?
A: Static permissions describe what an agent can generally reach, but runtime authorisation decides whether that specific action, at that specific moment, is acceptable. That matters because the requester, tool and target can change the effective authority of the action. Without runtime evaluation, organisations approve capabilities without governing how they are actually combined.
Q: How do security teams stop an agent from using authority it should not have?
A: Teams need to constrain the full chain of authority, not just the agent object. That means binding actions to the initiating requester, limiting tool reach, and revoking access when the task ends. The practical test is whether the agent can still complete the same action after the original purpose has expired. If yes, the control boundary is too loose.
Q: Should organisations treat agent access reviews the same as human access reviews?
A: No. Human reviews focus on role, business need, and employment status, while agent reviews must also cover tool scope, credential inheritance, and downstream action paths. The review object is not just the agent itself but the full execution chain it can initiate. That distinction matters because agent behaviour can change faster than a standard recertification cadence can capture.
Technical breakdown
Why authentication stops at the wrong boundary
Authentication answers who started a session or supplied the initial trust signal. In agentic systems, that is only the first input to the decision, because the actor that initiates work may not be the same entity that executes it. A requester can be a human, workload, service account or another agent, and the agent may then call tools with broader reach than the requester had directly. That means the security question is not identity alone, but whether the request context, execution path and resulting authority are jointly acceptable. Traditional sign-in controls do not evaluate that composition, so they can validate a request while missing the actual risk created by the action chain.
Practical implication: move the control point from sign-in to runtime authorisation across the full requester-to-tool-to-resource path.
Why the full chain of authority matters
The article’s central insight is that authority is assembled at runtime. An agent can inherit intent from a requester, gain reach through a connected tool and touch systems the original initiator could not access directly, such as a database, cloud console or production environment. That composition can create an authority the organisation never intended, even when each component looks acceptable in isolation. This is the blended identity problem for agentic systems: the effective actor is not a single principal but a temporary chain of principals, tools and scoped capabilities. Governance fails when teams treat agent approval as inventory management instead of action approval.
Practical implication: evaluate each agent action against the complete chain of authority, not against the agent’s standing permissions alone.
Why just-in-time access becomes mandatory for agentic tasks
Just-in-time access is still useful in agentic environments, but the article reframes it as a runtime control rather than a provisioning convenience. Access should exist for a specific purpose, within the correct scope, and then disappear when the task, workflow, session or project ends. Without that discipline, a completed agent task can leave behind reusable authority that no longer matches the original need. The same principle that reduces human privilege persistence now has to apply to agent-exercised access, because the risk is not only what the agent can do, but how long the assembled authority remains available after the work is finished.
Practical implication: time-box agent authority to the task and revoke it as soon as the workflow completes.
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.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
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
Runtime authorization is the real access control boundary for agentic systems: authentication, inventory and logging are all necessary, but none of them decides whether a specific action should be allowed once a requester, agent, tool and resource converge. The security model has shifted from identity verification to composition verification. IAM teams need to treat the runtime decision as the control event, because that is where excessive authority is actually exercised.
Blended identity is the right mental model for agentic access governance: the effective actor is not just the agent, and not just the requester, but the assembled chain of authority behind the action. That chain may include a human, workload or another agent, plus a tool that expands what can be touched. The implication is that approval, audit and constraint logic must bind to the action path, not to any single identity object.
Access review processes were designed for persistent entitlements, not ephemeral execution paths: they assume access can be observed over time, certified later and then recertified. That assumption fails when authority is assembled and consumed at runtime through an agentic workflow. The implication is not simply stronger review cadence, but a rethink of where governance begins, because the control window has moved to issuance and execution.
JIT for agentic access is a governance posture, not a feature request: the article makes clear that agent permissions should be specific to the task, constrained to the right scope and removed when the workflow ends. That aligns with Zero Standing Privilege thinking, but the key field-level change is operational. Teams have to govern the lifespan of agentic authority the same way they govern its scope.
Runtime context now decides whether an action is legitimate: a valid token, a known agent and a logged workflow are no longer sufficient evidence of authorised behaviour. The decisive question is whether the combined requester, tool and target were acceptable in that moment. Practitioners should treat runtime context as the policy object, not as an after-the-fact audit detail.
From our research library:
- 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
- Read next: AI Agent Authorisation Guide
What this signals
Runtime authorisation will become the decisive control plane for agentic access: programmes that keep focusing on discovery and authentication will miss the point where real risk is created. The control boundary moves to the moment an action is assembled from requester, agent, tool and resource, which means policy enforcement has to sit at execution time rather than after the fact.
Blended identity is the better governance frame for agentic environments: the practical unit of control is no longer the agent alone, but the delegated chain that causes the action. Teams should expect their current IAM and PAM models to require tighter integration with workflow governance, because authority is now contextual, temporary and compound.
For practitioners
- Define runtime authorisation policy for agentic actions Evaluate the requester, agent, tool and resource together before allowing any action. Make the policy decide whether the full chain of authority is acceptable at that moment, not just whether the agent is known or the token is valid.
- Bind agent actions back to the initiating requester Track which human, workload, service account or upstream agent caused each action so you can explain who assembled the authority behind the event and whether that delegation was intended.
- Scope agent permissions to the task and workflow Keep agent access purpose-specific, limit the reachable systems to what the task requires and revoke the authority when the session, workflow or project ends.
- Audit the full chain of authority before approval Check whether any downstream tool, sub-agent or connected workflow expands the action beyond what the requester could do directly, especially around production systems and sensitive data.
Key takeaways
- Agentic systems create an access-control problem that authentication cannot solve because the real decision is whether a composed action path is authorised at runtime.
- The effective authority in these systems comes from the requester, agent, tool and resource together, not from any single identity or token.
- Practitioners need runtime policy, task-scoped access and immediate revocation when the workflow ends, or agent authority will outlive its purpose.
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 addresses the attack and risk surface, while NIST AI RMF, NIST SP 800-53 Rev 5 and NIST CSF 2.0 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 centres on delegated agent authority and scope control at runtime. |
| ASI02 — Tool Misuse | The article focuses on how connected tools expand what an agent can do at runtime. | |
| Recommendation — Bind agent actions to least-privilege runtime scopes and block privilege expansion beyond the approved chain. Restrict tool invocation to policy-approved actions and verify each tool use against the initiating intent. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | Runtime authorisation for agentic access is a governance problem requiring clear accountability. |
| Recommendation — Define ownership for agent action approval, logging and revocation under an AI governance function. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article argues for scoping agent authority to the minimum needed for the task. |
| Recommendation — Apply least privilege to agent runtime actions and revoke permissions when the task completes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing authorisation decisions across identities and tools. |
| Recommendation — Use entitlement controls to evaluate whether composed agent actions are authorised before execution. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Chain of Authority: Chain of authority is the sequence of identities and approvals that explains how a task moved from request to action. In agentic environments, it is the evidence needed to prove who initiated work, which agent delegated it, which tool executed it, and whether the resulting access stayed within bounds.
- Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
- Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
What's in the full article
P0 Security's full article covers the operational detail this post intentionally leaves for the source:
- How to evaluate requester, agent, tool and resource together in a runtime policy
- Why a simple agent inventory cannot prove whether an action should have been allowed
- How to structure revocation when an agent task, workflow or project ends
- What leadership needs in an audit trail to reconstruct the full chain of authority
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 July 14, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org