Governing AI Agent Identities: An Identity Maturity Model for AI Agents
As agentic AI adoption grows, traditional IAM breaks down. Learn how to assess agent identity maturity, reduce blast radius, and make time-to-revocation the metric that matters.

Krishanu
A support agent reads a ticket. Below the customer's actual question sits a line of text instructing the agent to look up a different customer's account details and include them in the reply. The agent complies because the instruction is well-formed and its token has the permission.
Nothing in that sequence is a breach in the conventional sense. No credential was stolen, and no control failed in the way controls are supposed to fail. The agent authenticated correctly, called an API it was authorized to call, and returned data it was permitted to read. The problem is what "permitted to read" turned out to cover, which was the entire customer table, because the token was minted from an existing integration role during a two-week pilot and nobody narrowed it to the one lookup this agent performs.
The incident review will spend its first hour on the injected instruction, but the cost of the incident depends on what else that token could reach. In most organizations, that answer takes days to assemble, because it was never written down. The pilot ended, the agent stayed, and the credential kept the scope it started with.
The same question now appears in government guidance. In May 2026, six national cybersecurity agencies across the Five Eyes nations published joint guidance on adopting agentic AI, naming privilege risk as a primary concern and least privilege as critical.
Why agent identities break traditional IAM
A conventional service account performs a narrow, predictable task. Its scope is fixed at design time by a human who considered it once, and the controls around it are well understood because the behavior does not change.
An agent receives an intent, decomposes it into steps it was not given in advance, and calls whichever tools it judges appropriate. Its scope is not fixed at design time. It is determined at runtime, every time it runs. Three consequences follow.
MFA is unavailable. The control that carried human identity security for a decade cannot apply to a process, which leaves static secrets protected by nothing but the hope they never leak.
There is no joiner-mover-leaver equivalent. Nobody offboards an agent. It outlives its purpose and retains its access indefinitely, which is a backdoor your own team built.
The population is larger than IAM was sized for. Non-human identities already outnumber human ones by better than 50 to 1 in many enterprises, and quarterly access review does not survive contact with a population that grows daily.
The identity dimension of agentic risk
In December 2025 the OWASP GenAI Security Project published the Top 10 for Agentic Applications, the first industry taxonomy built for systems that act rather than systems that answer, covering categories ASI01 through ASI10.
Five of the ten resolve to a single question. ASI03 is identity and privilege abuse outright. ASI02, tool misuse, concerns which interfaces a credential may touch. ASI01, goal hijack, describes an attacker redirecting an agent, but the damage is bounded entirely by what that agent's identity can reach once redirected. ASI04 concerns trust granted to third-party tools and MCP servers, and ASI10 covers agents that drift or are compromised and keep operating. In each case the question is what the credential could do at the moment the agent went wrong.
The support agent above is that pattern. Injection is the delivery mechanism and permissions are the payload. Had that token been scoped to a single lookup and expired with the pilot, the same attack produces a logged anomaly instead of a disclosure.
Six requirements before production deployment
Below this line, an agent deployment is difficult to defend regardless of how the rest of the program scores.
A uniquely attributable identity per agent, never shared with another agent or a human administrator. If two things act under one credential, the audit trail answers nothing.
A named owner recorded at creation, not assigned retroactively. Accountability has to exist before an incident rather than be reconstructed during one.
Permissions justified against a stated purpose, rather than inherited from a role or copied from the previous agent.
A credential lifetime shorter than the detection window. A one-year key against a three-day detection capability is doing no work.
A complete audit trail per identity. Every action logged with timestamp, executing identity, and outcome, routed somewhere the detection stack actually reads. Fragmented logging cannot reconstruct what an agent touched.
A tested revocation path measured in seconds. If you have never run it, you do not know your revocation time.
An organization that cannot meet these six has a deployment readiness problem, and should fix that before scoring itself against a maturity model.
The five-stage maturity model

