Periodic access review breaks down because the agent can request, use, and release access inside a single execution cycle. That leaves little or no stable entitlement state for recertification to inspect, so governance has to move closer to issuance and runtime control rather than relying on after-the-fact review.
Why Recertification Stops Working Once the Agent Acts at Runtime
Traditional identity governance assumes access is visible long enough to be reviewed, certified, and then approved or revoked. Agentic workflows undermine that assumption because the agent can obtain access, use it, and release it inside the same business process. Governance shifts from “who has standing access?” to “who was issued authority, under what policy, and for how long?”
That is why IAM and IGA Basics matters here, the control problem is no longer only entitlement inventory, but whether the issuance model still produces something humans can actually certify.
What Changes in the Access Model for Agentic Workflows
In a human-centric model, access review can inspect roles, groups, app assignments, and lingering entitlements. In an agentic model, the meaningful access event may be a short-lived token, delegated scope, or task-scoped permission that exists only while a workflow is executing. That means the governance record has to capture issuance context, intent, and expiry, not just final state.
When the workflow itself is the access container, entitlement review alone misses the real decision points. The control conversation moves closer to just-in-time issuance, delegation boundaries, and runtime authorization, because those are the places where excess privilege or misuse is introduced.
That is also why the Agentic AI Identity Guide is the more relevant lens than a static account model, since the identity must be managed across registration, delegation, use, and retirement rather than only at periodic review time.
Why Governance Has to Move Closer to Issuance and Runtime
Once an agent can chain multiple actions in one execution cycle, the old control question, “does this identity still need access?” becomes too late. The more useful questions are whether the request was policy-bound, whether the access was narrow enough for the task, and whether the platform can observe or stop the action before it completes. That is a different governance posture from batch recertification.
Organizations also need to treat revocation and expiry as first-class design requirements. If access cannot be cleanly bounded to a task, the governance model will accumulate invisible authority that no reviewer can meaningfully attest to after the fact. The practical alternative is to make issuance auditable and to make runtime checks enforceable.
For that reason, AI Agent Authorisation Guide is directly relevant, because it shifts the emphasis toward task-scoped access, per-action decisions, and human approval where the risk warrants it.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic workflows change how authority is granted and consumed at runtime. |
| Recommendation — Enforce least-privilege, task-scoped authorization for agent actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Short-lived agent access still needs retirement and revocation discipline. |
| NHI-05 — Overprivileged NHI | Workflow agents can accumulate excess authority beyond a single task. | |
| Recommendation — Automate expiry and retirement so agent authority does not linger. Constrain agent permissions to the minimum access each workflow requires. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime agent access depends on managing credentials, tokens, and their lifecycle. |
| AC-6 — Least Privilege | Agentic execution should receive only task-bounded privileges. | |
| Recommendation — Control issuance, rotation, and revocation for workflow credentials. Limit each agent to the smallest set of permissions needed for the task. | ||
Practitioner Guidance
What to prioritise: Treat any workflow that can request and consume access within one run as a governance design problem, not a recertification problem. If the entitlement vanishes before the next review window, the review process is measuring the wrong object.
What to verify: Check whether the platform can prove who issued the access, what task it was bound to, when it expires, and whether the agent reused that authority elsewhere. If you cannot reconstruct those facts, periodic access review is not giving you meaningful assurance.
Decision rule: If the access is temporary, task-bound, and automatically constrained, focus on issuance policy and runtime enforcement; if it is long-lived or reusable, treat it as standing privilege and govern it accordingly.
Common mistake: Teams often keep their existing review cadence and add an “agent” category on top. That usually fails because the control is still looking backward at stable entitlements while the real risk is happening during execution.
Practitioner takeaway: The governance unit changes from the account to the action, so the control objective becomes bounded, observable, and revocable authority rather than retrospective certification of a state that no longer exists.