The Non-Human Identity Guide for IT and Security Leaders

You run access reviews for every employee. Each quarter, you pull reports, follow up with managers, and certify who still needs access. Meanwhile, a service account with standing administrative rights to your production database may never have appeared in a review campaign. It has no manager, has never gone through onboarding, and will never trigger an employee offboarding event.

That service account is one example of a non-human identity, and your environment likely contains thousands of identities like it. In many organizations, non-human identities already outnumber employees by a wide margin. Because these identities often operate continuously and outside standard employee lifecycle processes, they can accumulate access and remain active without the same oversight applied to human users.

You have automated the software that runs your company. The identities running that software are often the last population you still govern manually. This article explains what non-human identities are, why they slip past the controls you built for employees, and how to bring them into one governance program instead of a second silo.

What is a Non-Human Identity?

A non-human identity (NHI) is an identity used by software, workloads, devices, or automation to authenticate or receive authorization without a person signing in interactively. That category is broader than many identity teams initially expect.

The Identities Behind Every Automation

Non-human identities include service accounts, service principals, managed identities, OAuth applications, CI/CD runners, RPA bots, workload identities, and AI agents that authenticate to organizational resources.

API keys, tokens, certificates, and secrets are related but distinct. They are credentials that an NHI may use to authenticate. In IAM terms, the NHI is the principal, while the key, token, certificate, or secret is the authenticator associated with that principal.

The population grows each time someone connects a SaaS application, configures an integration, deploys a workload, or creates an automated process. An AI agent also becomes an NHI when it authenticates with its own credentials or receives delegated access to organizational resources.

The contrast with a human identity matters. A person typically has a manager, an HR record, an interactive authentication flow, and a defined offboarding event. A non-human identity may have equivalent access without any of those lifecycle controls. Some workloads use managed identities or short-lived federated credentials, but many environments still depend heavily on static secrets and manually managed service accounts.

Non-Human Identity Versus Machine Identity

The terms machine identity and non-human identity overlap, but vendors and security frameworks do not always use them consistently.

In this article, machine identity refers primarily to certificate-based and workload-based identities that allow systems and services to authenticate to one another. Non-human identity is the broader category, encompassing service accounts, application principals, OAuth applications, bots, automation, workload identities, and AI agents.

The distinction matters because teams cannot govern a category they have not clearly defined. A certificate used for mutual TLS, an overprivileged OAuth application, and a service principal authenticated by a hardcoded key may create different technical risks, but all belong in the organization’s non-human identity governance program.

Non-Human Identities Already Outnumber the People You Manage

You may manage a few thousand employees while maintaining tens of thousands of identities that have never been counted in one place. Most of those identities are not human.

The Numbers Nobody Wants to Total Up

Machine and workload identities already outnumber human identities in many environments, and the gap continues to widen as organizations add cloud services, SaaS integrations, automated pipelines, and AI agents.

The identities nobody has counted are the ones most likely to hurt you. A service account or workload credential that never made it into an inventory still authenticates, still holds whatever access it was granted, and still operates outside every monitoring and lifecycle control you built for known users. Attackers gravitate to exactly these identities, because an account the security team does not know exists is an account no one is watching.

The exact multiple is less important than the underlying operational problem: most organizations cannot produce a complete count.

Teams commonly undercount NHIs because of non-human identity sprawl. Service accounts, application principals, workload identities, and their credentials are distributed across identity providers, cloud accounts, SaaS applications, code repositories, secrets stores, and local systems that may never connect to the corporate directory.

No single administrative console contains the full population. As a result, identity teams rely on estimates, and those estimates frequently exclude the identities that nobody intentionally chose to track.

What Shows Up the Day You Build One Inventory

The scale becomes visible only when human and non-human identities appear in the same access graph. Across the environments Lumos connects to, the non-human share of access is often higher than identity and security teams expect.

A unified inventory allows teams to answer three basic questions:

• Who owns this identity?
• When did it last authenticate or perform an action?
• Which systems, data, and entitlements can it access?

When ChargePoint connected Lumos to more than 100 applications in under three months, previously unused and orphaned accounts became visible. That result illustrates the discovery problem clearly: an organization cannot govern an identity population it has never fully seen.

Discovery is not merely an inventory exercise. It establishes the data foundation required for ownership attribution, risk scoring, access reviews, credential remediation, and eventual decommissioning.

None of the Controls You Trust Were Ever Wired to Them

The central problem is not that these identities are used by machines. The problem is that many identity controls were designed around HR records, managers, employees, and predictable lifecycle events. Non-human identities frequently exist outside that operating model.

