An engineer chasing a slow overnight report finds an account named svc-etl-prod reading from four databases, one of which holds payroll. Its password was set in 2019. The ticket that created it points at a migration finished years ago, and the engineer named on it left in 2023. Nothing about the account is broken. Nothing about it is owned.
A non-human identity is any identity that authenticates to a system and holds access without a person signing in. Service accounts, cloud workload identities, automation bots, and AI agents all sit inside that definition. So does the integration a vendor asked you to set up last month. API keys and tokens are credentials these identities use, not identities themselves.
Most identity programs know this population exists and cannot say how large it is. An access review, a least-privilege project, and an incident response plan each assume a list somebody assembled on purpose. For the non-human half of the estate, nobody did.
Key Takeaways
- A non-human identity authenticates and holds access without a person signing in: service accounts, workloads, integrations, bots, and AI agents. API keys and tokens are credentials those identities may use.
- This population can outnumber the human one, and no consistent joiner-mover-leaver process sits behind it.
- The defining risk is ownership. When one of these identities has its access questioned, often nobody is accountable.
- Many still rely on long-lived credentials because the thing using them cannot complete an interactive re-authentication.
- Controls built for users mostly do not transfer, since nobody is present to satisfy a second factor.
- AI agents are the newest type rather than a separate problem. They inherit the weaknesses the older types had, and they act faster.
What Are Non-Human Identities?
Answering what non-human identities are is easier by subtraction. Take every identity that can authenticate in your environment, remove the ones attached to a person who signs in, and the rest is the population.
The definition, in plain terms
The non-human identity definition that survives an audit is narrower than the one people use in conversation. An identity qualifies when it holds its own credential, authenticates on its own, and carries access rights evaluated independently of any person's session. A shared spreadsheet password is not one. An account a script uses at 02:00 is.
The acronym NHI is in common use, including in the OWASP Non-Human Identities Top 10, whose 2025 edition ranks these risks by exploitability, prevalence, detectability, and impact.
What makes them different from user accounts
A user account arrives through a process: someone is hired, a record appears in the HR system, provisioning fires, and a leaver event eventually reverses it. Non-human identities arrive through a ticket, a console, or a line in a Terraform file, and no equivalent event ends them.
The second difference is interactive capability. A person can be asked to prove possession of a device. A nightly job cannot, and that constraint drives most of what follows.
Why Non-Human Identities Are Growing Across Enterprises
The population grew because the work moved. Every integration between two systems needs something to authenticate as, and enterprises have spent a decade connecting systems that used to sit apart. One SaaS rollout can produce a directory sync account, a webhook token, a reporting connector, and per-environment API keys before anyone logs in.
Automation multiplied them
Infrastructure as code changed the arithmetic. A Kubernetes cluster does not have one identity. It can have many service accounts across its namespaces, plus the node roles underneath. A CI/CD pipeline holds credentials for every environment it deploys to. Each is correct for its job, and the aggregate is identity sprawl no single team chose.
Nobody offboards a script
OWASP ranks improper offboarding first in its 2025 list, describing the inadequate deactivation of service accounts and access keys once they are no longer needed. That matches what teams find when they look: the migration finished, the vendor was replaced, and the credential is still valid.
Deleting one is also riskier than leaving it. An unused user account can be disabled on a Friday with low consequences. An account that might be running quarterly close cannot, and without an owner who knows, the safe choice is to leave it alone. That asymmetry is why these populations grow.
Common Types of Non-Human Identities
The types of non-human identities in a typical enterprise fall into five groups, separated by what creates them and what they carry. One system often produces several.
| Type | What creates it | What it typically holds | Who usually owns it |
|---|---|---|---|
| Service accounts | A ticket, an installer, or an admin configuring an application | A password or key, often in a group with broad rights | The application team, if ownership survives handover |
| API clients and integrations | A developer registering an integration or generating its credential | An API key or token carrying the scopes granted at issuance | The team operating the integration, if ownership was recorded |
| Workload and machine identities | The platform, at deploy time or at runtime | A short-lived token, or a certificate and its private key | The platform or infrastructure team |
| Bots and RPA | An automation team recording a business process | Logins to the applications it drives, sometimes a person's own | The business unit that requested the automation |
| AI agents | A team connecting a model to a tool, an API, or an MCP server | An OAuth grant, API key, service account, or task-scoped token | Whoever built the integration |
Service accounts
Because the application breaks when the credential changes, a service account accumulates exemptions: excluded from expiry, from rotation, and from the review that covers employees. The exemptions are what make it durable.
API keys and tokens
A key carries the scopes granted when it is issued, which may be broader than the integration needs. That is why one generated for a quick test can outlive both the test and the administrator who created it. Most teams have to start treating keys as an API security problem instead of a developer convenience.
Workload and machine identities
Workloads get identity from the platform, and the mechanism differs by provider. On Amazon EKS, a pod presents a projected Kubernetes service account token, an OIDC JSON web token, to AWS STS through AssumeRoleWithWebIdentity and receives temporary IAM credentials. On Google Kubernetes Engine, the metadata server exchanges a Kubernetes ServiceAccount token through the Security Token Service for a short-lived federated access token, and the access token the workload ends up holding defaults to a one hour lifetime.
Azure managed identities split along a line worth knowing. A system-assigned identity follows its resource's lifecycle and is deleted with it. A user-assigned identity is standalone and can remain after the resources using it are deleted unless someone retires it explicitly. Certificates and private keys belong here too, and the machine identity fundamentals behind certificate issuance and cryptographic key handling carry depth this taxonomy does not need.
Bots and RPA
Robotic process automation (RPA) bots were built to imitate a person, so they often authenticate like one. When a team deploys a bot quickly, it may reuse a real employee’s credentials, causing every action to appear in the logs under that person’s name.
AI agents
An agent holds a credential, calls tools and APIs, and decides its own sequence of actions within the scope it was granted. Agent governance frameworks are a separate subject. What matters here is that an agent is a non-human identity with a planner attached, and that the agentic workforce inherits every weakness the older types had.
Examples of Non-Human Identities in Modern Organizations
The examples of non-human identities below sit inside systems most enterprises already run, because a taxonomy only lands when each type arrives attached to something recognizable.
The nightly ETL job is the canonical case. Created in 2019 to move data into a warehouse, it authenticates with a password set the same week, and the engineer who requested it has left. Over six years it gained read access to three more databases, each grant reasonable in isolation and the set never reviewed together.
An API key tells a shorter story with a wider blast radius. A developer generated one to test a payments integration and pasted it into a configuration file, which was copied into staging and a second production region. One key now authenticates from three environments, and revoking it breaks something nobody can name.
In a poorly isolated Kubernetes environment, a workload without its own cloud identity may reach credentials or permissions associated with the node it runs on. Those permissions are often broader than the workload needs. It works, so nobody investigates, and it can reach object storage the workload never needed.
The RPA bot in finance logs into the invoicing application every morning using a named analyst's credentials, because that was the fastest way to run the pilot and the pilot never ended. The analyst changed roles last year, and their access never narrowed, because narrowing it would stop the bot.
The newest example is an AI agent connected to a CRM through a long-lived OAuth token, granted the scope of whoever authorized the connection. What it can reach is not what any one salesperson can reach. It is what the person who clicked approve could reach.
Why Non-Human Identities Create New Security Risks
A common objection here is that the team already knows about service accounts, has a naming convention, and keeps the secrets in a vault. That addresses one risk out of four. A vault protects the secret. It says nothing about who owns the identity, what it can reach today, or whether anyone would notice it authenticating at three in the morning from a new address.
No owner
Ownership is the risk the other three depend on. With no owner, nobody can say whether the access is still appropriate, approve a change, or sign a meaningful attestation. These are orphaned accounts still in active use, so disabling one and waiting for a complaint carries operational risk.
No expiry
Credentials for unattended processes tend to be long-lived by design, which makes them durable targets. The Hugging Face breach traces what over-privileged, long-lived machine credentials make possible once an attacker holds one. The property that makes a token convenient is what makes token theft worth an attacker's time.
No second factor
Interactive second factors do not fit an unattended process, because nobody is present to approve a push or touch a key. That constraint is real, and it does not leave a team without options.
NSA and CISA's joint advisory on the top ten cybersecurity misconfigurations, AA23-278A of October 5, 2023, treats elevated service account permissions under its second misconfiguration, improper separation of user and administrator privilege. It describes Kerberoasting, MITRE ATT&CK technique T1558.003, in which attackers request service tickets and crack their hashes offline to recover service account credentials. No prompt appears in that path.
Logged as something else
The same advisory states the fourth risk plainly. Describing credentials found in cleartext, it notes that accountability is lost, because system logs record valid user accounts accessing applications or systems. An RPA bot running under an analyst's login produces that effect by accident, and useful audit logging depends on each actor holding its own identity.
The evidence on scale is narrower than the headlines suggest. In the 2026 Data Breach Investigations Report, Verizon found that exploiting vulnerabilities became the top initial access vector for the first time at 31% of breaches, passing stolen credentials; counted anywhere in the breach progression rather than only as the first step, credential abuse still sits on top at 39%.
That report measures breaches, not identity types, and does not split credential abuse into human and non-human use. Its authors do offer one relevant observation: special attention belongs on service and machine accounts, since those are, in their words, the ones likely to be leveraged in a potential agentic AI future.
How NewCore Helps Discover and Govern Non-Human Identities
Every risk in the section above shares one precondition. The identity was not on a list. NewCore's view is that the count is the first deliverable rather than the last, and that the list has to cover the whole environment: the people who sign in, the machines that run without anyone signing in, the service accounts that predate the current team, the automations built to save a few hours a week, and the AI agents connected last quarter. Those five groups authenticate through different mechanisms and arrive through different processes. A program that governs only the first leaves a substantial part of its identity estate outside the model.
NewCore sits alongside what a team already runs. The secrets manager keeps protecting credentials, the identity provider keeps authenticating the workforce, and the IGA platform keeps running the certification and lifecycle processes already in place. NewCore supplies the inventory, the owner, and a governed access path for the identities none of them created.
- Identity Discovery reaches across the systems where identities actually live, from HRIS and directories to identity providers, IGA, PAM, cloud, SaaS, and AI platforms, and continuously indexes every identity, account, credential, and access relationship into one current record. It removes the precondition the problem rests on: a population nobody has counted.
- Agentic Governance applies one policy path across governed access requests, covering agents alongside people. It removes the split where agents are governed by a separate manual process, or by none.
- Agent Guardian mints short-lived, scoped credentials per call for agent execution across tools, apps, APIs, and MCP servers. It removes the long-lived token in a configuration file.
Those capabilities map to identity discovery, agentic governance, and controlled agent execution. Identity now spans humans, machines, and AI agents. Govern the whole population, not the part that filed a ticket. Request a Demo →
Best Practices for Securing Non-Human Identities
Tooling narrows the problem without replacing the judgment. What follows holds regardless of what produced the inventory.
Find them first
Start from the systems that issue credentials. The directory holds a fraction of them. Cloud IAM, the Kubernetes API, SaaS admin consoles, the CI/CD platform, and the secrets store each hold part of the population. Record last-used timestamps in the same pass, since authentication activity separates what is running from what is merely still valid.
Give every one an owner
An owner is a named person, not a team alias, who can say whether the access is still appropriate and who gets the alert when it changes. Assign an owner when the identity still does work someone would miss; retire it when nobody can name what would break. Where the answer is unknown, disable rather than delete, and hold it disabled for longer than the slowest job that identity might run.
Shorten their credentials' life
Prefer credentials the platform issues at runtime over credentials a person creates once. The workload identity mechanisms described earlier exist so a pod or a function never holds a stored secret. Where a static secret is unavoidable, secrets management handles storage and rotation, and rotation frequency should follow the sensitivity of what the credential reaches rather than a fixed calendar.
Frequently Asked Questions
How many non-human identities does a typical enterprise have?
Potentially more than the human count, but the answer varies by environment. Widely quoted ratios come from vendor surveys with different methods and populations, so treat any multiplier with care. The defensible number is the one you produce by enumerating your own issuing systems.
Is a non-human identity the same as a machine identity?
They overlap heavily and get used interchangeably. Machine identity tends to describe the credential layer: the certificates, keys, and tokens systems use to authenticate each other. Non-human identity is the broader term for the principal itself, including bots and agents that are not machines in the infrastructure sense.
Can non-human identities use MFA?
Interactive second factors generally do not fit an unattended process, since nobody is present to approve a prompt. Strong authentication remains available by other means: federated workload identity, mutual TLS with client certificates, and short-lived credentials issued per call. The control changes shape rather than disappearing.
Who should own a service account when the team that created it no longer exists?
Ownership follows the system the account serves, so the current owner of the application or dataset it touches is the usual answer. Where nothing consumes it any more, retirement beats reassignment. Assigning an owner to a dormant account looks like governance without being it.
Do AI agents need their own identities, or can they reuse a service account?
Reusing one works, and it creates the attribution problem described above: the agent's actions become indistinguishable from every other use of that account. A distinct identity per agent makes the logs answerable and lets scope narrow to what the agent does.
