TL;DR: Agentic IGA shifts identity governance from predefined connectors and manual reconciliation toward runtime selection of APIs, SCIM, agents, and other mechanisms to onboard applications faster, according to StackBob. The governance risk is that autonomy in fulfillment can outpace the controls built for scripted workflows, not because IGA is failing, but because the operating assumptions are changing.
NHIMG editorial — based on content published by StackBob: Agentic IGA and the next evolution of identity governance
By the numbers:
- In 2025, the average small to medium organization uses 300+ applications they know of.
- Agentic IGA can take less than 48 hours to train the model on new application functionality.
- The average organisation has 30-40% of existing applications onboarded.
Questions worth separating out
Q: How should security teams govern identity actions when the execution path is chosen at runtime?
A: Treat runtime choice as part of the control surface.
Q: What breaks when IGA relies on tickets, flatfiles, and scripts at scale?
A: Coverage and consistency break first.
Q: When does agentic automation create more governance risk than it reduces?
A: It becomes riskier when the organisation cannot explain why a particular execution path was chosen, cannot verify reconciliation quickly, or cannot contain exceptions in legacy systems.
Practitioner guidance
- Define which identity actions may be runtime-selected Classify provisioning, deprovisioning, reconciliation, and entitlement changes by whether the execution path can be chosen dynamically or must remain deterministic.
- Measure connector debt explicitly Track application coverage, manual exceptions, reconciliation lag, and the number of custom scripts or bots required to keep governance working.
- Separate policy approval from execution assurance A request can be policy-approved while still failing in execution.
What's in the full article
StackBob's full article covers the operational detail this post intentionally leaves for the source:
- Its stage-by-stage history of IGA from LDAP and directory sync through cloud IGA and next-gen connector models.
- The application onboarding timing estimates and coverage calculations behind the agentic IGA adoption case.
- The comparison of service management, flatfile, and RPA/Bot fulfilment patterns in existing deployments.
- The article's testing claims about target application coverage and residual gaps in legacy systems.
👉 Read StackBob's analysis of agentic IGA and identity governance change →
Agentic IGA and the governance gap teams are missing?
Explore further
Agentic IGA is best understood as a governance model shift, not just an automation upgrade. The article describes a system that chooses the execution path at runtime, which means governance is moving from fixed connector management to decision governance over identity actions. That changes the centre of gravity for IGA programmes, because the control problem is no longer only whether access was approved, but whether the execution path remained policy-bound and explainable. Practitioners should treat this as a new governance layer, not a faster version of the old one.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why governance programmes often lose the evidence trail before they lose the access.
A question worth separating out:
Q: Who is accountable when an agentic IGA workflow partially succeeds?
A: The accountable party remains the identity owner, not the agent. Organisations need clear ownership for approval policy, execution monitoring, and exception remediation because autonomy does not remove responsibility. If the workflow fails or drifts, accountability must be traceable back to a named governance role.
👉 Read our full editorial: Agentic IGA changes the connector model for identity governance