Non-human identities (NHIs), including software workloads, AI agents and service accounts, and their associated credentials vastly outnumber human identities in most environments. Research from Entro Security puts the ratio at 144 non-human identities for every human user, yet security programs still focus primarily on users.
While attackers still exploit human identity gaps, at least rules govern them: accountability, governance and enforcement. The same cannot always be said for NHIs.
For example, when a developer leaves a company, their access is revoked. But when an old API key is left behind in a repository, it often remains valid indefinitely. Service accounts frequently hold far more privilege than necessary, and automated workloads often authenticate with static secrets that never expire. GitGuardian’s 2026 report on secrets sprawl found that nearly 29 million new hardcoded secrets were exposed on public GitHub in 2025 alone, a 34% year-over-year increase, and that 64% of secrets exposed as far back as 2022 remained valid in early 2026.
To address this growing threat, OWASP released the first-ever NHI Top 10, an awareness document for identifying and mitigating the biggest risks associated with non-human identities.
The following breakdown draws on Aembit Principal Solutions Architect Andrew McCormick’s presentation at NHIcon 2025, with breach examples and solutions to mitigate each risk.
OWASP NHI Top 10: A Breakdown
1) Improper Offboarding: Forgotten Credentials That Never Expire
When workloads and services are retired, their associated credentials often remain active. Attackers look for these orphaned API keys and abandoned service accounts because they provide access without triggering alerts.
Example: Attackers gained access to the Internet Archive’s systems after an access token, exposed in a GitLab repository for 22 months, was exploited. They exfiltrated 7 terabytes of data, including long-lived Zendesk credentials that were later used for further compromise.
- Automate identity lifecycle management to ensure that NHIs are properly offboarded when no longer in use.
- Use ephemeral credentials. Replace long-lived secrets with short-lived tokens that automatically expire.
- Regularly audit non-human identities to identify and remove unused NHIs before attackers find them.
2) Secret Leakage: API Keys and Credentials in the Wrong Hands
Unlike user passwords, API keys and service account credentials don’t have MFA. If they leak, attackers can use them immediately. Secrets often end up in public repositories, logs or internal documentation.
Example: The New York Times breach started when a GitHub token was leaked publicly. Attackers used it to access repositories containing hundreds of secrets and user data.
- Replace static credentials with identity-based authentication using identity federation instead of API keys.
- Automate secret scanning to regularly scan repositories and infrastructure for exposed secrets.
- Enforce least privilege access by scoping API keys and service accounts to only what they need.
3) Vulnerable Third-Party NHIs: The Supply Chain Weak Link
Third-party integrations connect developer tools, cloud services and SaaS platforms. If a vendor is breached, their service account credentials and tokens can be stolen and used to access your systems.
Example: The Cloudflare breach was triggered by an earlier Okta compromise, where attackers stole service account credentials. Cloudflare rotated thousands of credentials afterward but missed one service token and three service accounts. Those four unrotated credentials allowed the attackers to access internal Atlassian systems weeks later.
- Adopt workload identity federation to replace static API keys with dynamic, short-lived credentials.
- Continuously monitor third-party access to detect anomalies in vendor behavior before they become breaches.
- Limit third-party permissions by granting only necessary access and removing it when no longer required.
4) Insecure Authentication: Weak or Nonexistent Safeguards
Many APIs still rely on static API keys and non-standard authentication methods. Attackers can exploit these with minimal effort.
Example: In mid-2024, Hugging Face detected unauthorized access to its Spaces platform. The company suspected that a subset of Spaces secrets may have been accessed, and it revoked affected tokens as a precaution.
- Adopt modern standards such as OAuth, OpenID Connect and mutual Transport Layer Security (TLS) instead of static API keys.
- Deprecate weak authentication methods by removing long-lived tokens and enforcing secure authentication flows.
- Audit API authentication by regularly reviewing API security configurations.
5) Overprivileged NHIs: Excessive Permissions That Expand Blast Radius
Developers and administrators frequently assign NHIs far more permissions than their function requires. When one of these overprivileged identities is compromised, attackers can access sensitive data, escalate privileges and move laterally across the network. Orca Security research found that 53% of organizations grant privileged access to more than 10% of their cloud roles, and that only 55% of policy permissions assigned to active AWS IAM roles are actually utilized.
- Enforce the principle of least privilege by scoping every NHI to only the permissions its function requires.
- Regularly audit and right-size NHI permissions. Flag service accounts and OAuth apps that exceed their operational scope.
- Use just-in-time access to grant elevated privileges only when needed and automatically revoke them afterward.
6) Insecure Cloud Deployment Configurations: Misconfigured Pipelines
CI/CD pipelines and cloud workloads require privileged access, but misconfigurations can expose excessive permissions.
Example: The Sisense breach occurred when attackers accessed GitLab repositories containing hardcoded AWS access keys. These credentials allowed exfiltration of customer data, including sensitive access tokens.
- Implement least privilege policies to restrict pipeline permissions to the minimum necessary.
- Remove hardcoded credentials from infrastructure code. Authenticate pipelines through verified workload identity rather than static secrets.
- Monitor and log CI/CD workflow activity to detect unauthorized access before it becomes a breach.
7) Long-Lived Secrets: Credentials That Never Rotate
Static credentials remain valid indefinitely. Even when organizations rotate credentials, attackers can still exploit them before rotation occurs.
Example: The U.S. Treasury Department breach stemmed from a BeyondTrust API key compromise. Attackers used it to steal sensitive documents from employee workstations.
- Issue short-lived, automatically expiring tokens instead of static secrets that persist across deployments.
- Automate credential rotation to reduce the risk of compromise by rotating secrets frequently.
- Store credentials securely using dedicated vaults instead of embedding credentials in code.
8) Environment Isolation Failures: Attackers Move From Dev to Prod
Organizations frequently reuse credentials across development, testing and production environments. If attackers breach a lower-security environment, they can escalate to production.
Example: The Midnight Blizzard attack on Microsoft started with a password-spraying attack on a legacy non-production test tenant account. Attackers then escalated privileges via a legacy OAuth application that had elevated access to the corporate environment.
- Use environment-specific identities with separate credentials for dev, test and production.
- Apply fine-grained access controls to restrict access to sensitive resources.
- Audit identities regularly to identify and remove credentials that are shared across environments.
9) NHI Reuse Across Systems: Breaking Least Privilege
Service accounts and API keys should be unique to each application. When NHIs are shared across multiple systems, it becomes impossible to enforce least privilege.
Example: The Imperva Cloud WAF breach occurred when a production database snapshot was used in a test environment. Sensitive customer data was exposed as a result.
- Assign unique NHIs per application to reduce the impact of a breach.
- Limit permissions based on function and enforce strict scoping of service accounts.
- Audit NHIs for overuse to identify credentials being used in multiple environments.
10) Human Use of NHIs: Admins Using Service Accounts as Shortcuts
IT teams sometimes use service accounts for convenience, bypassing security controls. This practice eliminates accountability and increases the risk of compromise.
Example: The CircleCI breach began when malware on an engineer’s laptop stole session cookies. These cookies were used to generate production workload credentials. The attackers exfiltrated data from customer environments.
- Enforce separation between human and non-human identities. Require developers and administrators to use their own credentials, not shared service accounts.
- Analyze non-human identity usage patterns to identify anomalous behavior that suggests human misuse of workload credentials.
- Educate engineering and security teams on the risks of using service accounts for human access.
OWASP NHI Top 10: A Security Framework for Compliance and Risk Reduction
The OWASP NHI Top 10 underscores a common oversight in security: non-human identities are often treated as fixed credentials rather than identities that require management and validation.
Attackers exploit this gap because traditional IAM solutions focus on human authentication. The identities that connect applications and services often receive weaker protections as a result.
Beyond security risks, regulatory and industry mandates like PCI DSS and NIST have increasingly prescriptive requirements for non-human identity governance. Many of the security failures outlined in the NHI Top 10, such as long-lived secrets, improper offboarding and overprivileged service accounts, map directly to these compliance requirements.
PCI DSS 4.0, whose future-dated requirements became mandatory on March 31, 2025, now requires organizations to manage and monitor all accounts, including non-human identities, enforce least privilege and periodically review access. The NHI Top 10 provides a framework to address these requirements, particularly around secrets leakage and service account sprawl.
The relevance of this framework has only grown since its release. OWASP’s Top 10 for Agentic Applications, published in late 2025, explicitly cross-maps to the NHI Top 10. It identifies overprivileged non-human identities, secret exposure and long-lived credentials as root causes and amplifiers of agentic AI risks. As AI agents become more autonomous, the non-human identities and secrets that power them carry even greater consequences when left unmanaged.
Organizations that implement these best practices will be better positioned to prevent breaches, pass audits and reduce overall business risk. Aembit provides workload IAM that replaces static secrets with identity-based, policy-driven access for the non-human identities your infrastructure depends on.