Stage | Defining criterion | What you can answer mid-incident | Blast radius |
|---|---|---|---|
1. Untracked | No inventory. Standing credentials, inherited permissions, no owner. | Nothing. Agent activity is invisible to forensics. | Critical |
2. Discovered | Identities inventoried, though inventories go stale. Scope not assessed. | Which credentials exist. Not what they reach or who owns them. | High |
3. Contextualized | Each identity correlated to owner, purpose, and actual permissions. Excess privilege surfaced. Reviews periodic. | Who owns it, what it was for, what it could reach. Not whether it exceeded that. | Medium |
4. Right-sized | Least privilege enforced per identity. Standing credentials replaced with scoped, time-bound access. Detect and revoke in real time. | Whether the action was in scope. Containment is provable. | Low |
5. Governed | Registration, ownership, rotation, expiration, and segregation automated at creation. Continuous enforcement, forensic-ready trail. | Everything, without manual investigation. Anomalies pause or revoke automatically. | Minimal |
Stage 1, Untracked. Agents run on credentials nobody has catalogued. Keys are issued by whoever builds the agent, permissions arrive inherited from an existing role, and no name is attached to either. During an incident, there is nothing for forensics to work from, and the question of what a compromised credential could reach has no answer at all.
Stage 2, Discovered. Every agent identity appears in an inventory, though the inventory goes stale and the scope of each credential is recorded rather than assessed. Exposure is unchanged from Stage 1: permissions are still broad, and nothing is watching for misuse. What the inventory removes is the unknown portion of the estate, which every stage above depends on, because a credential you cannot see cannot be scoped. Most programs stop here, since discovery produces a figure that grows each quarter while the next stage produces one that goes down.
Stage 3, Contextualized. Each identity has a named owner, a written purpose, and a measured set of permissions, which makes excess privilege and stale access visible per agent. The audit trail is reviewable, and anomaly detection works for the first time, since a baseline needs a stated purpose to deviate from. Enforcement is still periodic review rather than a control, but the fleet can now be sorted by exposure instead of treated as uniformly urgent.
Stage 4, Right-sized. Permissions match purpose, and standing credentials give way to scoped, time-bound access. A leaked credential expires on its own and can be revoked in real time before it is useful, so a compromise is contained rather than investigated. This is the first stage at which all six requirements above are met. It is also the stage most often claimed on the strength of a secrets manager, which is a different thing: vaulting changes how a credential is stored and nothing about what an agent holding it can reach.
Stage 5, Governed. Registration, ownership, scoping, rotation, expiration, and segregation happen at creation with no human in the path, policy is enforced continuously, and every identity carries a forensic-ready trail. The difference from Stage 4 is scale. Stage 4 governs the agents someone reviewed. Stage 5 governs the ones deployed next week by a team that did not tell you.
Measuring maturity: time to revocation
Coverage is the natural metric and the wrong one. Reporting that 94% of agent identities are inventoried says nothing about what those identities can reach or how quickly any of them can be stopped.
The figure worth reporting is the interval between a credential being compromised and that credential becoming useless. It cannot be low unless discovery is current, ownership is known, scope is bounded, and revocation works, which is why one number can stand in for the whole model. Coverage can sit at 100% while time to revocation runs to weeks. The reverse is not possible.
One related discipline: do not average agent identity governance into a single organizational score alongside human identity governance. A mature human IAM practice beside Stage 1 agent governance averages to something reassuring, and the average conceals that the ungoverned half is the identity class with the largest and least predictable scope of action.
Where to start
Control has to live at the identity layer, where access is decided, and it has to operate at the speed the agents do, because quarterly review will not begin running weekly out of goodwill.
The honest first step in adopting a maturity model is not to score well. It is to score truthfully, report agent identity separately from human identity, and treat the gap between them as the first roadmap item rather than the last. Run the revocation drill. Finding out on a Tuesday afternoon is considerably cheaper than finding out on an incident bridge.
Permissions do not change between Stage 1 and Stage 2. They are broad and inherited in both, and threat response is absent in both. Stage 2 buys visibility and no control.
Stage 2 still feels like substantial progress, because discovery produces an artifact: a dashboard, a count, a figure that grows each quarter. Moving from Stage 2 to Stage 3 produces nothing comparable. It produces an owner's name attached to a credential and a written purpose it can be measured against, which is organizational work involving other teams, tracked by a number that mostly goes down.
The related error is treating vaulting as scoping. Moving a standing admin credential out of a config file and into a secrets manager improves how it is stored. It changes nothing about what happens when an agent holding it is hijacked. Storage hygiene and scope are independent, and scope is where blast radius is decided.
Experience enterprise-grade Agentic Security solution

