Identity governance is shifting as non-human identities outnumber humans

At a glance

What this is: This podcast discussion from Omada Identity argues that identity governance is becoming a risk-management problem as non-human identities and AI agents outscale human-centric controls.

Why it matters: It matters because IAM teams need metrics, ownership, and Zero Trust evaluation models that can govern machine and agent identities continuously, not just at review time.

By the numbers:

• 95 percent of leaders now treat identity security, y security as core to their strategy.
• Non-human identities and AI agents often outnumber human accounts by more than 100 to 1.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Watch Omada Identity's podcast on the State of Identity Governance 2026 findings

Context

Identity governance breaks down when teams still optimize around human users while machine identities, service accounts, and AI agents proliferate across applications and infrastructure. The result is a visibility and accountability gap: leaders can say identity matters, but operational controls often stop at periodic review and static entitlements rather than continuous risk evaluation.

Omada Identity's podcast frames that mismatch as a governance maturity problem rather than a tooling problem. For IAM and NHI practitioners, the practical question is whether the programme can assign ownership, detect risky behaviour in connected systems, and prove that access decisions reflect current context instead of historical approval.

Key questions

Q: How should security teams govern non-human identities at enterprise scale?

A: Security teams should govern non-human identities through ownership, lifecycle control, and runtime policy enforcement. That means every service account, token, certificate, or AI agent needs a named owner, a defined purpose, expiry or review cadence, and monitoring for unusual use. Periodic certification alone is not enough when identities can be created and used automatically.

Q: Why do AI agents require continuous access evaluation?

A: AI agents can change behaviour during execution, chain tool calls, and reach systems that were not part of the original approval. Continuous evaluation checks whether current context still justifies access, which reduces overreach and limits blast radius. Without it, a once-approved task can turn into unintended privilege expansion.

Q: What is the difference between activity metrics and risk metrics in IAM?

A: Activity metrics show how much governance work happened, such as reviews completed or policies enforced. Risk metrics show what exposure remains, such as identities without owners, stale credentials, or privileged access that is no longer justified. For NHI programmes, risk metrics are more useful because they describe the attack surface, not the workload.

Q: When does Zero Trust become more than a policy label for NHI governance?

A: Zero Trust becomes meaningful when access is re-evaluated at runtime and tied to current identity state, task scope, and system context. For non-human identities, that means no standing assumption that yesterday's approval still applies today. If access is not continuously checked, the programme is still operating on static trust.

Background and context

Why human-centric governance fails for NHI sprawl

Traditional IAM assumes each identity maps to a person, a manager, and a stable access pattern. Non-human identities do not behave that way. Service accounts, API keys, tokens, certificates, and AI agents can be created by automation, inherit access indirectly, and keep working long after the original business purpose changes. That makes periodic review insufficient on its own. The architectural issue is not just volume, but ambiguity: teams often cannot tell who owns an identity, which system issued it, or whether its privileges still match the task it performs.

Practical implication: inventory machine identities by ownership, purpose, and lifecycle state before trying to optimize policy.

What continuous Zero Trust evaluation means for AI agents

Zero Trust for AI agents means access decisions should be re-evaluated as context changes, not granted once and assumed safe. An agent may be trusted to perform one task, then chain tool calls, access new systems, or act on stale instructions. Continuous evaluation therefore needs telemetry on identity usage, destination systems, scope changes, and anomalous behaviour. In practice, this is closer to runtime authorisation than classic joiner-mover-leaver governance. The control objective is to limit the agent's blast radius as it acts, not just to approve it before deployment.

Practical implication: treat agent access as ephemeral and context-bound, with policy checks at execution time.

Risk-based dashboards reveal more than activity counts

Counting logins, approvals, or certification completion gives leadership activity data, not risk data. For NHI and agentic environments, a useful dashboard should surface identities without owners, secrets with excessive lifespan, privileged connections that are rarely used, and agents interacting with sensitive systems beyond intended scope. The point is to show exposure, not just throughput. That shift matters because a mature programme can have high control activity and still carry unacceptable latent privilege. Risk metrics make the gap visible where compliance metrics often hide it.

Practical implication: replace vanity metrics with exposure-oriented indicators that show where access is unsafe now.

