Every enterprise identity program was built around a simple assumption: a person logs in, does some work, and logs out. That assumption is now wrong for the vast majority of "identities" touching enterprise systems. Service accounts, API keys, OAuth tokens, CI/CD pipelines, IoT devices, and increasingly AI agents outnumber human employees by a wide margin — and most identity and access management (IAM) programs were never designed to see them, let alone govern them.
This isn't a future problem. It's already the dominant category of identity in production environments, and it's growing faster than any security team's ability to inventory it manually.
What a Non-Human Identity Actually Is
A non-human identity (NHI) is any credentialed entity that authenticates to a system without a person typing a password at the moment of use. That's a broad category, and it's worth breaking apart because the risk profile differs across types.
- Service accounts — accounts created so one application or system can talk to another (a database connection account, a monitoring agent, a backup job).
- API keys and tokens — static or rotating credentials that let software call an external service (a payment processor, a cloud provider, a SaaS integration).
- Machine-to-machine (M2M) OAuth clients — applications that authenticate using client credentials rather than a user login flow.
- Workload identities — identities assigned to containers, pods, serverless functions, or VMs so they can call other cloud resources (AWS IAM roles, Azure Managed Identities, Kubernetes service accounts).
- Bots and RPA accounts — scripted automation that logs into systems the way a human would, often using a shared credential.
- IoT and device identities — certificates or keys embedded in physical devices, from badge readers to industrial sensors.
- AI agents — a newer and fast-growing category: autonomous or semi-autonomous software that holds its own credentials, calls APIs and tools on a schedule or in response to triggers, and increasingly spawns sub-tasks or delegates to other agents.
What unites all of these is that no human is present at the moment of authentication to notice something is wrong. A person who gets an unexpected MFA prompt at 3 a.m. might report it. A service account that authenticates every five minutes, 24 hours a day, generates no such signal — anomalous behavior has to be detected algorithmically or not at all.
How NHIs Get Created
Non-human identities rarely go through the same provisioning process as a new employee. A developer spins up an API key to test an integration and never removes it. A CI pipeline is granted a broad IAM role because narrowing permissions would have taken another afternoon. A SaaS vendor's onboarding wizard requests OAuth scopes far wider than the integration needs, and someone clicks "Allow" to unblock a project. Multiply this across every team, every tool, and every quarter, and you get sprawl that nobody planned and nobody fully owns.
Contrast this with how a human identity is created. A new hire triggers an HR event, which triggers a provisioning workflow, which creates a directory account with a defined role, a defined manager, and a defined start and (eventually) end date. Every step is visible to at least one system of record. A non-human identity typically has none of that scaffolding — it's created by whoever needed it, whenever they needed it, through whatever interface was fastest, and it persists until someone notices it's unused and deletes it, which in practice can mean it persists indefinitely.
Why the Ratio Is Now 45:1 — and Climbing
The 45:1 figure — and some analyses put enterprise machine-to-human identity ratios as high as 100:1 — reflects a few compounding trends rather than one cause.
Cloud-native architectures decompose applications into dozens or hundreds of microservices, each of which needs its own identity to talk to the others. A monolithic application that once had one service account might now be a mesh of forty containers, each with a workload identity. Add CI/CD automation (every pipeline stage authenticates to something), SaaS sprawl (every integration mints its own API key), and IoT deployment (every sensor gets a certificate), and the machine identity count grows combinatorially while headcount grows linearly at best.
AI agents are the newest and fastest-accelerating contributor. Where a traditional API integration is one static credential performing one narrow function, an AI agent often needs standing credentials across multiple systems — a ticketing tool, a code repository, a cloud console, an internal database — because its value comes from acting across boundaries a human would otherwise bridge manually. And unlike a service account that one team owns, an agent's permissions can expand as its task list grows, without a corresponding change-control process catching the drift.
The result: identity teams that spent a decade building mature processes around human joiners, movers, and leavers now find that population is a shrinking minority of what they actually need to govern.
Why This Matters for Security Teams Right Now
The risk isn't theoretical. Non-human identities tend to have the exact properties that make a credential dangerous in the wrong hands, and they carry them by default rather than as an exception.
| Property | Human identity (typical) | Non-human identity (typical) |
|---|---|---|
| Credential lifetime | Rotated on password policy, session expires | Often static, sometimes never rotated |
| Ownership | Clear — tied to an employee record | Frequently orphaned after the creator leaves |
| Privilege scope | Reviewed at least annually via access recertification | Rarely reviewed; often over-provisioned at creation |
| Visibility to security tools | High — SSO, MFA, UEBA all instrument human logins | Low — many NHIs bypass SSO/MFA entirely |
| Behavioral baseline | Anomalies (odd hours, new location) are easy to flag | Constant automated activity makes anomalies hard to isolate |
| Blast radius on compromise | Limited to that user's access | Can be broad — service accounts often hold elevated, cross-system privileges |
Static, over-privileged, poorly-monitored credentials are a familiar description of breach root causes — because attackers have already noticed this gap. Compromised API keys, leaked service account credentials in code repositories, and stolen OAuth tokens have been the entry point or the lateral-movement mechanism in a steady stream of publicized incidents. An orphaned service account left behind by a departed contractor, still holding write access to production, is not a hypothetical; it's one of the most common findings in cloud security assessments.
AI agents raise the stakes further. An agent that's been granted broad tool access to move faster on a task is also a broad attack surface if its credentials, prompts, or the systems it calls are manipulated — a risk category security teams are now grouping under agentic AI security, distinct from but overlapping with classical NHI risk.
Why Traditional IAM Wasn't Built for This
Most enterprise IAM programs grew up solving human identity problems: single sign-on, multi-factor authentication, access recertification tied to HR events, and password policies. Applied to non-human identities, each of these breaks down in a specific way.
- No HR system of record. A new employee triggers a joiner workflow in the HR system that IAM can hook into. A new service account triggered by a Terraform apply has no equivalent event, so provisioning happens outside the governed process by default.
- MFA doesn't apply. A machine can't respond to a push notification. Non-human identities typically authenticate with something-you-have (a key or certificate) and nothing else, which collapses a two-factor model into a single factor.
- Ownership decays. A human account's owner is unambiguous. A service account's "owner" is often whichever engineer created it — and when that person changes teams or leaves the company, the account frequently just keeps running, invisible to offboarding checklists that only look for human accounts.
- Recertification cadence doesn't fit. Annual or quarterly access reviews assume a human can meaningfully answer "do I still need this access?" Nobody is positioned to answer that question for a workload identity buried three layers into a CI pipeline unless the review process was specifically designed to reach it.
- Secrets sprawl across tools. Human credentials live in a directory service. Machine credentials live in code repositories, CI/CD variables, config files, cloud secret managers, and Slack messages — often all four in the same organization, with no single inventory.
Practical Implications for Businesses and Builders
Closing the NHI gap doesn't require ripping out existing IAM investment, but it does require treating machine identity as a first-class governance category rather than an IT hygiene afterthought.
Start with discovery, not policy. You cannot govern what you cannot see. Most organizations that run a serious NHI discovery exercise for the first time find several times more machine identities than they estimated, along with a meaningful share that nobody can identify the owner or purpose of. Discovery tools that scan cloud IAM configurations, secret managers, code repositories, and CI/CD systems are now a distinct product category for exactly this reason.
Assign ownership at creation, not after the fact. The cheapest point to fix orphaned-account risk is the moment the identity is created — require a named owner, a stated purpose, and an expiration or review date as fields that can't be skipped in the provisioning workflow, whether that's a self-service portal or an infrastructure-as-code template.
Move toward short-lived credentials by default. Static, long-lived API keys are the highest-risk credential type because a single leak (in a repo, a log, a misconfigured bucket) grants standing access indefinitely. Cloud-native workload identity mechanisms — short-lived tokens issued per-session rather than static keys — reduce the value of any single leaked credential dramatically.
Apply least privilege as a default, not a cleanup task. NHIs are routinely over-provisioned because it's faster to grant broad access once than to scope it precisely and revisit later. Automated tooling that compares granted permissions against actually-used permissions, and flags the gap, is a more realistic path to least privilege than manual review at this scale.
Bring NHIs into incident response playbooks explicitly. If a service account or API key is suspected compromised, does your team know how to find every system it can reach, rotate the credential, and confirm no persistence was established — in the same way it would for a compromised employee laptop? Many organizations discover the answer is no only during an actual incident.
Treat AI agents as a distinct, higher-scrutiny NHI subclass. An agent that can read code, open pull requests, query a database, and post to a ticketing system in the course of one task has a combined blast radius that a single-purpose service account doesn't. Scoping agent credentials tightly to the task at hand, logging every tool call the agent makes, and requiring human approval for high-impact actions are emerging as baseline controls rather than optional extras.
Limitations and Open Questions
The NHI security space is young, and a few things remain genuinely unresolved rather than simply under-adopted.
- Standards are still fragmented. There's no universal schema for describing a non-human identity's owner, purpose, or lifecycle across cloud providers, SaaS vendors, and on-prem systems, which makes cross-platform inventory harder than it should be.
- Discovery tools produce different counts. Because there's no single agreed definition of what counts as an NHI (does a Kubernetes service account with no active permissions count? Does a disabled API key?), organizations evaluating vendors in this space often get materially different inventory numbers from different tools scanning the same environment.
- AI agent identity is still being defined. Should an agent acting on a user's behalf inherit that user's identity and permissions, or hold its own distinct identity with its own audit trail? Both models are in active use across different platforms today, and the industry hasn't converged on one answer — with real consequences for accountability when something goes wrong.
- Rotation isn't always feasible. Some legacy systems and embedded devices simply can't support short-lived credentials or automated rotation without a hardware or firmware change, leaving a long tail of static-credential risk that policy alone can't fix.
- Ownership in distributed teams is genuinely hard. In organizations using platform engineering models where infrastructure is self-service, "who owns this identity" can honestly have more than one correct answer, and governance frameworks are still catching up to that reality.
- Tooling maturity varies wildly by environment. Discovery and governance for NHIs in a single well-managed cloud account is a largely solved problem today; the same task across a hybrid estate spanning multiple clouds, on-prem infrastructure, and dozens of SaaS vendors is still closer to an integration project than a product you can buy off the shelf.
What to Watch Next
Non-human identity is consolidating into its own security discipline, distinct from but adjacent to traditional IAM — expect the term "NHI security" or "machine identity security" to show up increasingly as a named budget line and a named vendor category rather than a feature bolted onto existing IAM suites. Regulatory and compliance frameworks are also starting to catch up: expect audit and compliance questionnaires to begin asking pointed questions about service account inventories and credential rotation policies, the way they already do for human access reviews. And as AI agents move from pilot projects to production workflows with standing system access, the identity and permission model for agents specifically — not just service accounts in general — is likely to become one of the more actively contested design questions in enterprise security over the next few years.
FAQ
What is a non-human identity (NHI)?
A non-human identity is any credentialed entity — a service account, API key, OAuth client, workload identity, bot, IoT device, or AI agent — that authenticates to a system without a human present at the moment of login. It's distinguished from human identity by the absence of real-time human judgment during authentication.
Why do machine identities outnumber human identities so heavily?
Cloud-native architectures split applications into many microservices, each needing its own identity; CI/CD pipelines, SaaS integrations, and IoT devices each mint additional credentials; and AI agents increasingly hold standing access across multiple systems. These sources compound while human headcount grows far more slowly.
How is non-human identity security different from regular IAM?
Traditional IAM is built around human events — logins, MFA prompts, HR-triggered joiner/mover/leaver workflows, and periodic access reviews a person can meaningfully answer. Non-human identities lack most of these anchors: no MFA-capable device, no HR trigger for creation, and no obvious person to ask during a recertification cycle.
What's the biggest risk from unmanaged non-human identities?
Static, over-privileged, and orphaned credentials are the most common failure mode — a service account or API key that was scoped too broadly at creation, never rotated, and left running after the person who created it moved on or left the company, giving an attacker a durable and often highly privileged foothold if it's ever leaked or compromised.
How should AI agents be treated differently from other service accounts?
AI agents often need standing access across multiple tools and systems to complete their tasks, giving them a broader combined blast radius than a single-purpose service account. Best practice is to scope agent credentials tightly to each task, log every action the agent takes, and require human approval for high-impact operations.
Can non-human identity sprawl actually be inventoried?
Yes, but it typically requires dedicated discovery tooling that scans cloud IAM configurations, secret managers, code repositories, and CI/CD systems — manual spreadsheets and periodic audits consistently undercount NHIs by a wide margin because so many are created outside any formal provisioning process.
What's the first practical step for a company with no NHI program today?
Run a discovery pass to build an actual inventory before writing any policy — most organizations are surprised by both the volume of non-human identities they find and the share with no identifiable owner, and that inventory is the prerequisite for every subsequent step, from ownership assignment to credential rotation.
Teams that need help turning an NHI inventory into an actual governance and rotation program can find hands-on support from Woyce Technologies.