Agentic IGA is one of the most talked-about concepts in identity security right now and also one of the most misunderstood. Is it a replacement for your existing IGA platform? A competing product category? Or something else entirely?
The short answer: it's a complement. Platforms like SailPoint, Microsoft Entra, and Saviynt do a tremendous job governing access across known, connected applications. Agentic IGA extends that foundation, reaching the applications and processes that sit just outside what any connector-based platform was designed to handle.
In this article, we walk through what traditional IGA does well, where the industry has historically faced challenges due to architectural constraints, and how Agentic IGA – as implemented by StackBob – extends the reach of your existing IGA investment.
Prefer to Watch?
I recorded a short video covering everything in this article — what Agentic IGA is, how it works alongside your existing IGA platform, and what StackBob does differently. If you'd rather watch than read, start here.
The Classical IGA Engine: Inputs, Outputs, and Access Decisions
To understand Agentic IGA, you first need to appreciate what existing IGA platforms do exceptionally well.
At its core, IGA is about inputs, outputs, and event management. When a new employee is hired and added to an HR platform, an event fires that pushes their information to the IGA system. From there, the platform reads attributes like department, job code, and employee type, and begins making intelligent access decisions: which applications does this person need?
Once those decisions are made, the IGA platform provisions accounts across target applications: Active Directory, ServiceNow, Salesforce, and others. This is the JML (Joiners, Movers, Leavers) engine in action, driven by RBAC policies configured in the platform. For applications with native connectors, this process is seamless: the IGA platform pushes access, receives confirmation, and maintains a clear record of what was provisioned.
This is powerful, mature technology. Platforms like SailPoint, Microsoft Entra, and Saviynt have spent years perfecting this engine. Agentic IGA builds on top of it — it does not seek to replace it.
The Architectural Challenge: Disconnected Applications
Every IGA platform (no matter how mature) faces a common industry-wide challenge: applications that don't have a native connector. These are called "disconnected apps," and they exist in virtually every enterprise environment. This is not a platform limitation so much as a reflection of how fast the application landscape grows relative to connector development.
How disconnected apps are handled today
When an IGA platform reaches a disconnected application during a provisioning flow, the standard approach is to fire a manual ticket (typically in ServiceNow). An admin picks up that ticket and manually provisions the user in the target application. This is a well-established workaround, and many organizations have built reliable processes around it.
That said, manual handoffs do introduce points where things can drift:
- Copy-paste errors when transferring user details from the ticket to the application
- Additional or incorrect access granted beyond what the IGA policy specified
- No closed loop — the IGA platform only knows the ticket was closed, not whether access was actually granted correctly
Flat file reconciliation
To maintain visibility into disconnected applications, organizations typically import flat files to reconcile access — a "trust but verify" approach that catches rogue access or discrepancies between what was requested and what was granted. It works, but it adds operational overhead for every disconnected application in the environment, and the data is only as current as the last import.
Access outside the governance layer
There is also a category of access that exists outside what any IGA platform can realistically govern: resources accessed through informal channels — a manager granting access via email, a department tool that was never onboarded to the IGA, a user requesting access directly from an application owner.
This is not a flaw in the IGA platform. It is a natural consequence of how organizations operate. But it does mean that the IGA platform governs what it knows about — and everything else remains in a blind spot.
Access coverage at termination
This visibility gap becomes particularly relevant at termination. When an employee leaves, the IGA platform deprovisions everything it provisioned. Applications accessed through informal channels fall outside that scope — which is where Agentic IGA can meaningfully extend coverage.
What Agentic IGA Changes
Agentic IGA addresses these gaps by replacing manual processes with automated, bidirectional connectors, even for applications that traditional IGA could never connect to.
No more disconnected apps
Through agentic capabilities, StackBob can learn and connect to applications that were previously unmanageable. Instead of firing a manual ticket, the system handles provisioning directly, with the same reliability as a native connector.
Bidirectional connectors
Traditional connectors are largely one-directional: push access, wait for a flat file to confirm it. StackBob's connectors are fully bidirectional: they push access and continuously pull status back, maintaining near real-time reconciliation without flat file imports.
This means your upstream IGA platform always has an accurate, current view of access across target applications, not a snapshot from the last batch import.
Full environment visibility
By connecting to previously disconnected applications, Agentic IGA brings them into the governance layer. Over time, this closes the visibility gap, giving your IGA platform a full or near-full picture of access across the environment, including applications it never had insight into before.
How StackBob's Agentic IGA Works in Practice
StackBob sits between your upstream IGA platform and your target applications. It does not replace your IGA — it extends it.
When your IGA platform (SailPoint, Microsoft Entra, Saviynt, or others) fires a provisioning request, it hits the StackBob layer. From there, StackBob's Bob Agents pick up the activity just like a normal connector and reach out to the target application to provision access.
Critically, StackBob uses a fan-out approach: each application gets its own individual connector within the StackBob platform. They are not consolidated into a single connector. Each application has its own entitlements, maps to the relevant JML operations, and behaves like a native target from the upstream IGA's perspective.
At the same time, Bob Agents are continuously reconciling access in those applications, pulling current data back into the StackBob platform so it is ready when the upstream IGA runs its next aggregation job.
StackBob recently released its Microsoft Entra ID native reconciliation flow, closing the loop for application provisioning and reconciliation on the Entra platform — a significant milestone for organizations running Microsoft-centric identity stacks.
Who Should Consider Agentic IGA?
If your organization has disconnected applications creating manual provisioning bottlenecks, Agentic IGA is worth evaluating. If your termination process leaves residual access in applications outside your IGA's current scope, Agentic IGA extends coverage there. If your reconciliation process relies on flat file imports and batch jobs, Agentic IGA can automate and accelerate that.
Most importantly: if you have already invested in a mature IGA platform — SailPoint, Microsoft Entra, Ping Identity, or others — Agentic IGA is designed to work alongside it, not against it. Your existing platform remains the governance engine. StackBob extends its reach into the applications and processes it could not previously touch.
For IGA practitioners who have spent years building out identity programs, this is not a rip-and-replace conversation. It is about getting more value out of the investment you have already made.