NHI Mgmt Group analysis

Non-human identity governance is now a control-plane problem, not a reporting problem. When machine identities and AI agents outnumber humans, the core risk is not whether teams can document access. The question is whether they can govern execution authority across systems that change faster than certification cycles. Practitioners should move from retrospective attestation to lifecycle control and runtime enforcement.

Identity blast radius is the right concept for agentic environments. AI agents and service accounts are useful precisely because they can act across multiple tools, but that also means a single weak credential can create disproportionate exposure. The practical goal is to reduce how far one identity can move, what it can touch, and how long it can persist without review. Security teams should measure blast radius before they measure volume.

Risk-based governance must replace activity-based governance. Executive dashboards that celebrate completed reviews and policy counts can mask unresolved exposure. In agent-heavy environments, ownership gaps, stale privileges, and unattended credentials matter more than process throughput. Practitioners should prioritize metrics that answer whether access is still justified, whether it is still observable, and whether it can still be revoked quickly.

Continuous evaluation is becoming the minimum viable operating model for Zero Trust in IAM. Static approval models were built for slower identity lifecycles and clearer human accountability. They do not cope well with AI agents that can act, re-plan, and chain privileges in seconds. Teams should treat Zero Trust as a runtime discipline for non-human identities, not a policy label attached to periodic reviews.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why practitioners should pair governance controls with the OWASP NHI Top 10 and runtime identity controls.

What this signals

Identity governance is moving toward runtime accountability. The teams that will cope best with agentic systems are the ones that can answer three questions in real time: who owns the identity, what can it reach, and why is it still active. Static recertification remains useful, but it no longer defines control maturity when agents can act faster than review cycles.

AI agent governance should be treated as an identity risk programme, not a point solution problem. With 96% of technology professionals already seeing AI agents as a growing threat, the operational question is whether IAM, security operations, and compliance are using the same exposure model. Teams that align policy, telemetry, and revocation will find it easier to defend their decisions to auditors and executives alike.

Blast radius is the metric that should shape planning. If one identity can touch multiple systems, shared data sets, and production workflows, the organisation needs to know how far failure can travel before it happens. That is why the next phase of NHI governance will be measured by containment, not by access volume.

For practitioners

• Inventory all non-human identities with ownership metadata Build a single register for service accounts, API keys, tokens, certificates, and AI agents. Record owner, business purpose, issuance source, last use, and downstream systems touched so revocation is possible when risk changes.
• Replace activity metrics with exposure metrics Track identities without owners, credentials older than policy, and privileged accounts that access sensitive systems outside normal patterns. Use those indicators in executive reporting instead of review counts alone.
• Apply runtime policy checks to AI agent actions Require policy evaluation at execution time for tool calls, data access, and cross-system actions. Limit permissions to the current task and block escalation when context changes or scope drifts.
• Shorten the lifecycle of standing credentials Reduce persistence for service credentials and rotate secrets on a schedule that reflects real usage, especially for identities that can reach production systems or sensitive data stores.

Key takeaways

• Non-human identities and AI agents have pushed identity governance past human-centric assumptions, making ownership and runtime control essential.
• Executive confidence in identity security does not eliminate exposure when machine identities can multiply faster than review processes can keep up.
• Practitioners should shift from activity reporting to exposure management so they can reduce blast radius and prove access is still justified.

Key terms

• Non-Human Identity: A non-human identity is any account or credential used by software rather than a person. That includes service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities often scale faster than human governance processes, which is why ownership and lifecycle controls matter.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is misused or compromised. It is shaped by reach, privilege depth, and how long access persists. In NHI environments, reducing blast radius is often more practical than trying to eliminate every identity risk at once.
• Runtime Authorisation: Runtime authorisation is the practice of checking access at the moment of action rather than only at setup or approval time. For AI agents and other NHIs, it helps ensure that current context, task scope, and system state still justify the requested access.

Deepen your knowledge

NHI lifecycle governance and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme to govern AI agents and machine identities, it is worth exploring.

This post draws on content published by Omada Identity: a podcast discussion of the State of Identity Governance 2026 report and the rise of non-human identities. Read the original.