Non-Human Identity

The Larger Half

Enterprise security has spent two decades hardening human identity.
Multi-factor authentication, single sign-on, privileged access
management, conditional access policies, user behavior analytics,
the whole apparatus of making sure the person logging in is who
they claim to be. The investment was substantial and largely
correct.

It also addressed the smaller half of the problem. In a modern
enterprise, the entities that authenticate to systems are
overwhelmingly not human. They are service accounts, API keys,
OAuth tokens, machine certificates, CI/CD credentials, and
increasingly the credentials wielded by AI agents. These are
collectively called non-human identities, NHIs, and they outnumber
human identities by ratios that the published research puts
between 40:1 and 100:1, reaching 144:1 in cloud-native and DevOps
environments. One audit at a large bank expected fifty thousand
human accounts and found over four million non-human ones.

The asymmetry is the story. The half of the identity problem that
gets all the security attention is the smaller half. The larger
half, the non-human half, has been managed for most of its
existence with spreadsheets, manual rotation schedules that
rarely run, and shared keys that never expire. The bill for that
neglect has started arriving, and this post is about why it
should be paid deliberately rather than after the breach.

What Makes Non-Human Identity Different

The reason human identity tooling does not transfer cleanly to
non-human identity is that NHIs violate every assumption the
human tooling makes.

Human identity tooling assumes a human at the other end. MFA
assumes someone who can approve a push notification. A service
account cannot approve a push notification. It authenticates with
a static credential, 24/7, with no second factor possible. The
entire MFA apparatus, which is the centerpiece of human identity
security, simply does not apply.

Human identity tooling assumes normal behavior patterns. User
behavior analytics flags the login from a new country, the access
at an unusual hour, the bulk download that does not fit the
user's history. A service account has no normal in that sense. It
runs continuously, accesses in bulk by design, and operates at
hours no human keeps. The behavioral baseline that flags human
anomalies produces noise for machines.

Human identity tooling assumes a lifecycle tied to employment.
When a person leaves, HR triggers deprovisioning, access is
revoked, the account is disabled. A non-human identity has no HR
record. The engineer who created the service account leaves, and
the account persists indefinitely, buried in a config file or a
hardcoded environment variable, with its full original
privileges. The published research found that 47% of NHIs are
more than a year old with no credential rotation, and 8% have no
owner in any HR system at all. These are the zombie identities,
and they are the primary vector for lateral movement in modern
breaches.

The AI agent makes all of this worse. A traditional application
follows a hardcoded path. You grant it a static key and you know
what it will do with it. An AI agent decides at runtime which
tools to call, which data to pull, which APIs to trigger. It
spawns subprocesses. It chains tools. It mints new credentials.
The static API key that was adequate for a predictable
application is, in the words of one analysis, a death sentence
when handed to an autonomous agent that decides for itself how to
use it.

The Breaches Are Already Here

This is not a theoretical risk. The pattern of NHI exploitation
has produced some of the largest breaches of the last two years,
and the structure of those breaches is consistent.

The Salesloft-Drift breach of 2025 began with a compromised
third-party application and exploited OAuth tokens to reach
hundreds of downstream environments. The blast radius was
measured at roughly ten times that of a comparable direct
attack, because the compromised tokens rode trusted connections
across a SaaS supply chain. Over seven hundred companies were
affected through a single integration's credentials.

The Moltbook breach of February 2026 followed the same shape on
an AI agent platform. Attackers compromised a third-party
integration, then pivoted to client environments across the
entire platform through the trusted NHIs that integration held.
The lateral movement was not through stolen passwords. It was
through machine identities that were trusted by design and
governed by nobody in particular.

The surveys behind these incidents are blunt. Roughly two-thirds
of enterprises report having suffered a breach via a compromised
NHI. A significant fraction, around a third in one survey, could
not even tell whether they had or not, because the monitoring
that would detect NHI compromise was not in place. The
combination of "it happened to most of us" and "many of us cannot
tell if it happened to us" is the signature of an unmanaged
attack surface.

What Managing It Right Looks Like

The governance model that the serious analyses converge on has
three pillars. They are not novel. They are the same principles
that human identity security worked out, applied to the larger
half.

