Part 3 — When Non-Human Identities Outnumber Humans
CSA Top Threats 2026 — Part 3 of 8
What happens when service principals, workloads, automation and AI agents become the dominant identity population.
By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.
For decades, enterprise identity management was built around a simple assumption.
An identity represents a person.
There is an employee.
The employee joins the organization.
An account is created.
The employee receives a role.
Permissions follow.
The employee changes jobs.
Permissions change.
Eventually, the employee leaves.
The account is disabled.
Around this lifecycle, we built an entire security discipline.
Identity governance.
Access reviews.
Privileged access management.
Segregation of duties.
Joiner-Mover-Leaver processes.
Multi-factor authentication.
Password policies.
Conditional access.
Recertification.
It is a mature model.
There is only one problem.
Humans are increasingly no longer the dominant identity population.
The Cloud Security Alliance’s Top Threats to Cloud Computing 2026 explicitly highlights the rise of non-human identities as part of the identity management challenge.
That observation deserves more attention than it usually receives.
Because when machines become the majority of identities, IAM is no longer simply a workforce security discipline.
It becomes something much larger.
It becomes the governance system for software actors.
And AI agents are about to make that problem considerably more difficult.
We Built IAM for People
Most enterprise identity governance still carries the organizational structure of the workforce inside it.
Consider how much context exists behind a human account.
Name.
Manager.
Department.
Job title.
Location.
Employment status.
Cost center.
Start date.
Contract type.
Role.
End date.
These attributes allow organizations to make access decisions.
They also create accountability.
If an employee has excessive permissions, there is someone to ask.
If a role changes, there is an organizational event.
If employment ends, there is a trigger for deprovisioning.
The identity exists because the person exists.
Now consider a service principal.
What is its department?
Who is its manager?
What is its employment status?
When is its last working day?
What business role does it perform?
When should its access be recertified?
Who knows whether it is still needed?
Suddenly, the assumptions behind decades of identity governance begin to disappear.
The Machine Identity Population Is Different
The term Non-Human Identity, or NHI, covers a wide and increasingly diverse population.
Service accounts.
Service principals.
Workload identities.
Managed identities.
API keys.
Application identities.
Certificates.
Automation accounts.
CI/CD identities.
Robotic process automation.
Containers.
Serverless workloads.
Integration identities.
Bots.
And increasingly:
AI agents.
These identities do not merely differ technically from human accounts.
They differ structurally.
A human identity usually corresponds to one person.
A workload identity may represent a process.
A service principal may represent an application.
An API credential may represent an integration.
An automation identity may represent a workflow.
An AI agent may represent something considerably harder to define.
It may represent:
a task,
a business function,
a user delegation,
a temporary objective,
a persistent digital worker,
or another agent.
This matters because governance depends on knowing what an identity represents.
If we cannot answer that, we cannot meaningfully determine what authority it should have.
Creation Is Easy. Accountability Is Hard.
One reason non-human identities proliferate so quickly is that they are easy to create.
A developer creates a service principal.
A cloud deployment creates a managed identity.
A SaaS integration generates an API token.
A pipeline receives credentials.
An automation platform creates a connector.
An AI prototype receives access to an enterprise API.
A new agent receives OAuth permissions.
Technically, everything works.
The project moves forward.
Months later, somebody asks:
Who owns this identity?
Silence.
The developer has moved teams.
The external consultant has left.
The project ended.
The application changed.
The business owner never knew the identity existed.
Nobody wants to disable it because nobody knows what might break.
This is how organizations accumulate something more dangerous than technical debt.
They accumulate authority debt.
Permissions survive longer than the organizational reason that justified them.
Credentials remain valid.
Trust relationships remain active.
Tokens remain usable.
Applications remain registered.
And identities continue to exist because removing them feels riskier than leaving them alone.
An Orphaned Identity Is Orphaned Authority
This distinction matters.
We often describe unused accounts as hygiene problems.
But a non-human identity is not merely an object in a directory.
It is a container for authority.
If the identity can:
read data,
invoke an API,
assume a role,
retrieve a secret,
trigger a workflow,
modify infrastructure,
or create another credential,
then the organization has delegated authority to it.
If nobody remains accountable for that identity, the problem is not simply an orphaned account.
It is:
orphaned authority.
And orphaned authority is fundamentally a governance failure.
Someone — or something — can still act.
But nobody can explain why that authority still exists.
Every Non-Human Identity Needs a Human Owner
This leads to what should become a basic governance principle for the agentic enterprise:
Every non-human identity must have an accountable human owner.
Not merely a technical owner.
Not merely the administrator of the platform.
Not merely the person whose name happens to appear in a configuration field.
An accountable owner must be able to explain why the identity exists and accept responsibility for the authority assigned to it.
That person should be able to answer:
What business purpose does this identity serve?
Which application, workload, automation or agent uses it?
Which systems can it access?
Which permissions does it possess?
Can it delegate authority?
Can it obtain additional credentials?
Which data can it reach?
What would happen if it were compromised?
What would happen if we disabled it today?
When should it expire?
And who approves changes to its authority?
If nobody can answer those questions, the organization may have an identity inventory.
But it does not have identity governance.
Ownership Must Follow Business Purpose
There is an important nuance here.
The human owner should not automatically be the technical team operating the identity.
Imagine an automated payment process.
IT may operate the platform.
A cloud team may manage the workload identity.
IAM may provision the permissions.
Security may define the control requirements.
But the authority ultimately exists because a business process needs to perform payments.
The business accountability therefore cannot disappear simply because execution has been automated.
This becomes even more important with AI agents.
If an agent can perform a business action, someone must remain accountable for that action.
Automation does not eliminate accountability.
It relocates execution without relocating responsibility.
That principle will become essential as organizations begin to deploy digital workers and autonomous agents at scale.
Machines Need Joiner-Mover-Leaver Too
One of the most successful ideas in human identity governance is lifecycle management.
Joiner.
Mover.
Leaver.
We need an equivalent model for machines.
Consider the lifecycle of a workload identity.
Joiner
Why is the identity being created?
Who requested it?
Who approved it?
What workload is bound to it?
What is its initial authority?
What is its expected lifetime?
Mover
The application changes.
The workload moves.
The agent receives another tool.
The API integration expands.
A new environment is added.
Permissions change.
Does the identity still represent the same purpose?
Does its risk classification change?
Does the owner need to approve the new authority?
Leaver
The application is retired.
The project closes.
The integration is replaced.
The automation is disabled.
The AI experiment ends.
What happens to the identity?
What happens to its tokens?
Its certificates?
Its delegated permissions?
Its API keys?
Its downstream trust relationships?
Its secrets?
Its access to data?
The lifecycle of the workload and the lifecycle of its authority must be connected.
Today, they often are not.
Expiration Should Become a Default
Human identities normally have a natural lifecycle.
Machine identities often do not.
That is backwards.
A service principal created for a six-month project should not quietly become permanent infrastructure.
An API credential created for testing should not survive for years.
An experimental AI agent should not retain production access because nobody remembered to revoke it.
For many non-human identities, permanence should therefore be the exception rather than the default.
Where technically possible, organizations should increasingly prefer:
short-lived credentials,
temporary authorization,
just-in-time access,
federated workload identities,
automatic rotation,
explicit expiration,
and automatic deprovisioning.
The security question should shift from:
Why should this identity expire?
to:
Why should this identity continue to exist?
That is a much healthier default.
Secrets Are Often a Symptom
Non-human identity discussions frequently become secret-management discussions.
Where are API keys stored?
How often are certificates rotated?
Are secrets stored in vaults?
Are credentials hard-coded?
These are important questions.
But they can distract from the larger governance problem.
A perfectly protected secret can still represent excessive authority.
A frequently rotated credential can still belong to an identity nobody owns.
A certificate can be cryptographically strong while authenticating a workload that should no longer exist.
Secret management protects the credential.
Identity governance governs the authority behind it.
We need both.
They are not interchangeable.
The Dangerous Question: What Breaks If We Disable It?
There is a simple diagnostic question I would ask in almost any NHI program:
What happens if we disable this identity?
If the answer is known, good.
If the answer is documented, better.
If the answer is tested, excellent.
But if the answer is:
“We don’t know, so don’t touch it,”
then the organization has discovered something important.
The identity is no longer under meaningful governance.
It has become a dependency nobody understands.
This is especially dangerous for privileged machine identities.
Organizations sometimes retain them not because somebody has positively determined that the access is necessary, but because nobody can prove that it is unnecessary.
That reverses the principle of least privilege.
Access becomes permanent by uncertainty.
Non-Human Does Not Mean Non-Privileged
There is also a tendency to think about privileged access primarily in human terms.
Administrators.
Root.
Domain Admins.
Global Administrators.
Database administrators.
But some of the most consequential identities in modern environments are machines.
A CI/CD pipeline may deploy hundreds of applications.
A backup service may access almost every critical system.
An automation platform may modify thousands of accounts.
An integration service may transfer sensitive information between security domains.
A cloud orchestration identity may create infrastructure and assign permissions.
The identity may never log into a management console.
It may never type a password.
It may never appear in a traditional privileged-user report.
Yet its effective authority may exceed that of most human administrators.
This is why PAM must increasingly become Privileged Identity Management, not merely privileged human account management.
Privilege Should Be Measured by Consequence
This also suggests a better way to classify non-human identities.
Do not ask only:
Does this identity have an administrator role?
Ask:
What is the maximum consequence this identity can produce?
Can it modify production?
Can it change security controls?
Can it access sensitive data?
Can it create credentials?
Can it delegate authority?
Can it disable logging?
Can it change backups?
Can it invoke financial transactions?
Can it communicate externally?
Can it trigger another privileged workload?
This gives us a much more realistic view of criticality.
Because in highly connected environments, privilege is not merely a role assignment.
Privilege is reachable consequence.
Then AI Agents Arrive
Everything described so far is difficult enough with conventional workloads.
AI agents make it more interesting.
A traditional workload identity usually represents deterministic software.
The software may be complex, but developers have defined what it does.
An AI agent is different.
It may interpret instructions.
Consume changing context.
Select tools.
Plan intermediate actions.
Respond differently to different information.
Interact with other agents.
And potentially pursue an objective over multiple steps.
Now attach an enterprise identity to it.
Give it OAuth tokens.
Connect it to APIs.
Give it access to an MCP server.
Allow it to read documents.
Let it create tickets.
Perhaps allow it to modify records.
At that moment, the identity no longer merely authenticates software.
It authenticates a software actor.
That is a significant change.
An Agent Identity Represents Delegated Agency
This is where terminology becomes important.
A service account represents access.
An agent identity increasingly represents delegated agency.
The organization is not merely saying:
“This software may read this database.”
It may be saying:
“This actor may pursue this objective using these resources.”
That creates a new governance question.
Who owns the objective?
Who defines the boundaries?
Who approves the tools?
Who determines what data may influence the agent?
Who monitors its actions?
Who can stop it?
Who reviews the consequences?
Who remains accountable when the agent chooses a path nobody explicitly programmed?
These questions do not fit neatly into traditional IAM.
But they absolutely belong in identity governance.
One Agent May Have More Than One Identity
There is another complication.
We often assume a clean mapping:
One person.
One identity.
Agentic systems may break that assumption.
An agent may operate:
on behalf of a user,
under its own workload identity,
through delegated OAuth permissions,
using a tool-specific token,
while calling another agent with a different identity.
Which identity performed the action?
The human?
The agent?
The workload?
The tool?
The downstream agent?
Potentially all of them are relevant.
That makes attribution considerably more difficult.
And attribution is not merely a forensic concern.
It is necessary for accountability.
If we cannot reconstruct the authority chain behind an action, we cannot reliably answer:
Who authorized what?
We Need Authority Provenance
Data governance has long discussed provenance.
Where did the data come from?
How was it transformed?
Who changed it?
Agentic identity may require a similar concept:
authority provenance.
For a consequential action, we should increasingly be able to reconstruct:
Which human initiated or authorized the objective?
Which agent acted?
Which identity did it use?
Which token represented the authority?
Which permissions were exercised?
Which tool was invoked?
Which downstream service executed the action?
Which policy allowed it?
And which human remained accountable?
That chain may become one of the most important audit trails in an agentic enterprise.
A log saying:
Agent-427 modified record
will not be enough.
Agent-to-Agent Delegation Changes the Scale
Multi-agent systems make this harder again.
Imagine Agent A delegates a task to Agent B.
Agent B calls Agent C.
Agent C invokes an enterprise tool.
Which authority applies?
Can Agent A delegate all of its permissions?
Only some?
Can Agent B further delegate them?
Does Agent C know the original human context?
Does the authorization survive across the chain?
Can the organization enforce purpose limitations?
Can the SOC reconstruct the entire sequence?
Traditional IAM has spent years dealing with delegated access between humans and applications.
Agent-to-agent delegation could make that problem far more dynamic.
Without careful architecture, organizations may create authority chains nobody can fully see.
The Inventory Must Include Actors, Not Just Accounts
This means the identity inventory of the future cannot simply be a directory export.
A list of object IDs is not governance.
For each significant NHI, organizations increasingly need context:
Identity
What is it?
Type
Workload, service principal, API, automation, agent?
Purpose
Why does it exist?
Owner
Which human is accountable?
Workload
What uses it?
Authority
What can it do?
Dependencies
What trusts it?
Credentials
How does it authenticate?
Delegation
Can it obtain or transfer authority?
Lifecycle
When was it created and when should it expire?
Criticality
What is the maximum reachable consequence?
Observability
Can its actions be reconstructed?
For AI agents, I would add:
Tools
Which tools can it invoke?
Data Sources
What can influence its reasoning?
Autonomy
Which actions can it execute without human approval?
At that point, the identity inventory begins to look very different from the IAM inventory most organizations maintain today.
The SOC Must Know Which Identities Are Machines
There is also an operational consequence.
Imagine the SOC sees 500 API calls in five minutes.
Is that suspicious?
For a human identity, probably.
For an automation identity, perhaps normal.
For an AI agent, it depends.
Behavioral detection requires context.
The SOC needs to know:
Is this human or non-human?
What type of workload is using the identity?
What is normal behavior?
Which systems should it access?
Which actions are expected?
Can it operate outside business hours?
Can it originate from multiple locations?
Can it call this particular API?
Has its toolset changed?
Without identity context, telemetry becomes much harder to interpret.
NHI governance therefore cannot live entirely inside IAM.
It must connect to detection and response.
The CISO Needs an NHI Governance Model
For CISOs, the strategic question is not whether non-human identities exist.
They already do.
The question is whether the organization’s governance model recognizes them as a first-class security population.
I would expect a mature NHI governance model to answer at least seven questions:
Do we know they exist?
Discovery.
Do we know what they represent?
Purpose.
Does every important identity have a human owner?
Accountability.
Do we understand what they can ultimately cause?
Authority.
Do they expire when their purpose ends?
Lifecycle.
Can we detect abnormal use?
Observability.
Can we revoke their authority quickly?
Control.
These sound simple.
At enterprise scale, they are not.
But if non-human identities are becoming the dominant identity population, they can no longer remain exceptions to an IAM model designed for people.
The Organizational Chart Is No Longer Enough
There is a deeper consequence here.
For human identities, the organizational chart provides a powerful governance structure.
Employee belongs to manager.
Manager belongs to department.
Department belongs to business unit.
Responsibility can be traced upward.
Machines do not naturally fit that hierarchy.
An API may serve five departments.
A platform identity may support hundreds of applications.
An AI agent may operate across several business processes.
An automation may be technically owned by IT but operationally depended upon by Finance.
This means identity governance increasingly needs two maps.
The organizational hierarchy.
And the technical authority graph.
One explains who is accountable.
The other explains what can happen.
Security needs both.
The Real Problem Is Not That Machines Outnumber Humans
The CSA observation that non-human identities can outnumber human users is important.
But the ratio itself is not the real security problem.
Ten thousand well-governed workload identities may be safer than ten unmanaged privileged service accounts.
The issue is not primarily quantity.
It is whether governance scales with authority.
The dangerous scenario is therefore not:
Machines outnumber humans.
It is:
Machine authority grows faster than human accountability.
That is the gap CISOs should watch.
Because every new workload, automation, integration and agent can create another identity.
Every identity can carry authority.
Every authority can create another path.
And every path can produce consequences.
From Identity Governance to Agency Governance
This is ultimately where the rise of non-human identities takes us.
Traditional IAM governs access.
Modern NHI governance must govern machine authority.
Agentic identity will require us to go further still.
It will require governance of delegated action.
Who may act?
On whose behalf?
For what purpose?
Using which identity?
With which tools?
Within which boundaries?
For how long?
Under whose accountability?
And with what ability to stop the action?
These are identity questions.
But they are also becoming questions of agency.
That distinction will matter enormously.
Because the enterprise of the future may contain far more digital actors than human ones.
We should not fear that.
Automation and AI can create enormous value.
But we should recognize what it means.
We are building organizations in which authority is increasingly exercised by software.
That makes one governance principle non-negotiable:
Non-human execution must never mean non-human accountability.
Every significant machine identity must ultimately lead back to a human decision.
A human owner.
A defined purpose.
A bounded authority.
A controlled lifecycle.
And a clear ability to revoke that authority.
Because the biggest identity challenge of the agentic enterprise may not be authentication.
It may not even be privilege.
It may be something much simpler:
Knowing who is accountable for an identity that is no longer human.
Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.
This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.
For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.
Member discussion