TL;DR: 89% of enterprises are deploying AI agents while only 10% say governance is adequate, according to EnforceAuth research, underscoring a gap between authenticating an agent at session start and authorizing every action it takes. The core failure is assuming token issuance can substitute for continuous runtime enforcement across changing data, tools, and context.
At a glance
What this is: This analysis argues that AI agent governance breaks when organisations treat authentication as sufficient and ignore continuous authorization over each action.
Why it matters: IAM and security teams need to separate identity proof at session start from runtime decision control, because agentic behaviour can move faster than human-centric access models.
Context
AI agent authorization is the control problem that begins after authentication succeeds. The article argues that verifying an agent at login or session start does not answer the harder question of what that agent may do next, especially when context, data sensitivity, and tool use change during execution.
For identity governance, the issue sits squarely in the gap between credential issuance and action-level enforcement. That makes it relevant to NHI, because agents authenticate like non-human identities, but the article’s core claim is that agent runtime behaviour now outgrows login-centric IAM assumptions.
The article positions this as a governance gap, not a product feature gap. Its central warning is that enterprises can have valid scoped tokens and still lack meaningful control over what an AI agent is authorised to do once it starts operating.
Key questions
Q: What breaks when an AI agent can act on inherited credentials without a fresh authorisation check?
A: The main failure is that the platform treats the worker’s pre-existing access as if it were still valid for every downstream action. Once a compromised runtime can reuse inherited credentials, identity governance loses the ability to distinguish the original task from attacker activity. That turns one execution foothold into a broad access problem.
Q: Why do elevated AI agent permissions create more risk than standard user access?
A: Elevated permissions matter because agents can use them at machine speed across multiple systems without the pauses that human workflows create. That raises the chance of data exposure, tool misuse, and unintended cross-system actions. The risk is not just scope, but the speed and autonomy of the workflow.
Q: How do security teams know if agent governance is actually working?
A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.
Q: Should organisations use the same access model for humans and AI agents?
A: No. Human access models are built around stable roles and review cycles, while AI agents often need contextual, task-specific permissions that change quickly. Treating them the same usually leads to over-permissioning or constant exceptions. Organisations should separate identity proof from authorization design and apply resource-level controls for agents.
Technical breakdown
Why session authentication is not runtime authorization
Session authentication establishes that an identity is real and was allowed to begin a session. Runtime authorization decides whether each individual action remains permitted as context changes. For AI agents, that distinction matters because the agent can make API calls, chain tool invocations, and access data long after the original decision was made. A token proves the session started correctly. It does not prove that every later request still fits policy. This is why identity controls designed around login events fail when decision-making happens continuously inside the session.
Practical implication: separate session establishment from per-action enforcement and treat them as different control layers.
Action-level authorization across applications, infrastructure, data, and AI workloads
The article breaks the runtime problem into four enforcement surfaces. Applications need fine-grained request-time decisions, infrastructure needs policy around resource creation and configuration changes, data needs row- and attribute-level access control, and AI workloads need governance over tool calls and chained actions. These are not interchangeable controls. A valid identity token can open the door in one layer while leaving the others effectively ungoverned. That is why agent governance cannot be solved by one identity event or one policy plane alone.
Practical implication: map each agent use case to the enforcement layer it actually touches, then check for coverage at that layer.
How agent speed breaks human IAM assumptions
Human IAM assumes people act slowly, one step at a time, and within a reviewable window. AI agents do not. They can execute thousands of autonomous actions in a single session, cross system boundaries, and change behaviour mid-session without a human checkpoint. That collapses assumptions behind role-centric access models, because the privilege decision is made once while the action stream keeps moving. The security problem is not only over-privilege, but also stale privilege assumptions that were written for human tempo.
Practical implication: re-test access models against agent-speed execution rather than human workflow expectations.
NHI Mgmt Group analysis
Authentication-first IAM is now an incomplete control model for AI agents. The article’s central point is that proving who or what started a session does not govern the actions that follow. Continuous authorisation, not login assurance, is the control boundary that now matters for agent behaviour. Practitioners should treat session start as the beginning of enforcement, not the end of the security decision.
Authorization must move from token scope to live decisioning. Scoped credentials are useful, but only as an initial constraint. Once an AI agent can make decisions, call tools, and chain actions independently, the risk is no longer whether the token was valid but whether each action is still permitted in the current context. That shifts governance from identity proofing to policy evaluation at runtime.
Runtime enforcement is the named concept this category now needs. The article exposes an authorization gap between authenticated identity and governed behaviour. That gap is not solved by stronger MFA, better login flows, or wider token scopes, because the broken premise is that one authentication event can safely cover a long stream of agent actions. The implication is that identity programmes must distinguish session trust from action trust.
Human-paced access review assumptions do not survive agentic execution. Review cycles assume privilege persists long enough to be inspected, challenged, and certified. Agents can consume and move through privileges faster than review processes can observe them, which means governance tied to periodic certification misses the real risk window. The practical conclusion is that identity governance must account for action velocity, not just entitlement ownership.
Cross-domain authorization is becoming the dividing line between governance and theatre. The article shows that agentic access spans applications, infrastructure, data, and AI workloads, so any programme that governs only one layer leaves material blind spots. The field now has to stop treating agent identity as a single control point and start treating it as a continuous policy problem across multiple enforcement domains. Practitioners should expect architectural separation to matter more than brand claims.
What this signals
Runtime authorization is becoming the control boundary that matters most for agents. Organisations that stop at session authentication will keep confusing identity proof with permission control. The programme shift is from proving who the actor is to proving what each action is allowed to do.
Agentic access exposes a governance split between issuance time and decision time. Traditional IAM models assume the meaningful security decision happens when credentials are issued. AI agents force that decision to be repeated at runtime, because the action set, context, and data sensitivity can change before the session ends.
For practitioners
- Define runtime authorization as a separate control plane Map session authentication, token issuance, and per-action authorization to different owners and policy decisions. If these are still treated as one identity control, AI agent behaviour will outpace the governance model.
- Inventory the actions each agent can take after login List the APIs, tools, datasets, infrastructure operations, and chained actions each production agent can reach once authenticated. Use that inventory to identify where token scope ends and live authorization must begin.
- Apply context-aware policy to every agent action Evaluate data sensitivity, current task state, delegation chain, and risk signals at request time instead of relying on the original session decision. Reassess permissions when behaviour or context changes mid-session.
- Separate human workflow controls from agent workflow controls Do not assume role-based access patterns that work for people will bound autonomous or semi-autonomous agent behaviour. Rebuild approvals, constraints, and audit points around machine-speed execution.
- Set explicit enforcement ownership across domains Assign clear owners for application, infrastructure, data, and AI workload authorization so gaps do not hide between teams. The control model fails fastest where responsibility is split but enforcement is not.
Key takeaways
- Authentication still matters, but it is no longer the control that contains AI agent behaviour on its own.
- The real governance gap is between a valid session and the next allowed action, which is where runtime policy has to operate.
- Identity teams should rework controls around action-level enforcement, because agent speed and chaining defeat login-centric assumptions.
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 centres on agent identity that is authenticated but not continuously constrained. |
| Recommendation — Apply ASI03-style controls to enforce action-level limits after agent authentication. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The piece argues authentication is necessary but insufficient for agent governance. |
| NHI-05 — Overprivileged NHI | The article warns that broad token scope can outlive the context that justified it. | |
| Recommendation — Use NHI-04 to harden agent authentication, then pair it with runtime authorization controls. Map agent entitlements to NHI-05 and reduce every permission to the smallest actionable scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The primary governance issue is whether authorised actions remain appropriate at the point of use. |
| Recommendation — Apply PR.AA-05 to evaluate permissions continuously instead of trusting session-start approval alone. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Agentic execution magnifies the impact of any privilege broader than the current task requires. |
| Recommendation — Enforce AC-6 so agent permissions stay task-scoped and do not persist beyond current need. | ||
Key terms
- Authorization Gap: The distance between what an authenticated identity can do and what it is actually permitted and proven to do in real time. For AI agents, the gap widens when decisions are made per action, at machine speed, and through workflows that expand faster than human review cycles.
- 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.
- Continuous identity validation: A governance model that checks identity trust throughout execution rather than only at login or periodic review. For AI and machine identities, this means verifying access, scope, and behaviour in real time so actions can be constrained while they are happening.
- Tool-Level Enforcement: Tool-level enforcement controls what an AI agent may do through each individual action endpoint, rather than relying on a broad domain label. It is the operational layer where allow, block, and approval states are actually applied, making it the real boundary for safe delegation.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org