Agentic identity governance is reshaping enterprise access control

At a glance

What this is: Lumos argues that identity governance is moving from manual access control toward agentic software that can decide and act on access decisions.

Why it matters: IAM teams need to understand this shift because the same governance model now has to cover human users, service accounts, and AI agents with different access lifecycles and risk profiles.

By the numbers:

• In Q2 2025, the 18 largest cybersecurity vendors grew 14.6%, outpacing overall IT spend at 8% and GDP at 2%.
• More than 70% of breaches use identity techniques.

👉 Read Lumos's view of agentic identity governance and access control

Context

Agentic identity governance is the problem of deciding what software entities can access, for how long, and under what oversight when those entities can now act on their own. The governance gap appears when identity programmes still assume access decisions are static enough to be handled through tickets, rules, and periodic review.

That assumption is breaking because enterprises now have human users, service accounts, and AI agents sharing the same access surface. Identity teams are being asked to govern faster-moving workloads without a matching increase in staff, which makes manual certification and spreadsheet-driven control sets increasingly fragile.

Key questions

Q: How should security teams govern AI agents that can act on their own?

A: Treat AI agents as a separate identity class with bounded tool access, explicit purpose scoping, and auditable execution. Do not rely only on static entitlements or quarterly reviews. Governance should focus on what the agent can do at runtime, what evidence is captured, and where the execution chain can be interrupted before a risky action completes.

Q: Why do access reviews struggle with agentic identity?

A: Access reviews assume privilege persists long enough to be observed and certified. Agentic systems can gain, use, and release access inside a short session, so the entitlement may no longer exist by the time review happens. That makes the gap structural, not just procedural, and requires runtime evidence rather than after-the-fact attestation.

Q: What breaks when RBAC is used for AI agents without extra controls?

A: RBAC breaks when it is asked to describe highly variable tool use with static roles. Agents can change what they need based on context, so role design becomes stale quickly and can over-grant access to cover every possible path. Teams need tighter scoping, purpose limits, and logging around each action path.

Q: Who is accountable when an AI agent takes a risky action?

A: Accountability should sit with the team that defined the agent's policy, scope, and approval boundaries, not with the agent itself. If the agent can execute without a human gate, then the organisation must be able to show who authorised the capability, what constraints were set, and how the outcome was recorded.

Technical breakdown

Agentic identity versus traditional access automation

Traditional access automation can approve or route requests, but it still depends on prebuilt rules and human-defined decision paths. Agentic identity changes the model because the software can interpret context, choose tools, and complete a workflow from intent to outcome. That is a different control problem from classic IAM, which assumes access is granted before use and reviewed later. In an agentic flow, the important question is not only who approved access, but whether the system can safely decide what to do next without becoming over-broad or self-reinforcing.

Practical implication: separate workflow automation from autonomous decision authority in your identity architecture.

Why RBAC and access review struggle with AI agents

Role-based access control works best when access patterns are stable enough to map into reusable job functions. AI agents make that assumption weaker because their tool use can vary by task, data context, and runtime feedback. Access review also becomes harder because a review cycle can only certify what exists long enough to be observed. If an agent can acquire, use, and discard access inside a short execution window, the governance artefact arrives after the event and misses the real exposure.

Practical implication: treat agent access as runtime governable, not only reviewable after the fact.

MCP, tool calling, and the identity layer for autonomous software

Model Context Protocol connects agents to tools and data sources, which makes the identity layer part of execution rather than a passive control plane. Once an agent can select a tool and invoke it in context, identity is no longer just authentication or entitlement storage. It becomes the boundary that determines what the agent may do, what evidence is logged, and where the execution chain can be interrupted. The security issue is not tool use alone, but the combination of tool access, context, and delegated action inside one runtime session.

Practical implication: govern tool access, context scope, and execution logging as one control surface.

NHI Mgmt Group analysis

Agentic identity governance is becoming a distinct discipline, not a rebrand of IAM. Traditional IAM assumes the subject is either a person or a non-autonomous service principal with a relatively stable access pattern. AI agents break that assumption because the actor can evaluate context and complete actions at runtime, which moves the control problem from static entitlement assignment to governed execution. Practitioners should stop treating agents as simply another workload and start treating them as a separate governance class.

