Your human employees are no longer the primary identity risk in your environment. In 2026, the average enterprise runs 45 non-human identities for every single human user — a ratio that has tripled in 18 months, driven almost entirely by the agentic AI explosion. Service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, LLM agent wallets, robotic process automation (RPA) bots, and cloud function roles now constitute the overwhelming majority of active identities in your estate.
And almost none of them are governed.
This is the Non-Human Identity (NHI) crisis — and it is the single most under-resourced vulnerability class in enterprise IT security today. While your SOC monitors phishing campaigns and your IAM team enforces MFA for the sales team, an entire shadow identity ecosystem runs unchecked in the background, accumulating privilege, expiring tokens silently, and creating the perfect pivot path for any attacker who finds a foothold.
Table of Contents
What Is a Non-Human Identity?
A Non-Human Identity (NHI) is any credential, token, or identity object that is used by a machine, application, script, or automated process — rather than a human — to authenticate to a system and perform actions. The category is broad and growing:
- Service Accounts: Windows/Linux OS accounts used by background applications and scheduled tasks.
- API Keys & Secrets: Static credentials embedded in CI/CD pipelines, configuration files, or environment variables.
- OAuth 2.0 Tokens: Short-lived (or not-so-short-lived) access grants issued to SaaS integrations and third-party apps.
- Cloud IAM Roles: AWS IAM roles, Azure Managed Identities, GCP Service Accounts attached to compute resources.
- AI Agent Wallets: Provisioned identities granted to autonomous LLM agents with spend authority, database access, or email permissions.
- RPA Bot Credentials: Accounts used by automation tools like UiPath, Power Automate, or Automation Anywhere that simulate human desktop sessions.
- SSH Keys & X.509 Certificates: Long-lived cryptographic credentials used for machine-to-machine authentication.
The defining characteristic of an NHI is that it acts continuously and autonomously, often with minimal human oversight. A human user logs in, does work, and logs out. A service account authenticates every 30 seconds, indefinitely. This persistent, high-frequency access pattern is precisely what makes NHIs so dangerous when compromised.
The Scale of the Problem in 2026
The NHI challenge isn't new, but three forces have converged in 2026 to make it an acute crisis rather than a slow-burn risk.
1. The Agentic AI Surge
When enterprises began deploying autonomous AI agents at scale in late 2024, each agent required its own identity: a credential to access data stores, APIs, CRM systems, and financial platforms. Unlike human accounts, these agent identities were provisioned rapidly by development teams who prioritized speed over hygiene. The result: thousands of over-privileged, under-monitored machine accounts spawned in months, with no deprovisioning workflow and no rotation schedule.
2. Multi-Cloud Sprawl
The average SMB now operates across 2.8 cloud environments. Each environment has its own IAM system — AWS IAM, Azure AD / Entra ID, GCP IAM, and dozens of SaaS platforms. There is no unified NHI registry. Service accounts created for a workload on AWS have no visibility in Azure, and vice versa. This fragmentation means your total NHI footprint is radically larger than any single team can see.
3. The DevSecOps Gap
Development teams create NHIs constantly as part of normal CI/CD operations. GitHub Actions secrets, Kubernetes service account tokens, Terraform backend credentials — every automated workflow generates identities. Security teams are rarely in the loop until a breach surface appears in a SIEM alert. By then, a credential may have been sitting idle with broad permissions for 18 months.
Top 5 NHI Attack Vectors
Threat actors have recognized that NHIs are the path of least resistance. The attack patterns are well-established and repeatable:
| Attack Vector | How It Works | Real-World Example |
|---|---|---|
| Secret Sprawl | API keys and passwords committed to public or private code repositories, exposed in Docker images, or hardcoded in config files. | Trufflesecurity scans find millions of leaked keys in GitHub repos annually. Average time-to-exploit: 4 minutes after public commit. |
| Token Hijacking | Attacker obtains a long-lived OAuth token or JWT via XSS, SSRF, or a phishing link and uses it to impersonate an automated service with broad access. | CircleCI breach (2023) — malicious agent exfiltrated customer secrets from CI pipeline jobs using stolen session tokens. |
| Privilege Escalation via Over-Permissioned Roles | Service accounts provisioned with broad roles (e.g., `iam:*` or `s3:*`) become pivot points. Compromise one low-value service to reach high-value data. | Most AWS S3 data exposures trace back to over-permissioned EC2 instance profiles, not leaked root credentials. |
| Zombie NHI Reactivation | Decommissioned services leave credentials in active state in the IdP. Attackers rediscover and reactivate them months later. | 2025 healthcare breach — attacker leveraged a service account from a deprecated EHR integration that had never been offboarded. |
| AI Agent Prompt Injection → NHI Abuse | Malicious content in data processed by an AI agent manipulates it into exfiltrating data or calling unauthorized APIs using its provisioned identity. | See: Agentic AI & Prompt Injection risks — the agent's NHI credential is the weapon. |
The Agentic AI Multiplier
The agentic AI boom has introduced a fundamentally new NHI risk class: the AI Agent Wallet. When you provision an autonomous agent to handle procurement, customer support escalations, or data enrichment, that agent needs credentials. And those credentials are typically provisioned by developers who have never read your IAM policy baseline.
The result is a new generation of NHIs with capabilities that would terrify most CISOs if they knew they existed:
- An AI procurement agent with access to corporate payment APIs and the authority to spend up to $10,000 per transaction — with no multi-approval gate.
- A customer support agent with read/write access to the full CRM database — because the developer connected it to "the real DB" for faster responses.
- A data enrichment agent with an active API key to LinkedIn, Clearbit, and your internal HR system simultaneously — a lateral movement dream for an attacker.
These agent identities also introduce a unique governance challenge: they act at machine speed. A compromised human account might exfiltrate data over hours as the attacker manually navigates. A compromised AI agent NHI can exfiltrate the entire database in under 90 seconds while the agent is still "performing its job." Traditional behavioral anomaly detection, calibrated for human usage patterns, often fails to flag this until it's far too late.
The NHI Governance Framework
Closing the NHI gap requires a structured governance approach. The framework has four pillars, each building on the last:
Pillar 1: Discover & Inventory
You cannot govern what you don't know exists. The first step is a comprehensive NHI discovery across every environment: cloud providers, SaaS platforms, on-prem Active Directory, CI/CD pipelines, and code repositories. This means scanning for:
- All service accounts in Azure AD / Entra ID, AWS IAM, and GCP.
- All API keys and secrets in GitHub, GitLab, Bitbucket, Jira, and Confluence.
- All OAuth grants issued by your Microsoft 365 and Google Workspace tenants to third-party apps.
- All SSH keys and TLS certificates, with expiration dates and owner attribution.
The output should be a living NHI Register — a single source of truth, ideally integrated with your CMDB, that records every NHI, its owner, its level of privilege, its last-used date, and its rotation schedule.
Pillar 2: Classify & Risk-Score
Not all NHIs are equally dangerous. Risk-score every entry in your NHI Register based on: privilege level (admin vs. read-only), blast radius (what systems and data could be accessed if compromised), usage frequency (active vs. dormant for 90+ days), and exposure surface (is the token used in a public-facing service?). An AI agent with write access to your financial database and an OAuth token exposed in a public-facing webhook deserves a Critical rating that triggers immediate remediation.
Pillar 3: Enforce Least Privilege & Rotation
The two most impactful technical controls for NHIs are ruthlessly simple:
- Minimum Necessary Permissions: Every NHI should be granted only the specific permissions it needs to perform its function, nothing more. Audit and trim existing permissions quarterly. For cloud roles, use AWS IAM Access Analyzer, Azure's Permissions Management (formerly CloudKnox), or GCP's Policy Analyzer to identify and remove unused permissions.
- Mandatory Rotation: Long-lived credentials are the enemy. Automate rotation for all API keys and service account passwords on a 30-day or shorter cycle. Use short-lived credentials wherever possible — AWS STS temporary credentials, Workload Identity Federation for GCP, and Azure Managed Identities eliminate static long-lived keys entirely.
Pillar 4: Monitor & Respond
Even with strong provisioning hygiene, runtime monitoring is essential. Integrate NHI activity data into your SIEM and establish behavioral baselines for each NHI. An API key that calls three endpoints 200 times daily should trigger an alert if it suddenly begins calling 50 different endpoints. For AI agents specifically, implement immutable action logs — every API call an agent makes should be recorded, attributed to its specific NHI, and auditable. This is not just a security control; in regulated industries under DORA and NIS2, it is a compliance mandate.
Tooling Landscape: Managing NHI at Scale
The NHI market has matured rapidly. Dedicated platforms now exist specifically for machine identity management, moving beyond the ad hoc approaches of previous years:
| Category | Capability | Representative Vendors |
|---|---|---|
| Secrets Management | Centralised vault for secrets, automated rotation, dynamic credentials | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk Conjur |
| Cloud Entitlements (CIEM) | Discover and right-size cloud IAM permissions across multi-cloud | Wiz CIEM, Orca Security, Microsoft Entra Permissions Management |
| NHI Security Platform | Dedicated NHI discovery, risk scoring, lifecycle governance | Astrix Security, Entro Security, Clutch Security |
| Certificate Lifecycle Management | Discover, monitor, and auto-renew TLS/SSH certificates | Venafi, CertCentral (DigiCert), AppViewX |
| SSPM with NHI Scanning | Discover third-party OAuth integrations in SaaS tenants | Varonis, Obsidian Security, Nudge Security |
For SMBs without an enterprise security budget, a practical starting point is combining AWS Secrets Manager or Azure Key Vault (for secrets rotation) with Entra ID's OAuth app audit (for SaaS NHI visibility) and a secrets scanning tool like Trufflehog or GitGuardian in your CI/CD pipeline. This stack covers 80% of the most exploited attack surface for a fraction of the cost of a dedicated platform.
Your 60-Day NHI Remediation Plan
A practical timeline to transform NHI from your most ignored risk into a controlled surface:
Days 1-14: Inventory Sprint
- Run discovery scans across cloud IAM, Active Directory service accounts, and all code repositories.
- Catalogue every OAuth grant in your M365 and Google Workspace tenants.
- Pull a full list of all AI agent provisioned credentials (coordinate with DevOps and the teams deploying LLM agents).
- Output: A raw NHI Register with estimated risk score for each entry.
Days 15-30: Triage & Kill the Worst Offenders
- Identify and immediately revoke all NHIs with "last used" dates older than 90 days that have not been formally justified by a service owner.
- Rotate all static API keys and passwords on a priority basis — start with the highest-risk (admin privileges, public-facing services).
- Migrate highest-risk workloads from static credentials to short-lived token mechanisms (Workload Identity Federation, IAM Roles for Service Accounts).
Days 31-60: Establish Ongoing Governance
- Implement automated rotation for all remaining static credentials via a secrets manager.
- Define and enforce an NHI provisioning policy requiring owner attribution, least-privilege review, and rotation schedule before any credential is issued.
- Integrate NHI activity logs into your SIEM and establish baseline alerting rules for anomalous access patterns.
- For AI agents: implement an "Agentic Red-Line" governance layer that hard-limits the permissions any single agent identity can hold.