A guide to governing non-human identities, including service accounts, OAuth apps, bots, and AI agents, across your stack.

Identity governance was built for people. The identity estate moved on

For most of its history, identity governance had one dependable anchor: a person. An employee joined, a manager approved access, HR recorded a role change, and a departure triggered offboarding. Even when identity data was spread across different systems, the organization could usually trace an account back to a human lifecycle.

That assumption no longer describes the identity estate.

• Cloud automation created identities that never appeared in HR.
• SaaS applications normalized OAuth connections and delegated access.
• DevOps environments filled with service accounts, workloads, bots, API clients, keys, and tokens.
• AI agents are now accelerating all of this. Unlike earlier automation, they don't just authenticate and wait for a person to direct every action. They select tools, call APIs, retrieve information, move data, and act across connected systems on their own.

As a result, the enterprise identity estate is no longer made up only of people using software. It now includes software acting on behalf of people, teams, applications, and business processes. This points to a larger change. The next identity program cannot govern only users; it has to govern every actor.

The scale of the shift

One 2026 industry briefing estimates that machine identities now outnumber human identities by 109 to 1, up from 82 to 1 a year earlier. Most identity growth is now happening outside the human workforce, and governance hasn't kept pace.

A 2026 Cloud Security Alliance and Oasis Security survey found that most organizations did not have formally adopted policies for creating or removing AI identities, and that only a small fraction were highly confident their legacy IAM systems could manage the risks associated with AI and non-human identities.

The market is beginning to respond. Identity platforms are increasingly treating AI agents as distinct identity types rather than as extensions of a human account. Microsoft, for example, now documents dedicated agent identities with human sponsors responsible for their access and lifecycle.

The identity estate changed faster than its operating model

A user is usually a person, but an actor is anything capable of authenticating, accessing a resource, or taking an action: an employee, a service account, an OAuth application, a workload, an integration, a bot, or an AI agent. Non-human identities aren't new; organizations have relied on service accounts and application identities for decades. What's changed is their scale, variety, and reach.

A single business process may now depend on several connected non-human identities. One may retrieve information from an application, another may transform it, a third may move it into a different system, and an AI agent may then use that information to choose and perform its next action. Each of these identities can carry access, but unlike an employee, it may have no manager, department, job title, or formal lifecycle:

• A service account doesn't resign.
• An OAuth application doesn't appear in an org chart.
• A workload doesn't trigger an offboarding workflow when the engineer who created it changes teams.
• An AI agent doesn't automatically tell the IAM team that its original project has ended.

This is how ownership disappears, and it's not always because teams are careless. It happens because most identity processes were never built to expect a handoff for a software actor. The identity is created when a team needs it, the project moves forward, the creator changes roles, and the application owner changes, until the original purpose becomes harder to reconstruct. The identity remains, all the same, and the access may well remain with it.

The real problem is not only identity volume

The number of non-human identities matters, but volume isn't the main governance problem. 

The deeper problem is that many organizations can't confidently answer basic questions about them: what the identity is, why it was created, what it can access, whether it's privileged, whether it's still needed, and who is responsible for it now.

Without those answers, an identity becomes difficult to assess. It may appear active with no record of which workflow depends on it, carry broad access that no one currently feels responsible for reviewing, or sit inside a critical application whose original creator left the company months ago.

A DevOps engineer spins up a service account with admin-level access to unblock a deployment pipeline during an incident, intending to scope it down later. The incident and ticket close, and the service account keeps its admin scope because scoping it down was never anyone's follow-up task. Two years and one acquisition later, it's still running with the same permissions, and the engineer who created it left the company a year ago.

An ownerless identity is not only a missing field in a database. It is an unresolved security decision.

The result is an accountability gap: software can hold access and take actions while no person or team is clearly responsible for deciding whether that access remains appropriate.

A credential is not always the identity

The terms used around non-human identities can create further confusion. API keys, tokens, passwords, and certificates are generally credentials, while applications, service accounts, bots, workloads, integrations, and AI agents use those credentials to authenticate. The identity and the credential are related, but they aren't the same thing, and the distinction matters because credential security and identity governance answer different questions.

Credential security asks where a secret is stored, how it's protected, when it was last rotated, and whether it can be revoked. Identity governance asks which actor uses the credential, what purpose that actor serves, what it can access, whether that access is privileged, who owns it, and whether it should still exist.

