What are non-human identities?
Non-human identities (NHIs) are software principals that authenticate and execute actions autonomously in cloud environments without human intervention. Because there is no interactive user behind these sessions, these machine accounts function largely outside traditional identity perimeter safeguards like interactive session expirations, multi-factor authentication (MFA) prompts, or interactive password reset workflows. Instead, an NHI is typically represented by a cryptographic credential that binds programmatic permissions to an active cloud workload, containerized application, database, or automated orchestration script, executing operations at machine scale and velocity.
According to the OWASP Non-Human Identities Top 10 Project, machine identities outnumber human accounts by a baseline ratio of 100:1 across automated enterprise cloud environments. In highly distributed cloud-native deployments, it can be as high as 145:1.
This massive variance isn’t a statistical anomaly; it’s direct evidence that standard, fragmented tracking utilities fail to maintain an accurate count of automated assets.
What unifies NHIs into a single architectural category rather than a disconnected collection of unrelated credential types is their shared governance characteristics. They authenticate, access resources, accumulate privileges, and eventually go stale without any of the lifecycle controls built for human accounts, such as behavioral profiling or explicit ownership logging.
Traditional identity and access management (IAM) consoles weren’t designed to monitor this programmatic scale natively. This is why engineering teams increasingly leverage cloud infrastructure entitlement management (CIEM) frameworks to centralize visibility and audit machine credential behavior across multi-cloud environments.
The 4-Step Framework for AI Threat Readiness
Wiz has designed a 4-step framework to help organizations defend against rapid, automated exploitation in a post-Mythos world.
The NHI taxonomy
The NHI category contains several distinct types, each with different creation patterns, storage locations, and exposure characteristics.
1. Service accounts
Service accounts are the most common NHI. AWS IAM roles for EC2 and EKS workloads (including IRSA and the newer EKS Pod Identity, AWS's recommended approach since late 2023), GCP service accounts, Azure Managed Identities, and Kubernetes service accounts bound to pods all fall here.
Kubernetes service accounts in particular are worth calling out: They are injected automatically into pods at creation, grant in-cluster API access, and can be configured with IRSA or EKS Pod Identity bindings that extend permissions to AWS resources. This makes them a potential lateral movement surface in Kubernetes environments. For Kubernetes security posture management, identifying overprivileged service accounts should be a primary focus of any inventory exercise.
2. API keys and long-lived secrets
These static credentials are issued to applications, third-party integrations, and automation scripts. By default, they carry no expiry. AWS and GCP both flag long-term access keys as an anti-pattern in their official guidance.
When stored in a secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault), teams can automate rotation. But that automation is rarely enforced consistently at scale. In many large environments, a significant portion of API keys still exist outside centrally managed secrets platforms.
3. OAuth and delegated access tokens
OAuth tokens and short-lived access tokens are issued dynamically during app-to-app delegation flows. They are absent from static IAM access-key inventories and routinely overlooked in audits because they don’t appear in the same consoles where teams manage service accounts.
4. Azure Service Principals and Managed Identities
Azure’s identity surface requires a nuanced approach to machine risk. Under the hood, Azure Managed Identities are actually a specialized type of Entra ID (formerly Azure AD) Service Principal where Azure automatically manages the credential lifecycle, eliminating human-handled keys. Traditional Entra Service Principals, however, rely on user-managed client secrets or certificates. These are heavily utilized for third-party SaaS integrations, CI/CD pipelines, and external applications. Because these secrets are static and frequently shared across teams, they represent a massive exfiltration risk. Moving toward Entra Workload Identity Federation, Azure’s newer OIDC-based framework, allows organizations to transition these high-risk traditional service principals to the same keyless, short-lived model championed by AWS and GCP.
5. CI/CD Pipeline Credentials
CI/CD platforms act as a powerful but hidden identity layer. GitHub Actions secrets and OIDC tokens, GitLab CI variables, and Jenkins credentials live in pipeline configuration, not IAM consoles. Because of this, they are excluded from most NHI inventories.
Why NHIs carry a different risk profile than human accounts
Human accounts get MFA, password rotation prompts, session timeouts, and behavioral baselines. NHIs get none of that. The difference is architectural, not a configuration gap.
When an attacker steals an API key or service account token, they can use it immediately. There is no second factor to bypass, session to hijack, or login anomaly to trigger. Revocation is possible only if you know the credential was compromised. But most organizations only detect NHI compromise after data has already moved.
Traditional user and entity behavior analytics (UEBA) tools were built around the chaotic nature of human access patterns, monitoring variables like login times or geographic shifts. But because non-human identities don't keep standard working hours, a machine account executing 10,000 API calls at 3 AM looks entirely legitimate to legacy systems. The real challenge isn't that NHIs lack a behavioral baseline, it's that their true baselines are highly deterministic. While a human’s schedule changes, a legitimate machine identity performs the exact same narrow set of API calls from the exact same network blocks. Attackers exploit this by blending into legitimate programmatic traffic, knowing that legacy tools won't flag a compromise until the NHI deviates drastically from its static, intended function.
Cloud security posture management (CSPM) addresses misconfiguration at the infrastructure level. But excessive permissions on a service account is an entitlement problem. The 2025 State of NHIs and Secrets report found that 97% of non-human identities have excessive privileges. This happens because NHIs are built too broad from the start, are never audited down, and have no real owner tracking them.
Ownership metadata for NHIs is often missing, incomplete, or not maintained. The engineer who created a service account two years ago may have left the company. No HR offboarding workflow catches a machine identity. The NHI simply persists with its original permissions, indefinitely.
Third-party exposure amplifies all of these gaps simultaneously: 92% of organizations expose NHIs to third parties, per the State of NHIs and Secrets report. Every SaaS integration that receives an API key or OAuth token extends the attack surface beyond perimeter controls. The organization can’t enforce rotation on a key it handed to an external vendor. And it can’t monitor behavioral anomalies in the vendor's environment.
An overprivileged NHI exposed to a third party, with no behavioral baseline or ownership tracking, produces an attack path that looks like normal traffic until data is gone.
Securing Modern AI Applications with Wiz AI-APP: From Code to Runtime
See how to outpace rapid AI-generated code and eliminate the blind spots created by interconnected models, agents, and cloud data before they turn into "toxic combinations" of risk.
What a compromised NHI enables
A compromised NHI allows an attacker to access connected cloud resources automatically, without needing to bypass a human login or a second factor.
Software vulnerability exploits are now the number one way attackers break into systems, driving 31% of data breaches according to the 2026 Verizon Data Breach Investigations Report (DBIR). But cloud credential abuse has simply moved to the second act of the attack chain, remaining a pervasive execution technique present in 39% of all breaches overall. Machine identities make that 39% uniquely risky because automated access patterns don’t trigger standard security alerts built for human accounts.. With the average breach now costing $4.4M, these findings highlight why credential compromise remains one of the most significant risks organizations face today.
Consider a Kubernetes pod compromised via an application vulnerability or container escape. If that pod runs with a service account carrying broad IAM permissions, the attacker gains cloud-level access without ever touching the control plane directly. From inside the pod, they can enumerate S3 buckets, access Secrets Manager entries, describe EC2 instances, and pivot to other services.
This is a common attack path in Kubernetes environments where service accounts are granted excessive permissions beyond what the workload requires. Applying container security best practices, including scoping service accounts to least privilege before deploying workloads, directly limits this blast radius.
CI/CD pipeline credentials enable a different attack path. When a pipeline secret is exfiltrated through a supply chain attack or a misconfigured pipeline job, the attacker gains whatever cloud access that credential was granted. Pipeline tokens are frequently scoped with broad permissions, rarely rotated, and often carry write access to production deployment targets or secrets storage. The structural reason these attacks succeed is that pipeline credentials are almost never scoped to the minimum a specific pipeline run actually requires.
The attacker's advantage in both scenarios is the same: NHIs have no behavioral baseline, so the access looks identical to legitimate workload traffic.
The NHI sprawl problem: Why your inventory is probably wrong
Most NHI inventories are structurally incomplete. For example, a tool like Terraform provisions a service account, a developer adds a GitHub Actions secret, or a CI/CD job creates an IAM role. None of these actions trigger an ownership request, approval, or offboarding procedure.
These accounts hide in places that make them hard to see:
AWS IAM roles: These are often invisible unless you use specific filters for each service or resource type.
GCP service accounts: Their keys are often absent from standard IAM reports unless you query the key inventory API directly.
GitHub Actions secrets: These live completely outside cloud IAM.
Kubernetes service accounts: Kubernetes service accounts persist even after the workloads they were created for are deleted. While modern bound tokens expire when a pod dies, the underlying ServiceAccount remains an open structural hazard, ready to be mounted by a new or compromised workload."
Third-party apps: SaaS OAuth tokens issued during an integration setup two years ago will not show up in your cloud IAM console or your company identity provider.
Leftover credentials and external exposure
Stale credentials often last longer than the work they were made to do. A workload is terminated, but its service account and permissions remain active. There is no machine-identity equivalent of an HR offboarding workflow. These "ghost credentials" carry full permissions against resources they were originally granted, waiting to be discovered by an attacker scanning for callable service accounts with broad entitlements.
This is why understanding vulnerability management for identities, including stale credential detection, is just as important as patch-based vulnerability programs.
Third-party exposure turns each of those ghost credentials into an external attack surface. As noted above, most companies have never been able to get an accurate inventory count. To find every account, you have to connect signals across AWS IAM, GCP IAM, Azure Entra, Kubernetes, pipeline credential stores, and third-party SaaS.
How to reduce NHI risk in your environment
You can reduce NHI risk with these five actions: Build the cross-environment inventory, apply least privilege, replace long-lived credentials with OIDC tokens, clean up stale NHIs, and embed governance in CI/CD. Inventory is the gate.
1. Build the cross-environment inventory
Discovering NHIs across all entitlement stores means querying AWS IAM roles and access keys, GCP service accounts and keys, Azure Managed Identities and Entra service principals, Kubernetes service account bindings, pipeline credential stores (GitHub Actions, GitLab CI, Jenkins), and third-party SaaS OAuth token grants.
Automation creates new NHIs continuously; this means the inventory process must run continuously, not quarterly.
2. Apply least privilege to machine identities
Scope IAM roles, service account bindings, and pipeline permissions to the minimum required for the specific workload. Scope by action (not resource class), by environment (dev permissions should never reach production), and by workload (a shared IAM role across multiple services invites lateral movement).
As mentioned, Excessive permissions are one of the most common NHI security issues. Start with the identities that have write access to production resources or access to secrets storage, where the potential impact of compromise is highest.
3. Replace long-lived credentials with OIDC-based short-lived tokens
All three major cloud providers now recommend this explicitly:
AWS OIDC federation for CI/CD pipelines enables workloads to obtain short-lived IAM credentials without storing long-lived access keys.
GCP Workload Identity Federation and GKE Workload Identity allow workloads access without using long-lived service account keys. Instead, they rely on short-lived credentials.
Azure Managed Identities and Federated Identity Credentials allow workloads to authenticate without storing secrets or long-lived credentials.
The convergence across AWS, GCP, and Azure demonstrates broad industry alignment around a simple principle: "No keys, no secrets."
4. Identify and clean up stale NHIs
Review credentials that haven't been authenticated in 30, 60, or 90 days. Decommission service accounts with no bound resources, workload identities where the workload no longer exists, and API keys that haven’t been called in months.
5. Embed NHI governance in CI/CD
Catch credentials before they reach production by using secrets scanning in pull request checks. Enforce OIDC token scoping at the pipeline configuration level to ensure pipeline runs don’t exceed their minimum required permissions. Tagging every service account with an owner in your IaC templates builds the clear record you need for future audits.
How Wiz approaches NHI security
Wiz CIEM delivers agentless discovery across AWS IAM, GCP IAM, Azure Entra, Kubernetes, and pipeline credential stores. It leaves zero coverage gaps for ephemeral workloads that spin up and disappear before an agent-based scanner can even register them.
Once the inventory is built, the Wiz NHI Dashboard surfaces the operational triage view. This identifies which NHIs exist, carry excessive privileges, are stale, and are exposed to third parties. Remediation queues are ordered by actual risk impact, not credential count.
The Wiz Security Graph connects that inventory to the rest of your cloud environment, mapping each NHI's permissions to the resources it can reach. If a credential is compromised, it surfaces the blast radius. It flags combinations that represent real attack paths (e.g., an overprivileged service account with a public exposure and a lateral movement path to a sensitive data store). You get context-driven ranking applied to identity and cloud risk.
NHIs are the largest and least-visible identity risk surface in most cloud environments. Security engineers own the inventory and entitlement work. DevOps engineers own the pipeline governance. The attack paths exist in both domains simultaneously, as does the responsibility for closing them. Start with the inventory, follow the blast radius, and work backward from there.
See where your current machine identity footprint and permission boundaries stand. Get a personalized demo.
See how AI-APP connects the full stack
Experience Wiz's unified security graph mapping code, cloud, and runtime for your AI workloads.
