Static approval and recertification models no longer describe the full risk picture. If a workflow can select tools or data during execution, then entitlement state at provisioning time is only part of the story. Teams need governance that can see when access is granted, used, and released within the same operational session.
Where static identity governance stops being enough
Runtime access decisions change the meaning of governance because the control point moves from provisioning to execution. If a workflow can choose tools, query data, or invoke services while it is running, then an approval record alone no longer proves the actual access path. Governance has to account for the moment access is exercised, not just the moment it was granted.
This is why lifecycle models such as IAM and IGA Basics remain necessary but incomplete when runtime authority is in play. The core issue is not whether access was approved, it is whether the same session, process, or agent used that access in a bounded and observable way.
Practically, this shifts identity governance from a recordkeeping problem to an execution-governance problem. Teams need to know which identities can act, which tools they can reach, what data they can touch, and whether those permissions were actually exercised during the operational window.
What becomes invisible once execution is dynamic
Static certification is weakest where access is conditional, ephemeral, or delegated at runtime. A role may look acceptable on paper while the live workflow adds a tool call, a data pull, or a chained action that was never obvious in the original entitlement review. That gap matters because runtime context can increase blast radius without changing the provisioning record.
Governance also loses accuracy when access is composed across multiple steps. A workflow might begin with a low-risk entitlement and then expand through tool selection, API calls, or downstream delegation. The control question becomes whether the organization can trace who or what made each access decision and whether those decisions were constrained by policy at the time.
For identity-heavy environments, Access Reviews and Certification Guide is most useful when reviews are redesigned to reflect actual use, not only assigned entitlement. That means reviewers should see runtime scope, not just the role name, especially where sessions can activate additional access on demand.
How governance has to change for runtime sessions
When access can be selected during execution, governance has to cover the full access lifecycle: granted, used, and released. That usually means stronger telemetry, tighter policy boundaries, and more explicit ownership for the session itself. The objective is to make runtime authority measurable enough that a recertification process can explain what actually happened, not just what should have happened.
This is also where Identity Security Programme Guide becomes a useful umbrella reference, because runtime governance is not solved by a single control. It needs a programme view that ties entitlement design, review cadence, logging, exception handling, and recovery together.
In mature environments, the better governance question is not “Was this access approved?” but “Was this access observable, bounded, and revocable for the entire time it could have caused impact?” That framing is much closer to how runtime systems actually behave.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime access decisions depend on controlled credential lifecycle and session authority. |
| AU-2 — Event Logging | Runtime governance needs evidence of access granted, used, and released during execution. | |
| AC-6 — Least Privilege | Dynamic tool or data selection can expand effective access beyond static approval. | |
| Recommendation — Manage session credentials so runtime authority can be issued, limited, and revoked reliably. Log access events at decision and use time to reconstruct session behavior. Constrain runtime privileges so execution cannot exceed the minimum needed. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The topic is about governing who can do what as access changes during execution. |
| Recommendation — Review access paths that can change at runtime and remove unnecessary reach. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime decisions in agentic workflows can widen authority beyond the original entitlement. |
| Recommendation — Bound agent authority so runtime tool and data access cannot silently escalate. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Runtime access decisions expose where non-human actors carry more authority than static review suggests. |
| Recommendation — Reduce standing privilege so runtime sessions cannot inherit excessive access. | ||
Practitioner Guidance
What to verify: Confirm whether your governance process can show runtime usage, not just entitlement approval. If a session can choose tools or data dynamically, your evidence set should include the decision path, the time of use, and the point of release.
Decision rule: If access can expand inside the execution path, treat provisioning review as a baseline control and add runtime monitoring or session-level approval for the high-impact steps. If the workflow cannot explain its own access path, the governance model is too static.
What practitioners underestimate: The biggest gap is often not excess privilege at assignment time, but hidden privilege amplification during execution. That is where recertification can look clean while real exposure is still growing.
Practitioner takeaway: Identity governance only remains trustworthy when it can describe what authority existed at approval time and what authority was actually exercised during the session.
Related resources from NHI Mgmt Group
- How should security teams implement runtime access decisions in identity governance?
- What breaks when identity teams automate customer onboarding and access decisions without enough governance?
- Why is it important to integrate identity and data governance?
- What is the difference between role-based access and API key governance for NHI security?