The term is being applied to almost anything at the moment, which is what happens to a good phrase before anyone pins it down.
So here is a definition with enough substance to argue with.
Agentic IGA has two halves
AI does the governance work. Not one step of it. The whole spectrum: connecting every app, running the joiner, mover and leaver workflows, surfacing what is orphaned or risky or over-provisioned, and producing the evidence at the end. If it stops at the access request, it is doing the easiest part of identity governance and calling it the category.
The agents themselves get governed. Every AI agent, service account, API key and OAuth grant is a first-class identity with an owner, a scope, an expiry and an audit trail. Including the ones an engineer spun up under their own account, which get revoked when that person leaves.
Both halves, or it is not the thing. A platform that automates provisioning but cannot see the MCP server your engineering team shipped last quarter has solved the 2019 problem well.
How to tell it from an AI sticker
There is a version of this that is a chatbot bolted onto an access-request form. It takes a request in natural language, grants the access, closes the ticket, and reports that AI handled it.
That is not governance. It stops at the request and governs nothing afterwards. Nothing watches the grant, nothing notices when it goes cold, nothing removes it when the person changes teams, and nothing produces evidence at the end of the quarter.
Six things, and the honest test is whether all six are covered:
Connect. Every app, including the ones with no SCIM, because governance that only reaches the well-behaved half of your stack is a partial answer wearing a complete one's clothes.
Provision. Joiners, movers and leavers, from the HR record rather than a checklist.
Revoke. Which is the half everybody skips, because removal is the part with no deadline attached.
Watch. Continuously, between reviews, not once a quarter.
Recommend. What is orphaned, what is unused, what is over-scoped, and what somebody should look at first.
Prove. Evidence written as the work happens, mapped to the controls an auditor asks about.
433 identities. 321 human, 112 not. cc_github and the MCP token sit in the same table as Amy Lee, with the same columns and the same offboarding states.
The second half of the definition is visible in that header. Human 321, Non Human 112, one list. A platform that treats agents as a separate module has answered the question with a second product rather than with governance.
The platform should stop being a destination
Here is the argument that matters most, and it is about distribution rather than intelligence.
The dominant pattern right now is a vendor building an agent inside their own product. It is capable, it messages approvers, it works across Slack and email, and it does real work. It is also, structurally, still a place you go. The intelligence belongs to the vendor and you interact with it on their surface.
Iden is the other shape. There is no Iden agent to talk to. Iden is a set of tools that your agent calls, while you are doing something else.
An engineer in a coding session needs a teammate added to a service. They do not open an identity console, or a ticket form, or a chat with a vendor's assistant. They say it in the session they are already in, their agent resolves the identity, checks the policy, and files the request. The identity work happens inside the task that generated it.
That is the difference between an assistant that helps you use identity software and identity software that no longer needs you to use it.
Why this is not reckless
Three constraints, and they are what let the surface be this open.
Access is delegated, never held. When an agent calls Iden it carries the identity of whoever invoked it: the admin running the action, or the end user asking for access. The agent has no standing of its own. Every line of the audit trail names a human.
It files, it does not grant. The model works out what is being asked for, who owns it, and which policy applies. Then it creates an access ticket, and that ticket follows the approval workflow the admins defined. The intelligence is in getting the request right. The decision stays exactly where it was.
The surfaces are different doors to the same house. A coding agent, Slack, the console and the API are separate entry points into one policy engine and one record. Which door the work came through is a field in the log, not a different set of rules.
One app's accounts. billing@, hs-syn@ and an MCP integration user are in the list with everybody else, carrying the same profiles and permission sets.
Down at the app level the same thing holds: three of those Salesforce accounts are integration users, carrying the same profiles and permission sets as the people around them.
The policies are the whole safety story. An agent that can only create tickets against rules an admin wrote is not a new attack surface, it is a faster path into an existing control.
What actually changes
What this does not mean
It does not mean an AI decides who gets access. It decides what the request is, and a policy or a person decides whether to grant it.
It does not mean the console goes away. Configuration, campaigns and anything you want to look at properly still want a screen, and everything available to an agent is available there.
And it does not mean the model is doing anything clever with your entitlements. The determinism is the point: each action is one tool call with defined arguments, so it does what was asked rather than approximating it. An identity system built on a model that improvises would be an interesting demo and an unusable product.