It should come as no surprise that every system these days runs on identities that no employee ever actually logs into.
Service accounts call APIs. CI/CD pipelines deploy code. Kubernetes workloads pull secrets and reach cloud services. SaaS connectors sync data in the background.
And over the past eighteen months, a genuinely new category has joined them: AI agents that authenticate to systems, chain actions across tools, and even spawn other agents, each spawn minting a new identity with no human in the loop.
NIST defines a non-person entity as something with a digital identity that acts in cyberspace but is not a human actor. OWASP describes non-human identities, or NHIs, as the application and machine identities that let software authenticate inside production systems. Both definitions now have to stretch to cover software that decides what to do next on its own.
In 2026, this is no longer a niche concern for platform teams. Sophos's State of Identity Security 2026 report, based on a survey of 5,000 IT and security leaders, found that weak non-human identity management is now the second-greatest root cause of breaches, appearing in roughly 40 percent of security incidents. Gartner named identity and access management adapting to AI agents one of its top cybersecurity trends for the year. The World Economic Forum called NHIs agentic AI's new frontier of cybersecurity risk. The topic has moved from blog posts to board decks.
More from Dave Lewis:
Dave Lewis
Dave Lewis
Dave Lewis
The standards were built for people, but that is finally changing
Most identity standards and operational controls still assume a human is behind the login. NIST finalized SP 800-63-4 in mid-2025 after a roughly four-year revision, and the final publication frames itself around users such as employees, contractors, and private individuals. It sharpened phishing-resistant authentication, added passkeys and mobile driver's licenses, and shifted toward continuous, risk-based evaluation, all valuable, and all pointed at humans.
The service account behind a production app sits outside that frame. It can read data, publish messages, assume roles, and talk to internal services all day long, and no phishing-resistant MFA control touches it. Google's IAM guidance names the problem directly: service accounts are non-human users, and because they are both principals and resources, you have to limit their privileges and protect them from being impersonated.
What has changed in 2026 is that the standards bodies have stopped treating this as a footnote. In February, NIST's National Cybersecurity Center of Excellence published a concept paper on AI agent identity and authorization. In March, engineers from AWS, Zscaler, Ping Identity, and Defakto published the IETF draft known as AIMS, the Agent Identity Management System, which deliberately invents no new protocols and instead composes existing, battle-tested ones: SPIFFE for workload identity, WIMSE for workload-to-workload authentication, and OAuth 2.0 for delegated authorization.
Related drafts cover dual-identity credentials that bind an agent to its owner, agent-specific JWT claims, and SCIM extensions for provisioning agent identities alongside human ones. None of this is finished, the drafts still leave authorization largely as an exercise for the reader, but the direction is set: agents are being standardized as workloads with cryptographic, attestable, short-lived identities, not as users with passwords.
Regulators are moving on a parallel track. Compliance frameworks like SOC 2, ISO 27001, PCI DSS, and NIST 800-53 have always technically covered machine access, and auditors are now asking pointed questions about it. In the United States, the Colorado AI Act's reasonable-care standard for high-risk AI systems took effect at the end of June 2026, and widely adopted identity standards are exactly the kind of evidence that satisfies a reasonable-care test. "We use a vault" is no longer an answer that holds up.
The scale problem keeps getting worse
The ratios were already stark and they keep widening. Google's earlier estimate of 10 to 45 non-human identities per human user now looks conservative. Rubrik Zero Labs and One Identity put the average enterprise ratio around 45 to 1. Entro's research on cloud-native environments found roughly 144 to 1, up more than half in a single year. KPMG's Cybersecurity Considerations 2026 report cites 80 to 1 for the average enterprise, and some 2026 outlooks range as high as several hundred to one depending on how identities are counted. One 2026 analysis puts the average enterprise at over 250,000 NHIs across its cloud estate, with the overwhelming majority carrying more privilege than their function requires.
The exact multiple matters less than the mechanism. Microservices, CI/CD, multicloud deployments, GitHub Actions, SaaS connectors, and automation create new trust relationships every week, and each one gets created in minutes and forgotten for years. Human identities have HR triggers, hire, transfer, terminate. NHI creation has no equivalent lifecycle event. Now add agents that create sub-agents: the fastest-growing identity category in the enterprise is one that can reproduce itself. The result is sprawl that no periodic access review was designed to catch.
What actually goes wrong: the OWASP NHI Top 10
This is why OWASP published a dedicated Non-Human Identities Top 10 in 2025, the first authoritative risk framework built specifically for machine identity. Its ten entries read like a catalog of routine operational failures rather than exotic attacks:
- Improper offboarding: identities that stay active after the workload, project, or owner is gone.
- Secret leakage: keys and tokens exposed in code, logs, or config files.
- Vulnerable third-party NHI: credentials handed to external apps and IDE extensions that can be compromised upstream.
- Insecure authentication: deprecated or weak protocols on high-access processes.
- Overprivileged NHI: identities granted far more access than their job needs.
- Insecure cloud deployment configurations: pipelines authenticating with static credentials or misvalidated OIDC.
- Long-lived secrets: credentials that live for months or years without rotation.
- Environment isolation failures: the same identity reused across test and production.
- NHI reuse: one service account shared across multiple workloads.
- Human use of NHI: engineers borrowing machine credentials for manual work, which destroys accountability.
The failure pattern behind most of these is boring, which is exactly why it survives. A deployment job needs access. A broad role is granted because nobody wants the pipeline to fail. A static key is created because federation takes longer to set up. Months later the job has changed, the owner has moved teams, and the credential still works. The numbers bear this out: roughly 71 percent of NHIs are not rotated within recommended timeframes, only about a fifth of organizations have a formal process for offboarding and revoking API keys, and GitGuardian's secrets-sprawl research found tens of millions of new hardcoded secrets pushed to public GitHub in 2025 alone, with a meaningful fraction of previously leaked credentials still valid long after exposure. Exposed keys plus orphaned identities is a lateral-movement path waiting to be used, and NHI-rooted breaches are now documented in mainstream incident reporting, not just vendor whitepapers.
AI agents: Same risks, at machine speed
For two years, teams managed assistive AI copilots a human validated at each step. Agentic AI reverses that model. An agent plans a sequence of actions, picks its own tools, authenticates to third-party services, reads and writes data, and moves on without approval at each step. That makes every deployed agent a privileged non-human identity, with runtime decision-making, memory, and the ability to chain across tools in ways no policy document anticipated.
The Cloud Security Alliance's January 2026 State of Non-Human Identity and AI Security report makes an important framing point: AI does not introduce a new identity paradigm so much as it magnifies every existing NHI weakness, governance, visibility, ownership, and credential lifecycle, at higher velocity. A traditional API key has a fixed scope you can inventory and audit. An agent operating with delegated access can reason about what it needs, request new permissions, spawn sub-agents, and escalate scope mid-session. The blast radius is larger and the audit trail thinner, and unlike a human account, an agent has no normal behavioral baseline for anomaly detection to learn.
The survey data shows how far behind the controls are. Around two-thirds of organizations say they cannot reliably distinguish AI-agent activity from human activity. More than one in six do not track the creation of AI-related identities at all, and roughly half report no clear ownership for AI identities. Meanwhile, 80 percent of IT leaders in SailPoint's research report having seen agents act outside expected behavior, and a majority of US companies have resorted to mandating human-in-the-loop checkpoints as a stopgap. If you are deploying agents, and most organizations now are, they belong in your NHI inventory as first-class identities with owners, scopes, and review dates, not as clever product features.
The fixes the platforms and standards now agree on
The good news is that the remedies have converged. AWS recommends temporary credentials over long-term access keys, issued through IAM roles and STS. Microsoft recommends workload identity federation and managed identities so software can reach protected resources without storing secrets. GitHub's OIDC guidance follows the same pattern for cloud deployments: federated tokens rather than long-lived secrets, with trust conditions so untrusted repositories cannot mint tokens for your environment. Google has pushed the same direction with keyless API access using X.509 certificates and Managed Workload Identities built on SPIFFE, the same standard the IETF agent-identity work now builds on. That convergence matters: the pattern you adopt today for CI/CD federation is the same pattern the emerging agent-identity standards assume, so the migration is not throwaway work.
Google also supplies the operational detail many teams skip. Create single-purpose service accounts. Avoid service account keys wherever possible. Identify and disable unused accounts before deleting them. Review permissions regularly, because service accounts accumulate access over time. CISA adds the core rule: system and service accounts should have tightly scoped access for the job they perform. None of it is glamorous. It is the advice that keeps an automation credential from becoming your easiest lateral-movement path.
Building the program: inventory, ephemeral auth, blast radius, runtime
A strong NHI program starts with inventory and ownership. Every service account, workload identity, long-lived application credential, and every AI agent should have a named owner, a documented purpose, an environment boundary, and a review date. If nobody can explain why an identity exists, it should not be active. OWASP's offboarding guidance explicitly calls for periodic recertification to confirm NHIs are still needed and still have valid owners, and for agents, decommissioning must include credential revocation as part of the teardown, not a cleanup task for later.
From there, move to short-lived authentication wherever the platform allows it. Managed identities in Azure. Workload identity federation for GitHub Actions and external workloads. IAM roles and temporary credentials in AWS. Certificate-based and SPIFFE-style workload identity removes the shared secret entirely: the private key never leaves the machine and automated rotation eliminates the long-lived-secret problem. Every secret you stop issuing is a secret that cannot leak.
Then tighten the blast radius. Give each workload its own identity. Do not reuse one service account across multiple apps. Do not share identities between test and production. Do not let engineers use NHI credentials for routine manual access. For agents specifically, two additional controls are becoming table stakes in 2026: replace standing access with time-bound, just-in-time grants scoped to the task window, and pair identity governance (what an agent may reach) with runtime inspection (what it actually does inside that boundary). Identity controls define the fence; runtime policy watches what happens inside it. Frameworks like the CSA's MAESTRO threat model for agentic systems give you a structured way to reason about where those controls belong.
A measurable next step
If you want something concrete, do this in the next seven days:
- Export every non-human identity tied to your production environment: service accounts, keys, tokens, workload identities, and every AI agent, including embedded and shadow agents inside SaaS products.
- Assign an owner to each one. No owner, no identity. No, really.
- Delete or disable any identity without a valid owner (disable first, delete after a quiet period).
- Replace one long-lived secret in CI/CD with OIDC or workload identity federation.
- Review the ten NHIs with the broadest permissions and cut any access the workload does not need.
Then, over the next quarter, add the 2026-specific layer: put agents into the same inventory as first-class identities, convert their standing access to time-bound grants, and stand up runtime logging that lets you answer "which agent did this, on whose behalf, and was it in scope?" because that is the question auditors, regulators, and incident responders are now asking.
The teams that get NHIs under control treat machine access, including their AI agents, as real identity infrastructure, not background plumbing. The standards, the survey data, and the breach statistics all say the same thing in 2026: the perimeter is no longer the network or even the human login. It is the growing swarm of identities nobody is watching.