Both sets of controls matter. Protecting a key doesn't establish ownership for the service account using it, just as assigning an owner doesn't remove the need to protect and rotate the credential. A complete approach has to understand the actor as well as the means it uses to authenticate.

Microsoft describes non-human identities as software-based agents (programs, bots, AI agents, and digital tools that access systems automatically) and notes that these identities can remain active too long, accumulate excess access, and go unnoticed by traditional identity governance.

Every actor needs a record, context, and an owner

Identity governance doesn't need to apply human workflows unchanged to every non-human identity, but it does need to preserve the principles that made human identity governance work in the first place.

A record. The organization first needs to know that the identity exists. The record should show where it was discovered, its classification, the application it belongs to, and whether it remains active. This can't depend on a one-time spreadsheet, because non-human identities keep appearing as teams deploy applications, integrations, automation, and AI workflows, so the inventory needs to change as the environment evolves.

Context. An identity name rarely provides enough information to make a decision on its own. Teams need to understand the access relationships around the identity: whether it's privileged, which resources it can access, who or what created it, which applications or processes depend on it, and whether it already has an assigned owner. Context is what turns an identity record into something teams can actually investigate and prioritize.

An owner. Every non-human identity needs a person or team responsible for decisions about its purpose and continued access. The owner doesn't necessarily use the identity. The owner is accountable for confirming why it exists, whether it's still required, and who should review it when the environment changes. Without an owner, a risky identity can remain active simply because no one has the authority or context to make a decision about it.

Visibility shows that the identity exists, context explains why it matters, and ownership makes someone accountable for it.

Introducing Identity Visibility for Non-Human Identities

Zluri already applies this record, context, and ownership model through its Identity Visibility & Intelligence Platform, and that model now extends to non-human identities. Identity Visibility for Non-Human Identities helps security, IAM, and IT teams discover NHIs across supported connected applications, understand their access and potential risk, identify privileged and ownerless identities, and establish clear ownership. The capability is powered by IRIS, Zluri's identity intelligence layer, and human and non-human identities appear together in the same platform, giving teams a connected view of identities, applications, access, ownership, and risk context.

There is no additional agent to deploy. Instead of creating another identity silo, the platform brings non-human identities into the same view teams already use to understand the wider identity estate.

Build a living record of the NHI estate

Most organizations don't have one system where teams can see the non-human identities discovered across their applications. Individual applications may show local accounts, service users, integrations, OAuth applications, or other identity records, but each system tends to represent them differently: one application may call something a service account, another may describe a similar identity as an integration user, and a third may treat it as a bot, application identity, machine user, or API client. This makes manual inventories difficult to build and even harder to maintain.

The platform brings NHI records from supported connected applications into a single live inventory. Teams can:

• View non-human identities at the application level
• See human and non-human identities on the same platform
• Automatically classify NHI records
• Apply custom taxonomy based on the organization's environment
• Correct classifications when records are inaccurate
• Keep the inventory current as connected data changes

A custom taxonomy helps teams organize identities using terms that reflect how the organization actually operates. One organization may distinguish between service accounts, integration identities, workloads, bots, and AI agents; another may need categories based on business function, environment, application criticality, or ownership model. The goal isn't to force every identity into a generic label. It's to create an inventory that security, IAM, IT, and application teams can understand and use.

Prioritize by reach, privilege, and ownership

An inventory answers the question of what exists, but it doesn't automatically answer where the team should start. Treating every non-human identity as equally risky creates noise: an identity supporting a limited internal process may not need the same attention as an ownerless identity with privileged access across important systems.

The platform brings together context such as:

• Individual blast radius
• Privileged identity flags
• Ownerless identity flags
• Creator details
• Application context
• Identity classification
• Custom fields and business context

The individual blast-radius view helps teams understand the access and connected resources an identity could affect, based on the relationships visible through connected systems. Privilege flags surface identities with elevated access, ownerless flags show where accountability is missing, and creator details provide a starting point when the current owner is unclear. A posture dashboard brings these signals together so teams can identify patterns and focus on the identities that may create the greatest exposure.

Instead of starting with the oldest record or the application that generated the most alerts, teams can prioritize based on reach, privilege, ownership, and context.

Turn visibility into accountability

Finding an ownerless identity doesn't resolve the issue; assigning an owner begins to. The platform allows teams to add or remove owners for non-human identities directly within the platform, and the assigned owner can help confirm:

• Why the identity was created
• Which application or workflow depends on it
• Whether the identity still serves an active purpose
• Whether its access remains appropriate
• Which team should review it in the future