When a person joins a company, HR creates a record, IT provisions access, a manager becomes accountable for the relationship, and offboarding begins when the person leaves. When an engineer creates a service account to unblock a deployment, none of those events necessarily occurs. The account may have no ticket, assigned owner, documented purpose, review date, or expiration condition.

No MFA and No Reliable Rotation

A non-human identity may authenticate with a secret, key, token, or certificate. If an attacker obtains a valid credential, the attacker may be able to authenticate as that identity without encountering an interactive MFA challenge.

The problem becomes more serious when the credential is long-lived. Human identities generally have lifecycle triggers, interactive authentication controls, and established credential-reset processes. Many non-human identities still rely on static secrets that remain valid for months or years.

Modern workload federation and managed identity services can reduce this risk by replacing static secrets with short-lived credentials. Where static credentials remain necessary, teams need a reliable process for discovering, rotating, revoking, and replacing every copy.

Rotation limits how long a compromised credential remains useful. However, rotation works only when the identity team knows where the credential exists, what depends on it, and whether replacing it will interrupt production.

No Owner and No Leaver Event

Ask who depends on a particular service account, and the answer is often unclear. When nobody can explain what will break if the account is revoked, teams usually leave it active. The identity then remains in place with its existing permissions, even after its original purpose has ended.

A durable non-human identity security strategy starts with ownership. Teams cannot right-size, review, rotate, or retire an identity until a person or service team is accountable for it.

The account may outlive the project, application, and employee who created it. Over time, orphaned identities accumulate, each retaining credentials or entitlements without a responsible owner.

This is rarely a local failure. Most identity programs run a defined joiner-mover-leaver process for employees but have no equivalent trigger for the credentials machines use, so non-human identities get created constantly and almost never formally offboarded. The same programs tend to watch human activity closely while leaving service-account and workload activity largely unmonitored, which is how these ownership and monitoring gaps persist across the environment.

These gaps can become documented audit findings. When an assessor asks who owns a privileged service account and the organization cannot provide an answer, the issue is no longer theoretical. It becomes a control weakness assigned to a team for remediation.

When Nubank brought its identities into one inventory through Lumos, the company found hundreds of incompletely offboarded users that had previously remained invisible and recovered $2.7 million in software spend. Although the example spans the broader identity population, the lesson applies equally to NHIs: lifecycle gaps remain hidden when identity records, access data, and ownership information are fragmented.

Where Non-Human Identity Risk Gets Exploited

Two conditions amplify NHI threats across most environments: exposed credentials and standing privileges that the associated workload does not use.

Secrets That Leak Faster Than You Can Rotate Them

Static secrets can be hardcoded into source code, printed in logs, added to configuration files, pasted into collaboration platforms, or committed to public and private repositories. The same credential may then be copied into multiple vaults and environments until nobody can identify every instance that must be replaced.

Hardcoded secrets leak constantly, and the ones that leak tend to stay valid. A key committed to a repository or written into a config file often keeps working for months or years, because nothing revokes it and nobody knows it's there to revoke. A large and growing volume of exposed credentials that remain usable long after they leak is what makes secrets sprawl so hard to contain.

A secrets vault addresses only one part of the problem. Teams must also discover credentials embedded in code, build systems, configuration files, ticketing platforms, and collaboration tools.

An attacker who obtains a valid credential may inherit the identity’s effective access. The resulting blast radius depends on the permissions attached to that identity, the systems it can reach, and the organization’s ability to detect and revoke the credential quickly.

Standing Privilege Nobody Uses

Non-human identities are often created from existing templates or copied from previously configured accounts. That process can grant permissions the identity never needs.

In many environments, observed access shows that workloads use only a portion of their assigned entitlements. The unused remainder creates an attack surface without providing operational value. If an attacker compromises the identity, those dormant permissions become immediately available.

Non-human identity breach prevention starts before a credential is compromised. Teams should compare granted access with observed use, remove dormant entitlements, and replace unnecessary standing privilege with time-bound, just-in-time access.

Every entitlement removed reduces the potential blast radius of a future compromise.

Using Lumos, Code42 reduced access-request resolution time from 18 hours to four minutes and reduced long-standing privileged access by 67%. That type of right-sizing is not a one-time cleanup project. It is a continuous discipline that keeps access aligned with actual operational requirements.

AI Agents Become Non-Human Identities When They Authenticate

An AI agent becomes an identity-governance concern when it authenticates with its own credentials, assumes a role, receives delegated authorization, or takes actions against organizational resources.

Unlike a traditional service account with a narrow and predictable function, an agent may require different permissions as its assigned tasks change.

