Agentic IGA is identity governance done by software that acts, rather than software that waits for a ticket. The term arrived in 2026 as vendors across the category rewrote their positioning around AI agents. It is used loosely enough that a definition has to do two jobs: say what the agents do, and say what happens to the agents themselves.
The two halves, and the test
THE WORK (AI does the governance) THE SUBJECT (the agents are governed) ----------------------------------- -------------------------------------- connect every app, SCIM or not each agent has a named human owner provision on join, change on move a scope: what it may reach revoke on leave, in one run an expiry, and a place in the review review: surface what changed an audit trail: what it did, for whom recommend what to fix revoked when its owner leaves prove it to an auditor
What are the two halves?
| First half: what the agents do | Second half: what happens to the agents | |
|---|---|---|
| Subject | The governance work | The agents themselves, and every other agent employees create |
| Scope | Connect, provision, review, revoke, recommend, prove, across the whole lifecycle | Owner, scope, expiry, review, audit trail, for every agent |
| Without it | A workflow engine with a language model in front of it | A policy document |
| Test | How much of the stack the agent reaches without a person in the loop | Whether the agent would pass the review it runs |
The work the agents do
In agentic IGA, an AI agent connects the applications a company runs, including the ones without SCIM or an API, and creates and removes accounts as people join, move and leave. It runs the access review by surfacing what has changed and what looks wrong, revokes what a reviewer rejects, recommends what to fix, and produces the evidence an auditor asks for. The agent does the governance across the whole lifecycle, not one step of it.
The agents as subjects
The agents doing that work, and every other AI agent an employee spins up, are identities. Each one has a named human owner, a scope that says what it may reach, an expiry and a place in the access review. Each one leaves an audit trail of what it did and on whose behalf. An agent that an employee created under their own account is revoked when that employee leaves, the way their other access is. A commenter on a widely read thread about an agent that deleted a production database located the failure precisely:
The confession framing is the wrong lesson. The agent didn't delete the database, someone gave the agent write access to production. The culprit is in the IAM policy, not the prompt.
Why neither half stands alone
A product with one half and not the other is not agentic IGA. Automation that provisions but governs nothing is a workflow engine with a language model in front of it. It moves accounts faster than a ticket queue, and it answers neither who approved a grant nor whether the grant is still needed. Governance of agents without automation of the lifecycle is a policy document. It names owners and expiries for identities that no system is watching, which is a register rather than a control. The two failures compound, because automation that creates access at machine speed raises the cost of having no review behind it.
Iden's definition of agentic IGA is the one on this page, and the Action Center is where the first half shows: findings across every connected application, orphaned and overprovisioned accounts among them, resolved by automation and confirmed by a person. The second half is the Identities screen, where agents and service accounts sit in the same table as employees, each with an owner, a scope and a place in the review. The feature behind it is Service accounts, API keys and agents.
Findings als Eingang. Links Kategorien und Anzahl, rechts die Warteschlange, zwei Kategorien stehen schon auf null. Angelina wurde vor drei Tagen offgeboardet und hält noch sechs Applikationen.
What is the test?
The clearest test is where the automation stops. Take an access request from an employee, made in Slack, to an AI assistant.
| Step | A chatbot with an AI badge | Agentic IGA |
|---|---|---|
| Request | Parses the message | Parses the message |
| Decision | Checks a policy, grants, closes the ticket | Checks a policy, grants, records the grant with the reason |
| After the grant | Nothing | The grant enters the review population, expires or is recertified |
| Role change | Nothing | The grant is revoked when the person changes roles |
| Evidence | The closed ticket | The request, decision, grant, review and revocation as a record |
| The assistant itself | Not an identity anywhere | An identity with an owner, a scope and a place in the review |
| The assistant's creator leaves | Nothing | The assistant is reassigned or revoked with the rest of their access |
Where the two products diverge
The chatbot is an access-request form with a conversational front end, and it stops at the request. Every row below the decision is lifecycle work. An expiry, a recertification, a revocation on a role change, and a record that survives the closed ticket are the parts a request form never had. A product that automates the intake and none of that has moved the queue and left the governance where it was.
The questions applied to the product itself
Agentic IGA keeps going past the request, into the rows beneath it. The first test is whether the product can answer, for its own agents, the four questions it answers for people. Who has access to what, why, whether it is still appropriate, and how that is proven. The harder version of the test is what an auditor would find when sampling accounts inside a connected application. An agent with an owner, a scope and a row in the review passes it. A shared administrative credential created during implementation and untouched since does not, whatever the product does for everyone else's identities.
Why did the term appear now?
Two things happened at once, and the word was coined for only one of them.
The capability arrived
Language models became good enough to read an application's admin console, interpret a policy and take a bounded action. That made automating the long tail of applications without SCIM practical for the first time. The work those applications need is the work that resisted automation for a decade: a form filled in a browser, a role picked from a dropdown, a confirmation dialog acknowledged. Nothing changed on the protocol side, and no vendor shipped a connector that did not exist before. What changed is that the step in the middle no longer needs a person.
The population arrived
Employees started creating agents of their own, in coding tools, in chat platforms and in automation products. Each of those agents holds OAuth grants, API keys and delegated permissions that outlive the task and often the person who created it. This population grows without a purchase order, a ticket or an inventory entry, which is why the second half of the definition is the half most companies have not started on.
Why vendors adopted half the word
The first change made agentic automation possible, and the second made governing agents necessary. Vendors in the category adopted the word for the first change and have been slower on the second. The first is a feature, and the second is an admission that the inventory is incomplete. Standards work has moved in the same order. The Model Context Protocol authorization specification puts an OAuth model around an agent's access to tools. NIST has asked for public comment on what securing agents requires. Neither settles what an access review row for an agent should contain. On the thread about that request for comment, one commenter separated the checkbox from the control:
What we actually need is runtime behavioral monitoring: what files is the agent accessing? What network calls is it making? What credentials can it reach? That's where the real threat surface lives.
And the least-privilege design that governance has to enforce was described years before the current wave, in a thread on prompt injection:
You don't give the AI "admin" access. You treat different capabilities as different users with least privilege. Agents can't direct other agents. Yes it limits the capabilities.
What does governing an agent require?
The same three things every non-human identity needs, with one addition.
1An owner
A named person who answers for the agent, approves its scope and is the trigger for reassigning it when they leave.
2A scope and an expiry
The smallest set of systems and actions the task needs, and a date on which the agent is re-justified or removed. An agent's scope is its primary control, because the agent decides at runtime which of its permissions to use.
3A place in the lifecycle
The agent is created through a path that records it, appears in the access review, and is revoked when its owner leaves or its task ends.
4An audit trail of actions
The addition. A service account does the same thing every night. An agent does different things on different days, so the record has to cover what it did and on whose behalf, not only what it could do.
Does agentic IGA depend on SCIM?
No, and this is where the term earns its keep or does not.
Where SCIM-bounded automation stops
An agent that only acts through SCIM is bounded by the applications that expose SCIM on the plan the company pays for, which in a typical stack is a minority. That boundary is invisible from inside such a product. An application with no connector never appears in a finding, and a screen with no findings reads as a screen with no problems. Everything past the boundary degrades into a recommendation for a person to carry out by hand. The governance record for those applications is then a note saying that someone was asked.
What reaching the rest requires
Agentic governance that covers the whole stack has to work over an application's API where one exists and drive the admin console where one does not. What it reads is the account list the application itself holds, rather than the identity provider's view of it. The two lists diverge for ordinary reasons: an account created inside the product, an invitation sent by a colleague, a login that predates the identity provider. The applications outside SCIM are where the orphaned accounts and the ungoverned agents live.
The two maturity questions
The maturity of an agentic IGA product is measured first by how much of the stack it can reach without a person in the loop. The unit of that measure is applications governed end to end, not connectors listed on a website. It is measured second by whether its own agents would pass the review it runs. Iden's definition of the term, and the maturity model built on it, are at /agentic-iga.