Access review was designed for access that persists long enough to be reviewed, and that assumption fails when the actor is autonomous. In agentic workflows, privileges may be acquired, used, and discarded inside one session, leaving no stable state for quarterly certification to inspect. The implication is not just that reviews are too slow, but that the review model itself presumes a human-paced access lifecycle that no longer exists.

Identity blast radius is now the key design variable for autonomous software. Once an agent can chain tool calls, the issue is no longer a single permission but how far one decision can propagate across systems, data, and downstream actions. That makes containment, scoped delegation, and evidence capture more important than broad permission sets that look efficient on paper but expand operational risk.

Agentic software forces identity teams to govern outcomes, not just entitlements. When a system can act on its own, the control question becomes whether the enterprise can bound the actions it is allowed to complete and prove what happened afterward. The practical conclusion is that access governance, auditability, and operational accountability must converge around runtime behaviour.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, leaving a large portion of delegated access outside direct oversight.
• For a broader view of agentic risk, see OWASP NHI Top 10 for the control patterns practitioners are using to bound agent behaviour.

What this signals

Agentic identity is pushing governance from review cycles to runtime boundaries. When software can choose actions in context, teams need to know where delegation starts, where it ends, and what evidence survives the session. The useful control question is no longer only whether access was approved, but whether the organisation can reconstruct the path the agent took and prove it stayed inside policy.

With 80% of organisations reporting that AI agents have already performed actions beyond intended scope in recent research, the operational signal is clear: policy is not enough without execution controls. That makes least privilege, logging, and scope validation part of the same design conversation rather than separate programme streams.

Runtime governance gap: this is the failure mode where a programme can describe entitlements but cannot reliably bound action. Teams should expect agent deployments to expose weak ownership, unclear approval paths, and logging that captures access but not intent or outcome.

For practitioners

• Define an agent identity classification policy Create a policy that separates human users, service accounts, and AI agents in your IAM and IGA models so reviews, approvals, and monitoring match the actor type.
• Map runtime permissions to specific tool and data scopes Inventory every tool, API, and dataset an agent can reach, then tie each one to a bounded purpose, approval rule, and logging requirement.
• Rework access reviews for short-lived execution Test whether your certification process can still detect risk when access is acquired and consumed within one session, then adjust evidence collection accordingly.
• Instrument delegated actions with audit-grade logs Record the agent's input context, selected tool, output, and downstream side effects so you can reconstruct the full decision chain during investigation.

Key takeaways

• AI agents change identity governance because they can make and execute access decisions at runtime, which static IAM models were not built to absorb.
• The biggest governance weakness is not just over-provisioning, but the assumption that access will persist long enough to be reviewed and certified later.
• Practitioners need to classify agent identities separately, bound their tool access tightly, and prove what the agent did through audit-grade runtime evidence.

Key terms

• Agentic identity: An identity model for software that can decide and act at runtime rather than only follow fixed automation. In practice, it requires governance over the actor's tools, timing, and permitted outcomes, not just authentication or a static entitlement record.
• Identity blast radius: The maximum operational damage a single identity can cause if misused or over-scoped. For autonomous and non-human actors, blast radius depends on how many systems, datasets, and downstream actions a delegated session can reach before controls intervene.
• Runtime governance: Control of identity behaviour while an action is happening, not only before access is granted or after it is reviewed. It combines scope limits, logging, policy enforcement, and interruption points so the organisation can constrain decisions as they occur.

What's in the full article

Lumos's full article covers the operational detail this post intentionally leaves for the source:

• How the vendor frames Albus as an identity agent and where it fits in the access workflow
• The product narrative around autonomous software, including the examples used to explain agentic decision-making
• Lumos's view of how RBAC, lifecycle management, and access governance should evolve in an AI-native identity model
• The customer examples and implementation anecdotes the vendor uses to illustrate workflow scale and role design

👉 Lumos's full article expands on autonomous software, RBAC, and the role design examples behind Albus.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.