Why Static Assumptions Break

Consider an agent that needs read access to one data store for a task on Monday and write access to a different system on Wednesday. A permanent set of permissions may either prevent the agent from completing legitimate tasks or grant it access it does not continuously need.

Static provisioning therefore creates the same overprivilege problem identity teams already face with service accounts, but the access requirements can change more frequently.

Most identity programs have no policy for how an AI agent's identity gets created in the first place, and the controls they already run were not designed to govern an actor whose access needs shift from one task to the next. Traditional provisioning assumes a fixed function and a stable set of entitlements. An agent breaks both assumptions, which is why teams relying on static tooling tend to fall behind the moment agents start operating at any scale.

The objective is not to give every agent broad standing access. It is to evaluate the task, identity, target resource, requested action, and relevant policy before granting the minimum access required.

Governing an Actor That Decides for Itself

AI agents should not sit in a separate inventory or operate outside established identity controls. When an agent authenticates or receives delegated access, the organization should place it in the same access graph as employees, contractors, service accounts, and workload identities.

Lumos brings human, non-human, and AI-agent identities into a unified access model. Albus, the Lumos AI agent, can draft and maintain least-privilege policies as applications, identities, and access relationships change. Agentic access reviews can then include human and non-human identities in the same campaign while drafting explainable decisions for a reviewer to approve or override.

Autonomy does not eliminate accountability. Every AI agent still needs an owner, a documented purpose, defined authorization boundaries, observable activity, and a process for revoking access when the agent is retired or its responsibilities change.

The relevant distinction is whether governance can adapt as quickly as the environment. A tool that merely recommends a change may still leave teams with a growing manual queue. Autonomous identity governance can continuously evaluate changes while preserving human oversight for high-impact decisions.

Why Non-Human Identities Belong in One Program, Not a Second Silo

When evaluating non-human identity management solutions, prioritize platforms that reconcile human and non-human identities in one inventory, policy model, and review process rather than creating a separate governance silo.

The Instinct That Recreates the Sprawl

It is understandable to treat NHIs as an entirely separate security problem. They differ from human identities, are growing quickly, and often require specialized discovery and credential controls.

However, creating an isolated NHI program can produce a second inventory that never reconciles with the human identity system, a separate review cycle, and another administrative console the security team must maintain.

That approach can recreate the same fragmentation that made access difficult to govern in the first place. Each point product may address a valid technical problem, but every additional identity repository increases the amount of data the organization must reconcile before it can answer who or what has access.

Specialized controls may still be necessary for secrets, certificates, workload federation, or cloud permissions. The governance layer, however, should connect those controls to a unified identity record, accountable owner, access graph, policy model, and lifecycle.

One Inventory, One Review Engine

A non-human identity is still an identity. It is created, granted access, reviewed, modified, and revoked when its purpose ends. The actor differs from a person, but the governance obligations remain.

A scalable model governs human and non-human identities in one inventory, applies least-privilege policies across both populations, and brings them into the same review engine. An auditor should receive one answer to who and what has access rather than separate reports that teams attempt to reconcile at the end of the quarter.

Lumos is built around that model. It brings human, non-human, and AI-agent identities into one access graph. Its delta access reviews include each identity type in a single campaign while directing reviewers to the access that has changed since the previous review.

This approach makes reviews more manageable at scale. When Pluralsight adopted it, quarterly reviews expanded from 20 applications over two months to 200 applications in less than two weeks. Reviewers could focus on the access relationships that had changed instead of repeatedly recertifying unchanged access.

Our guide to non-human identity management explains the operating model in more detail, including the six-stage identity lifecycle and a risk-scoring framework for prioritizing remediation.

What Changes When Governance Runs Continuously

You have already automated deployments, infrastructure, and the pipelines that deliver software throughout the day. Identity governance should operate with a similar level of consistency.

Automation does not mean removing oversight. It means continuously discovering identities, assigning owners, evaluating access, identifying material changes, and routing the highest-risk decisions to the appropriate reviewer.

Roku reduced onboarding time by 98% and moved lifecycle policy management from a team of people to a single person. The improvement came from applying automation and consistent policy across the identity lifecycle rather than relying on a quarterly manual process.

The same model can extend to non-human identities. A mature program continuously discovers new identities, attributes ownership, monitors credential and entitlement risk, triggers reviews when access changes, and revokes access when an identity no longer has a valid purpose.

Non-human identities have operated automatically for years. Identity governance must now become continuous enough to keep pace with them.

See what autonomous identity governance looks like across your applications and identities—human, non-human, and AI-driven—in a Lumos demo.