8 Examples of Non-Human Identities Security Teams Should Know

An auditor asks for a list of every account with write access to production. Three weeks later, you hand over a spreadsheet you know is incomplete because the accounts you can name are tied to people, while most of what touches production is not.

A non-human identity is any credentialed identity that authenticates without a person behind it. Non-human identity security begins with discovering these accounts, credentials, workloads, and agents before they accumulate unreviewed access. Across a typical environment, non-human identities fall into eight recognizable types, from an Active Directory service account created in 2019 to an AI agent someone launched last Tuesday. Most teams can name only three.

This article covers all eight types: what each one is, where it appears, who owns it, what an attacker can reach if it is compromised, and the highest-priority control for reducing its risk. It then ranks which identities to address first because they do not present equal risk.

1. Service accounts in Active Directory and on-premises infrastructure

Service accounts are named accounts created for applications, daemons, and scheduled processes rather than people. They often accumulate more unreviewed privilege over time than other identities in an environment.

The category is broader than most inventories capture: domain service accounts in Active Directory, LDAP bind accounts, Windows service identities, database service accounts that maintain connection pools, and daemon accounts such as Apache or MySQL at the operating-system layer. Common locations include domain controllers, legacy SQL instances, and middleware integrations that predate the current team.

Ownership is where governance often breaks down. For example, the engineer who created svc_billing_prod may have left in 2021, the ticket authorizing the account may live in a decommissioned tool, and the naming convention may identify the application it serves without identifying the person accountable for it. Useful attribution signals include the owner of the connected application and the person or team paged when it fails.

Compromised service accounts are among the most consequential non-human identity threats because they may give an attacker access to more than one application. These accounts are often domain-privileged, which can turn a single stolen credential into lateral movement across the environment.

There is often no MFA because there is no person to prompt. Passwords may not expire because rotating them can disrupt production. Because these accounts authenticate at all hours, behavioral baselines may not make anomalous use obvious.

Highest-priority control: Put service accounts into the same user access review cycle as your employees, with last-used data attached to every entitlement. A reviewer who can see that an account has not been authenticated in eleven months is more likely to remove it. A reviewer who sees only a name and a permission string may approve it without enough context.

2. API keys and long-lived tokens

An API key is a static bearer secret, meaning the string itself acts as the identity. Whoever holds it can use it, with no second factor to stop them and no expiration date to limit its lifetime.

Treat these credentials as one family because they behave similarly from a governance standpoint: API keys, personal access tokens, webhook signing secrets, database connection strings, and the SSH keys used by automation. Each is a string that grants access to whoever presents it.

These identities often hide wherever code lives or people discuss it: source repositories, CI configuration, .env files, container images, wiki pages, ticket comments, and direct messages. A key shared in a direct message can turn revocation into a change-management project rather than a click because the same key may exist in five places, and you may be able to find only four.

Attribution is usually possible but rarely easy. The audit log may identify the engineer who generated the key if the retention window reaches back far enough. That engineer may have created it for a project that no longer exists. If compromised, the key exposes whatever scope was granted at creation. That scope is often broader than the integration requires because teams under deadline pressure may prioritize getting it working over scoping it tightly. OWASP tracks both sides of this risk as NHI2:2025 Secret Leakage and NHI7:2025 Long-Lived Secrets.

Highest-priority control: Short-lived credentials are a foundational part of non-human identity breach prevention. Replace long-lived keys with credentials that are issued automatically wherever the platform supports them, and scope any remaining credentials by environment so a leaked staging key cannot reach production data.

3. OAuth apps and third-party SaaS integrations

Whenever an employee clicks Allow, a third party can receive a standing, tokenized identity inside your tenant that security may not have approved or reviewed.

The mechanism is quiet by design. Someone may install a Slack app, connect an AI note-taker to a calendar, or authorize a marketplace add-on in Google Workspace or Microsoft 365. The employee may think they are configuring a tool. In practice, they have provisioned an identity with delegated scope that can persist long after they change teams or leave because standard offboarding often revokes the IdP account but not the grants that the account authorized.

These identities can appear across more consoles than many teams realize, including the connected-apps view in the IdP, the Google Workspace and Microsoft 365 admin consoles, and the integration settings inside individual SaaS applications. That fragmentation makes it difficult to produce a single inventory.

The blast radius is the granted scope, and mail or calendar scopes may be broader than users assume. A read grant on a mailbox is a read grant on the entire mailbox, including anything an executive assistant forwards. It also extends the attack surface to a third party's security program, which your organization does not control and cannot audit on demand. The 2026 Verizon Data Breach Investigations Report put third-party involvement at 48% of breaches, roughly double the prior year. OWASP calls this NHI3:2025 Vulnerable Third-Party NHI.