This creates a clear point of accountability and reduces the chance that an identity will remain active simply because nobody feels responsible for deciding whether it should stay.

Teams can also improve the quality of the inventory by correcting misclassifications, merging duplicate records, and archiving records that have already been reviewed. These may look like data-management actions, but they have a direct effect on governance: a duplicate record can divide ownership and context across two entries, a misclassified identity can be excluded from the right review process, and an unmaintained inventory can make teams spend time investigating records that have already been addressed. Reliable governance, in the end, depends on reliable identity data.

Human and non-human identities belong in the same view

Non-human identities don't operate in a separate business environment. They access the same applications, infrastructure, and information as human identities, and a human identity often sits somewhere in the surrounding context:

• A person may have created the service account.
• An engineer may have configured the bot.
• An employee may have approved the OAuth connection.
• An application owner may understand the workflow the identity supports.
• A team leader may now be responsible for the process even if the original creator has left.

These relationships can help teams reconstruct purpose and establish ownership. That's why human and non-human identities shouldn't be kept in separate, disconnected inventories. The platform brings them together, powered by IRIS, so teams can examine the NHI record, its application, creator information, ownership status, access relationships, privilege, and potential blast radius without building a separate data pipeline or moving between several spreadsheets. The goal, after all, is not only to find an identity, but to understand it well enough to make a decision about it.

Built for the teams that share identity risk

Non-human identity risk rarely belongs to one department:

• Security teams need to identify privileged, ownerless, and broadly connected identities that may increase exposure.
• IAM teams need a consistent inventory and ownership model that extends beyond employees.
• IT teams need to understand the accounts, applications, and integrations operating across the systems they manage.
• Application owners need to confirm why an identity exists and whether it still supports an active process.
• Engineering teams may hold the original context behind the service accounts, bots, workloads, and automated workflows in question.

Without a shared view, each team ends up holding only part of the answer: one may see the risk, another may understand the application, another may remember the original purpose, but no single team may have enough context to see the full picture alone. The platform closes that gap with a common inventory and a consistent set of identity signals, so instead of passing spreadsheets between departments, they can work from the same identity records, classifications, ownership information, and risk context.

The next identity program governs every actor

Identity governance was built around the human lifecycle because it provided a dependable source of context. The employee record was never the final goal; accountability was. Organizations needed to know who had access, why they had it, who approved it, and when it should change.

The same principle now needs to extend to non-human identities. None of them carry a manager, a job title, or a resignation letter, and an AI agent can act on its own without asking permission first. But every one of them still needs an owner, still needs context for the access it holds, and still needs someone accountable for what it does with that access.

The identity estate has moved beyond people, and identity governance now has to move with it: from governing only users to governing every actor, from disconnected records to a living identity view, from unknown access to usable context, from ownerless to accountable, and from invisible to owned.

Identity Visibility for Non-Human Identities is live today. See it in action

Frequently asked questions

What is a non-human identity?

A non-human identity is a digital identity used by software to access systems, information, or other resources without a person signing in directly. Examples include service accounts, OAuth applications, managed identities, service principals, bots, workloads, integrations, and AI agents.

Is an API key a non-human identity?

An API key is generally a credential used by an application, service, or other non-human identity to authenticate. The identity and the API key are related, but they aren't always the same object.

Why are non-human identities difficult to govern?

Most identity governance processes depend on human lifecycle signals such as an HR record, manager, department, role change, or departure. Non-human identities often lack these signals, so their original purpose and ownership can become unclear over time.

What can teams see with Identity Visibility for Non-Human Identities?

Teams can build a live NHI inventory across supported connected applications, classify identities, identify privileged and ownerless records, inspect creator and application context, and understand individual blast radius.

What does blast radius mean for a non-human identity?

Blast radius describes the access and connected resources that could potentially be affected if an identity were compromised or misused. In the platform, this is based on the identity and access relationships visible through connected systems.

Can teams assign owners to non-human identities?

Yes. Teams can add or remove owners, correct classifications, merge duplicate records, and archive records that have already been reviewed.

Does Identity Visibility for Non-Human Identities require another agent?

No. The capability works within Zluri's existing platform and doesn't require an additional agent.

Who should use Identity Visibility for Non-Human Identities?

The capability is designed for security, IAM, IT, engineering, and application teams that need to understand non-human identities, prioritize risk, and establish clear ownership.

‍