No. User reviews assume the identity’s access is stable long enough to certify, but agents can acquire and spend access inside a single task. Governance has to move closer to issuance and runtime monitoring, or the review will always lag the behaviour.
Why normal access reviews miss AI agent behaviour
Normal user access reviews work when access is relatively stable and can be certified after the fact. AI agents are different: they may request, inherit, use, and discard privileges within one task, so a quarterly or monthly review can easily approve something that no longer reflects how the agent actually behaved.
That makes the real question not “who has the account?” but “what did the agent do with the authority it received, and when was that authority valid?” In practice, the review boundary has to move closer to issuance, delegation, and runtime use, especially where the agent can trigger downstream actions or spend delegated tokens.
For agent-specific access design, AI Agent Authorisation Guide and Agentic AI Identity Guide both reflect the same core point: the meaningful control is not a static certification of access, but a tighter model of delegated authority, task scope, and retirement.
What should be reviewed instead of static user entitlements
The unit of control should be the agent’s operational scope, not just the identity record. That includes what the agent is allowed to request, which tools or systems it can call, whether approvals are per action or per session, and whether the authority expires before the task ends. If those elements are not reviewed, the organisation is only validating paperwork, not behaviour.
Reviews also need to distinguish between standing access and task-bound access. An agent with “correct” entitlement on paper may still be unsafe if it can chain multiple calls, escalate through broad delegated scopes, or act on stale approval context. The useful certification question is whether the current grant still matches the smallest necessary action boundary.
Agentic AI Identity Maturity Model is a useful navigation point for teams deciding how far to move from human-style reviews toward runtime-aware governance, while AI Agent Observability, Audit and Incident Response Guide supports the evidence side of that shift by showing what must be logged and attributed.
How governance should change in practice
Governance should move upstream and downstream at the same time. Upstream, approval should happen at issuance, when the agent is granted a capability or a token with clear scope, expiry, and purpose. Downstream, runtime monitoring should validate whether the agent stayed inside that scope, because a later review cannot reconstruct every action sequence with enough fidelity to be preventive.
That means organisations should define approval logic around task scope, delegation chain, expiry, and revocation triggers. If the agent can materially change data, issue transactions, or invoke privileged tools, those actions need a live control path, not just a retroactive reviewer signature. Zero Trust for AI Agents and Agentic AI Security Guide both map naturally to this operating model because they treat continuous verification, policy per action, and blast-radius reduction as first-class controls.
Risk and Threat Considerations
Static reviews create a false sense of control when agent authority is short-lived, delegated, or composable. The main risk is not simply overpermissioned access, it is that an agent can use legitimate authority in a sequence that no periodic review will see in time, including token theft, destructive actions, or unauthorized tool use.
Failure mechanism: The approval happens after the agent has already used the access, or after the original task context has changed, so the certifier signs off on stale entitlement rather than live behaviour.
Impact: Excessive or mis-scoped agent actions can complete before detection, which increases blast radius, weakens accountability, and makes revocation too late to prevent harm.
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 SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent approvals hinge on runtime authority and privilege scope. |
| ASI02 — Tool Misuse | Agent reviews must account for tools the agent can invoke during a task. | |
| ASI10 — Rogue Agents | Unchecked agent autonomy can outgrow static review assumptions. | |
| Recommendation — Enforce per-action authorization and remove standing agent privilege. Restrict tool calls to approved actions and monitor for misuse. Continuously verify agent behavior and disable unsafe autonomy quickly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Agent approval depends on token and credential lifecycle, not just account review. |
| AC-6 — Least Privilege | Agent access should be scoped to the smallest task boundary. | |
| AU-2 — Event Logging | Runtime monitoring is required to see what the agent actually did. | |
| Recommendation — Rotate, expire, and revoke agent credentials on short operational lifecycles. Limit each agent to the minimum permissions needed for the task. Log agent actions at the point of use and retain them for review. | ||
| NIST Zero Trust (SP 800-207) | SP 800-207 — Zero Trust Architecture | The question is about moving from static certification to continuous verification. |
| Recommendation — Verify every agent request continuously instead of trusting prior approval. | ||
| OWASP ASVS | V8 — Authorization | Agent approvals are fundamentally an authorization problem at runtime. |
| Recommendation — Validate authorization decisions at the point each privileged action occurs. | ||
| CIS Controls v8 | CIS-5 — Account Management | Agent identities and credentials need lifecycle governance beyond user review cycles. |
| Recommendation — Inventory agent accounts and remove access that no longer matches current use. | ||
Practitioner Guidance
What to prioritise: Review the issuance and runtime controls first, not the access review calendar. If an agent can act within minutes or seconds, the review cadence must be replaced or supplemented by action-level policy enforcement, scoped tokens, and fast revocation.
What to verify: Confirm that each approved agent has a documented purpose, an expiry condition, an owner, and a visible audit trail for every privileged action. If you cannot attribute a material action to a task, treat the review model as incomplete.
Decision rule: If the agent can spend authority inside a single task, do not rely on periodic user access certification as the primary control. Use reviews only as a governance backstop for the agent’s standing design, not as proof of safe runtime behaviour.
Practitioner takeaway: Treat AI agent approvals as dynamic authorisation events, not as stable user entitlements, because the control failure is usually timing and scope, not the existence of an account.
Related resources from NHI Mgmt Group
- How do organisations prevent AI agent access from outliving the user session?
- Should organisations treat agent access reviews the same as human access reviews?
- Should organisations treat AI agent access to AWS differently from CI/CD access?
- Should organisations treat AI plugins like privileged access?