Highest-priority control: Discover OAuth grants continuously across every tenant rather than waiting until audit time, and revoke access by scope without waiting for someone to uninstall the application.

4. Cloud workload identities

Cloud workload identities are credentials that a cloud platform issues to compute resources so code can authenticate without storing a key.

Product-specific examples include AWS IAM roles attached to EC2 instances and Lambda functions, Azure managed identities, GCP service accounts, and Microsoft Entra service principals. This identity model has real advantages: credentials arrive through the metadata service, expire automatically, refresh automatically, and do not sit in a repository waiting to be committed. It addresses many of the risks associated with static API keys.

However, the model replaces a key-management problem with a permissions problem. A role policy may be written once at build time by a developer trying to get a deployment working, and the fastest fix may be a wildcard. Permissions that are too broad may go unreviewed because they do not break anything.

Security teams should examine the IAM console of every account and subscription, including sandbox accounts with VPC peering connections to production that predate the current network design. Attribution may come from resource tags when tagging is consistent or from the infrastructure-as-code repository when it is not. A compromise can reach whatever the role can assume, along with whatever those downstream roles can assume. That is how one over-scoped Lambda function can become a path into a data warehouse.

Highest-priority control: Compare granted entitlements with actual usage and remove permissions that have never been used. It is the same right-sizing exercise that cloud identity governance applies to human identities, adapted for workloads.

5. Kubernetes and container workload identities

Container identities are credentials bound to workloads. Those workloads can be created and destroyed faster than a periodic review can capture them, and their tokens may remain valid indefinitely unless expiration is configured.

Concrete forms include Kubernetes service accounts, projected service account tokens mounted into pods, and workload identity federation patterns that connect a cluster identity to a cloud role: IRSA on AWS, Workload Identity on GCP, and workload identity federation in Azure.

Default configuration creates much of the risk. Every namespace receives a default service account whether anyone requested it or not. Unless automounting is disabled, every pod in that namespace receives its token. Kubernetes Secrets are base64-encoded rather than encrypted, so anyone who can read the API object can read the secret. Review your cluster RBAC bindings and count how many workloads are bound to a default identity.

Ownership often splits at an awkward boundary. The platform team owns the cluster and the RBAC model, while application teams own what deploys into it. Those application teams may not have written the binding. A compromised pod can move laterally inside the cluster, and it can move outside the cluster when its service account is federated to a cloud role with meaningful permissions.

Highest-priority control: Disable default service account token automounting and bind every workload to its own scoped identity so a compromised container inherits nothing by accident.

6. CI/CD pipeline credentials

In many environments, the identity that can write to production has less governance around it than the human identities it supports. That identity often belongs to the build pipeline.

Deploy tokens in GitHub Actions, Jenkins credentials, Terraform Cloud API tokens, and Azure DevOps service connections can push code to production, provision infrastructure, and read every secret the pipeline is allowed to inject at build time. Meanwhile, these credentials may live on repository settings pages that security teams rarely review.

Common locations include repository-level and organization-level secrets, runner configuration, self-hosted runners that have not been patched since deployment, and pipeline forks that teams copied years ago but still run. Each copy carries its own credential and permissions.

Ownership is usually clear, which should move this category toward the top of the priority list. The engineering team that owns the repository typically owns the pipeline. That clarity can make this a high-consequence category that is also relatively straightforward to address because you know whom to contact. The blast radius includes everything downstream of the build. If you ship software, that includes your customers. As a result, pipeline compromises can trigger mass credential-rotation events across an entire customer base rather than a contained incident.

Highest-priority control: Scope tokens by repository and environment, replace stored static cloud keys with OIDC-based short-lived credentials, and require approval for any pipeline change that touches production credentials.

7. RPA bots and automation scripts

RPA bots are the only non-human identities on this list that deliberately impersonate humans, which can make them difficult for detection logic designed to distinguish machines from people.

The reason is structural. If the finance application that a bot operates has no usable API, the bot may log in through the interface with a real username and password. To run reliably overnight, it may need an MFA exemption and a password-expiration exemption. Those exemptions may be granted quietly by someone who reasonably wants the invoice run to finish.

Common locations include the RPA platform's credential store, the ERP and finance applications that the bots operate, scheduled tasks and cron jobs that have not been audited since they were written, and shared accounts with names such as automation whose passwords are known to multiple teams.

