TL;DR: The OWASP NHI Top 10 formalises the core failure modes behind machine identity exposure, from improper offboarding and secret leakage to overprivilege, third-party trust, and insecure cloud deployment, according to Unosecur. The category now demands lifecycle governance, not just inventory, because NHIs create broad attack paths when they are unmanaged, long-lived, or reused.
At a glance
What this is: This is an analysis of the OWASP NHI Top 10 and its key claim that machine identities now form a major, under-governed attack surface.
Why it matters: For IAM and NHI practitioners, it reframes machine identity risk as a governance problem that spans discovery, lifecycle control, and privilege scope.
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
👉 Read Unosecur's analysis of the OWASP NHI Top 10 and machine identity risk
Context
Machine identity risk is the security gap that appears when service accounts, API keys, OAuth apps, tokens, and workload identities expand faster than governance. In practice, these identities are often created for speed, then left with broad access, weak ownership, and limited monitoring. The primary keyword here is non-human identities, and the problem is that existing IAM controls were built around people, not autonomous systems and machine-to-machine trust chains.
The article argues that the OWASP NHI Top 10 gives teams a structured way to think about this sprawl. That matters because machine identities are not a niche edge case. They are embedded in CI/CD, cloud deployments, SaaS integrations, and automated operations. For teams building an NHI programme, this is a useful frame because it shifts the discussion from isolated secret leaks to lifecycle governance, privilege scope, and cross-environment trust.
The source examples are typical of the broader market, not unusual outliers. Stale accounts, leaked credentials, overprivileged tokens, and weak third-party controls are recurring patterns across modern cloud estates, which is why the framework has practitioner relevance beyond the specific incidents named in the post.
Key questions
Q: How should teams govern non-human identities in cloud environments?
A: Start by assigning every machine identity an owner, purpose, privilege boundary, and expiry. Then automate discovery, secret rotation, and offboarding across cloud, SaaS, and CI/CD. The goal is not just inventory. It is continuous lifecycle control so machine access cannot outlive the business need that created it.
Q: What is the difference between human identity governance and NHI governance?
A: Human identity governance centers on people, sessions, and authentication factors. NHI governance centers on credentials, workload trust, automation paths, and lifecycle events that often occur without user interaction. Machines need stronger expiry, revocation, and scope control because they can authenticate continuously and at machine speed.
Q: Why do long-lived secrets create more risk for machine identities?
A: Long-lived secrets turn a one-time exposure into persistent access. If a token or key stays valid for months, an attacker can reuse it quietly, often without triggering human-centric controls. That is why rotation alone is not enough unless revocation, ownership, and validation are automated.
Q: Should organisations prioritise secret scanning or privilege reduction first?
A: They should do both, but privilege reduction usually lowers risk faster because it shrinks blast radius before every leak is fixed. Secret scanning finds exposure. Least privilege limits what an exposed credential can do. Mature programmes pair the two so discovery does not outpace containment.
Technical breakdown
Why NHI sprawl becomes a governance failure
Non-human identities proliferate because modern systems create them automatically and use them continuously. A single application may rely on several service accounts, cloud roles, API keys, and OAuth grants, each with its own lifecycle and risk profile. The technical problem is not only quantity but fragmentation: credentials live in code, vaults, pipelines, and SaaS platforms, while ownership is often unclear. That creates a governance gap where no single control point can answer basic questions about purpose, expiry, or privilege.
Practical implication: Practitioners should treat NHI discovery and ownership assignment as a continuous control, not a one-time inventory project.
How secret leakage and long-lived tokens turn into durable access
Secrets are credentials, not just sensitive data. When an API key or token is exposed, the attacker often gets direct authentication capability rather than a need to bypass controls. Long-lived secrets make this worse because they remain valid long after exposure, and many systems lack binding to device, workload, or context. In practice, this means a leak in a repository, log, chat thread, or CI/CD file can translate into persistent cloud access unless revocation is automated and immediate.
Practical implication: Security teams need rotation, revocation, and secret-scanning workflows that are tied to ownership and expiry, not manual cleanup.
Why overprivilege and trust-chain weakness expand blast radius
Machine identities are frequently granted more access than human users because automation has to keep working. That convenience becomes risk when the same identity can reach production, pull data, trigger deployments, or assume additional roles. Trust chains across third parties, cloud roles, and pipelines magnify that exposure because one compromised identity can impersonate a trusted workflow. The result is a blast radius problem, not just an authentication problem: compromise of one machine account can become compromise of an environment.
Practical implication: Teams should map privilege to task scope and isolate trust relationships so one identity cannot traverse multiple environments or vendors.
Threat narrative
Attacker objective: The objective is durable programmatic access that bypasses human authentication controls and gives the attacker repeatable entry into critical systems.
- Entry occurs through a forgotten service account, leaked API key, or overprivileged OAuth app that still authenticates successfully.
- Escalation follows when the compromised NHI has broad permissions, enabling access to cloud roles, CI/CD workflows, or internal mailboxes.
- Impact is achieved when the attacker uses machine trust to move laterally, exfiltrate data, or persist inside automated infrastructure.
Breaches seen in the wild
- Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OWASP NHI works because it turns a vague sprawl problem into a control problem. Most enterprises already know they have machine identities everywhere, but they lack a shared model for classifying risk. A structured top 10 helps teams separate lifecycle failures, credential failures, and privilege failures so remediation can be prioritised. The discipline now is not counting identities for its own sake, but mapping where governance actually breaks down.
Identity blast radius is the right concept for machine identity risk. When a service account or token is reused across pipelines, clouds, or third parties, compromise no longer stays local. The access path becomes wider than the original workload, which means containment has to start with privilege design. Practitioners should think in terms of how far one machine credential can travel before they design controls.
Secret visibility without revocation is not a control strategy. Discovery matters, but exposed secrets remain dangerous if they are still valid. The operational lesson is straightforward: scan, correlate, revoke, and confirm expiry. Teams that stop at detection are documenting exposure, not reducing it.
Third-party NHIs are now part of the trust boundary, whether teams like it or not. SaaS integrations, cloud roles, and external automation all create machine identities that can outlive the original business need. That means vendor governance, contract review, and technical access review must be connected. Practitioners should assume third-party machine trust is an ingress path until proven otherwise.
OWASP NHI is also a signal that IAM for machines needs lifecycle parity with human identity. Human identity programs already understand joiner, mover, leaver, access review, and conditional access. Machine identity programs need equivalent rigor for issuance, rotation, attestation, expiry, and offboarding. The field is moving toward lifecycle governance as the baseline, and practitioners should build to that standard now.
From our research:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
- For the lifecycle and offboarding angle, see the Ultimate Guide to NHIs , What are Non-Human Identities for the identity classes that need continuous control.
What this signals
Identity blast radius is becoming the practical metric that matters most. With 70% of organisations granting AI systems more access than they would give a human employee performing the same job, the governance problem is already structural rather than theoretical. The teams that will cope best are the ones designing machine privilege around task scope, environment separation, and revocation speed rather than static role assumptions.
NHI programmes should now be built as lifecycle systems, not just control inventories. Discovery, ownership, rotation, and offboarding need to connect to cloud IAM, secrets management, and CI/CD automation so that one stale token cannot survive operational drift. That is the gap the OWASP NHI Top 10 helps expose, and it is the gap practitioners need to close before audit season forces the issue.
For practitioners
- Implement continuous NHI discovery Build an inventory that covers service accounts, API keys, OAuth grants, certificates, and workload identities across cloud, SaaS, and CI/CD. Tie each identity to an owner, purpose, and expiry date so governance can survive team turnover.
- Automate secret revocation and rotation Treat every exposed secret as a live credential until confirmed revoked. Connect scanning, ticketing, and rotation workflows so leaked values in code, logs, chat, or pipelines are removed quickly and repeatedly.
- Reduce privilege to task scope Replace broad machine permissions with narrowly scoped roles, separated by environment and function. A token that can deploy code should not also read production data or assume unrelated cloud roles.
- Review third-party machine trust paths Map every SaaS integration and external automation to the identity it uses, the permissions it holds, and the data it can reach. Reassess those paths when business purpose changes or vendors change their architecture.
Key takeaways
- Machine identity risk is now a governance problem, not a niche credential-management issue.
- Long-lived secrets and overprivileged tokens create durable attacker access that scales with automation.
- Practitioners need continuous discovery, revocation, and least privilege if they want NHI controls to hold up under real-world use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret leakage and leaked credentials are central to this article. |
| NIST CSF 2.0 | PR.AC-4 | Machine access scope and entitlement review align to this control. |
| NIST Zero Trust (SP 800-207) | Zero trust assumptions apply to machine-to-machine authentication paths. |
Map every NHI to least-privilege entitlements and review access on a set cadence.
Key terms
- Non-Human Identity: A non-human identity is any digital identity used by software, services, workloads, or automation instead of a person. It includes service accounts, API keys, OAuth applications, certificates, bots, and AI agents. These identities often authenticate continuously and need tighter lifecycle control than human accounts.
- Identity Blast Radius: Identity blast radius is the amount of access an identity can reach if it is compromised. For machine identities, the blast radius can span multiple clouds, pipelines, and data systems because credentials are often reused, overprivileged, or trusted by other automation.
- Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, logs, chats, pipelines, and configuration files. It increases the chance that valid tokens remain hidden, reused, or exposed long after creation. Good governance pairs discovery with automated revocation and ownership tracking.
- Lifecycle Governance: Lifecycle governance is the control of identity issuance, use, rotation, expiry, and removal from start to finish. For NHIs, it is the difference between a credential that exists somewhere and one that is actually governed throughout its operational life.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- How the vendor maps each OWASP NHI risk to real-world incidents such as Midnight Blizzard, CircleCI, and Snowflake.
- The specific discovery and lifecycle automation workflow used to correlate machine identities across AWS, Azure, GCP, and SaaS.
- Behavior-based detection ideas for dormant key activation, machine impersonation, and unusual cross-environment activity.
- The vendor's own benchmarking and reporting approach for scoring NHI resilience against the OWASP framework.
Deepen your knowledge
OWASP NHI Top 10 analysis is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building machine identity governance from the ground up, it is worth exploring.
Published by the NHIMG editorial team on 2025-12-01.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org