The first pillar is discovery. You cannot secure what you
cannot see, and most organizations cannot see their NHIs. The
research repeatedly finds that around 70% of machine identities
are either undocumented or unused while still holding live
privileges. The first work is inventory: continuous, automated
scanning across every cloud, every SaaS integration, every CI/CD
system, every repository, to find every credential, token, and
service account that exists. The spreadsheet approach fails here
because the spreadsheet is stale the moment it is written. The
inventory has to be continuous because the population changes
continuously.

The second pillar is ownership and governance. Every
non-human identity needs a human custodian, a real person who is
accountable for that identity's lifecycle. The identity needs a
declared intent: what is this credential allowed to do, and which
systems should it never touch. A logging service's credential
should not be able to reach the payroll database, and the
governance layer is where that constraint is declared and
enforced. The ownerless zombie identity is the failure of this
pillar, and assigning every identity to a custodian is the fix.

The third pillar is ephemeral credentials and enforcement.
The static secret that lives forever is the relic that has to
die. The 2026 standard is short-lived, context-aware tokens tied
to a specific authorized task and set to expire the moment that
task finishes. The frameworks for this exist and are maturing:
SPIFFE for workload identity, OIDC for federated token issuance,
the various cloud-native workload-identity systems that replace
static keys with cryptographically attested short-lived
credentials. The principle is that identity should be proved by
cryptographic attestation of origin at the moment of use, not by
possession of a static key that was issued once and never
reconsidered.

The synthesis of the three pillars is a model where every machine
identity is discovered automatically, owned by an accountable
human, scoped to a declared intent, issued as a short-lived
credential, and revocable instantly if something looks wrong. The
contrast with the spreadsheet-and-static-key status quo is the
difference between governing the larger half of the identity
problem and pretending it does not exist.

The Honest Difficulty

None of this is easy, and the analyses that pretend it is a
matter of buying one tool are selling something. The genuine
difficulties are worth naming.

The discovery problem is harder than it sounds because the
identities are spread across clouds, SaaS platforms, on-premise
systems, and third-party integrations, each with its own
inventory and no unified view. Stitching these into a single
picture is real integration work.

The ephemeral-credential transition requires application changes.
An application that expects a static API key in an environment
variable has to be modified to fetch and refresh short-lived
tokens. For a large estate of legacy applications, this is a
multi-year program, not a configuration change.

The AI agent case is genuinely unsolved at the frontier. An agent
that mints credentials at runtime, chains tools autonomously, and
operates with limited human oversight is a governance challenge
that the industry is still working out. The human-in-the-loop
requirement that many organizations have mandated is a stopgap,
not a solution. The right architecture, where the agent proves
its identity cryptographically and operates under
zero-standing-privilege with just-in-time authorization, is still
being built.

The compliance pressure is, however, removing the option of
ignoring the problem. SOC 2, ISO 27001, PCI DSS, and NIST 800-53
all carry access governance requirements that apply to non-human
identities as much as human ones, and auditors are increasingly
asking the specific questions that the "we use a vault" answer no
longer satisfies.

Closing

The structural observation is simple. The industry built a
sophisticated apparatus for securing the identities of humans,
who are the smaller and slower-growing half of the population of
things that authenticate to systems. The larger and faster-growing
half, the non-human identities, got spreadsheets and static keys.
The asymmetry was tolerable when machine identities were a small
multiple of human ones and behaved predictably. It is not
tolerable at 50:1 and rising, with AI agents minting credentials
autonomously and the breaches already arriving.

The work to manage non-human identity right is the same work that
was done for human identity, applied to the larger half:
discovery so you can see what exists, ownership so someone is
accountable, least privilege so the blast radius is bounded, and
ephemeral credentials so a stolen token is worthless within
minutes. None of it is conceptually new. All of it has been
neglected because the tooling was built for the smaller half and
nobody extended it to the larger one.

For anyone running infrastructure in 2026, the question to ask is
the same one the bank asked before it found four million machine
identities where it expected fifty thousand human ones: how many
non-human identities do I actually have, who owns each one, what
can each one reach, and how would I know if one were compromised.
The answers are usually uncomfortable. The discomfort is the
point. The larger half of the identity problem has been waiting
to be managed for a long time, and the breaches of the last year
are the reminder that the wait has a cost.