Ownership often sits outside IT. The business team that commissioned the automation, usually finance or HR, may think of it as a process rather than an identity. Compromising one of these bots can give an attacker the same access as a finance analyst, but the attacker can operate continuously, at machine speed, without triggering normal session anomalies. In addition, a bot that both creates and approves an invoice creates a segregation-of-duties violation that may surface as an audit finding even when the bot has not been compromised.

Highest-priority control: Give every bot its own named credential under a convention that makes it identifiable on sight. Then include those accounts in your segregation-of-duties analysis alongside human accounts.

8. AI agents

Unlike the other categories, an AI agent can decide what to access as it works. That capability challenges the assumptions behind many of the controls described above.

The other seven types authenticate to perform predetermined tasks. A service account queries its database. A pipeline token deploys its repository. An agent receives a goal, chooses which tools to call, and acquires access at runtime based on what it determines the task requires.

That creates three governance gaps. First, an agent may acquire credentials while it runs rather than at provisioning time, making the provisioning record incomplete. Second, it acts under delegated human authority that an audit log may not capture, so the trail shows what happened but not on whose behalf it happened. Third, it may start and terminate within a single task, so a quarterly review may never record its existence.

Relevant discovery points include agent registries; app registrations and service principals that represent agents in the IdP; MCP server configurations and their attached tool credentials; and agents that individual employees created with corporate cards without notifying security.

Ownership is central to the problem. An agent should be traceable to a named human sponsor who is accountable for its actions. In many environments, it is not, making it difficult to explain why the agent accessed a particular resource. The blast radius is the combined access of every tool the agent can call, and that access can grow whenever someone adds a connector. OWASP added a Top 10 for agentic applications in 2026, and identity and privilege abuse is included within it.

Highest-priority control: Require a named human sponsor and a scoped, expiring credential before any agent reaches production. Treat "no sponsor" as a blocking condition rather than a finding to track. Agentic AI security starts with knowing whose authority the agent is acting under.

Which NHI types should you address first?

The highest-risk NHI in many environments may be one with substantial privilege and no effective oversight, even when its owner is easy to identify.

Lists like this can imply that every entry presents equivalent risk. They do not. Four practical metrics to evaluate non-human identity governance are standing privilege (can it write to production without asking?), credential lifetime (minutes or years?), detection difficulty (would anomalous use look different from normal traffic?), and ownership clarity (can you name an accountable human in under a minute?).

‍

Eight NHI types, one inventory

A scalable non-human identity security strategy treats these as eight categories within one program, not eight separate programs. The distinction determines whether you end up with unified governance or more non-human identity sprawl.

When teams evaluate non-human identity management solutions, the reflex is often to buy a different tool for each identity type: a secrets scanner for the keys, a CIEM for the cloud roles, an agent-governance product for the agents, and a spreadsheet for everything else. The result is four inventories, four owners, four review cadences, and an auditor who still cannot get one answer to the question of what has access to a given application.

Each of the eight types follows the same lifecycle as a human employee: it is created, granted access, reviewed on a schedule, and revoked when its purpose ends. That shared lifecycle supports governing machines and people in one inventory, under one set of least-privilege policies, within the review engine you already use.

A small number of platforms are designed to support that model. Lumos catalogs human and machine identities together and applies the same lifecycle automation and delta access reviews to service accounts that it applies to employees. This approach helped ChargePoint connect more than 100 applications in under three months and surface unused and orphaned accounts that were missing from existing inventories.

The payoff is what security teams are measured on at quarter-end: one audit trail instead of four, one place to answer access questions, and no second inventory to reconcile before certifying access.

When the next step is building the program, non-human identity management covers the lifecycle from end to end.

Every identity on this list is already running without you

You automated your deployments, infrastructure, and software delivery. The pipeline token that ships the code, the workload role that runs it, and the service account it queries are the reasons all of that happens without you in the room.

Those same three identities may still be tracked in a spreadsheet and certified once a quarter, if at all, by a manager who does not know what svc_billing_prod does and clicks Approve because the deadline is today. The result is eight categories, four software tools, and still no single answer when an auditor asks who has access to production.

Lumos governs all eight types in the same inventory as your employees, allowing a service account, an OAuth grant, and an AI agent to move through one lifecycle instead of four disconnected ones. Discovery runs continuously across your IdP, cloud environments, and applications. Ownership is attributed automatically. Delta access reviews show reviewers only what changed, making machine-access certification more manageable at scale.

Book a demo, name whichever of the eight types concerns you most, and we will show you which identities hold standing access in your environment.

‍