TL;DR: Non-human identities are made up of consumers, secrets, and entitlements, and the security failure usually appears when those three pieces are managed separately rather than as one governance problem, according to Entro Security. The real issue is not just credential exposure, but the access path and blast radius that follow it.
At a glance
What this is: This is a framework for understanding non-human identities as the combination of consumers, secrets, and entitlements, with the key finding that risk concentrates where those elements are managed in silos.
Why it matters: It matters because IAM teams cannot govern AI agents, workloads, and service accounts effectively if they only track credentials and ignore the identity’s permissions and runtime context.
By the numbers:
- Non-human identities outnumber human identities in organizations by 92:1.
👉 Read Entro Security's blog on the three elements of non-human identities
Context
Non-human identity governance breaks down when teams treat the workload, its credential, and its permissions as separate problems. In practice, a service account, API key, or AI agent only becomes risky when its secret and entitlements are broad enough to turn ordinary automation into unauthorized access. That is the core NHI governance gap this article points to.
The article frames NHIs as the combination of consumers, secrets, and entitlements, which is a useful way to think about machine access in cloud, SaaS, and AI environments. For practitioners, the important point is that least privilege is not a static policy decision. It has to follow the identity across creation, use, rotation, and revocation, or the access path remains open long after the original use case changes.
Key questions
Q: How should security teams govern non-human identities across cloud and AI systems?
A: Security teams should govern non-human identities as a lifecycle, not a set of separate controls. That means inventorying the workload, the credential, and the permissions together, then reviewing creation, rotation, revocation, and access scope on a recurring basis. The goal is to shrink blast radius and prevent stale access from surviving after the original use case changes.
Q: Why do secrets alone not solve non-human identity risk?
A: Secrets only prove that an identity is allowed to authenticate. They do not define what that identity can do once it is inside. If entitlements remain broad or stale, a protected secret can still enable overreach. Effective control requires secrets management plus permission review and ownership of the underlying workload.
Q: What is the difference between a non-human identity secret and an entitlement?
A: A secret is the credential that authenticates the consumer, such as an API key, token, or certificate. An entitlement is the permission set that determines what the identity can access or modify after authentication. In practice, a secure secret with excessive entitlements is still dangerous because the authorization layer remains too wide.
Q: When should organisations prioritise entitlement reduction over secret rotation?
A: Organisations should prioritise entitlement reduction whenever a workload has broad, inherited, or rarely used permissions. Rotating a secret does not reduce the damage an attacker can do if the identity still has excessive access. Removing unused rights first usually delivers faster risk reduction than changing credentials alone.
Technical breakdown
Consumers, secrets, and entitlements as one identity chain
A non-human identity is not just a credential. It is a chain made up of the consumer that performs the action, the secret that proves identity, and the entitlements that define scope. If any one of those links is too broad, compromise becomes easier and blast radius grows. In cloud and GenAI workflows, the consumer might be a service, pipeline, or agent; the secret authenticates it; the entitlement layer determines what resources it can reach. Security failures often start when the secret is protected but the permissions remain excessive.
Practical implication: Map every NHI to its workload, credential, and permission set before attempting cleanup.
Why secrets are only one part of NHI exposure
Secrets are the proof-of-identity layer, but they do not define authority. A valid API key, token, or certificate can authenticate a workload while still leaving the underlying access model unsafe if the attached role is too broad or stale. That is why secret rotation alone is incomplete. If the same identity keeps the same rights, an attacker who captures a fresh secret can still operate with the same excessive privilege. NHI defense has to combine discovery, rotation, and entitlement review.
Practical implication: Pair secret hygiene with access review so rotated credentials do not preserve unsafe authorization.
Entitlements determine blast radius in cloud and agentic AI
Entitlements are where machine identity risk becomes operational. In AWS, Azure, and similar environments, permissions can accumulate as applications evolve, integrations multiply, and teams reuse existing roles. That creates latent blast radius even when the workload itself looks routine. For AI agents, the problem is sharper because the agent can chain tools and act dynamically. The key technical question is not whether the identity can authenticate, but what it can do after authentication and how far that action can propagate.
Practical implication: Treat entitlement scope as the primary control variable when assessing NHI and agent risk.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- 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
The consumer, secret, and entitlement triad is the right model for NHI governance, but most programs still only manage one corner of it. Credential vaulting without permission governance leaves blast radius intact. Permission reviews without inventory leave unknown identities active. A durable NHI program has to govern the identity as a lifecycle, not as a collection of disconnected controls.
Identity sprawl is now a structural governance problem, not a hygiene issue. When machine identities outnumber humans by 92:1, manual review cannot keep up with creation, reuse, and privilege drift. That scale pushes NHI control toward continuous discovery, policy enforcement, and lifecycle automation. The practical conclusion is straightforward: if the inventory is incomplete, the control plane is incomplete.
Entitlements are the most important part of the risk equation because they define the attacker’s usable reach. A stolen secret matters, but a broad role or stale policy turns that secret into a systems-level incident. This is why NHI governance should prioritise privilege reduction, not just credential protection. The program should measure how much access an identity really has, not how securely the secret is stored.
Agentic systems intensify the NHI problem because their behaviour is dynamic while their authorisation often is not. Traditional IAM assumes relatively stable subjects and predictable use cases. AI agents and automation pipelines break that assumption by creating short-lived, tool-rich, and context-sensitive access patterns. The field now needs governance models that follow runtime behaviour, not just static identity records.
Consumer, secret, and entitlement review should become a recurring operating discipline, not a one-time project. The article’s model is useful precisely because it can be operationalised across onboarding, access review, rotation, and decommissioning. Teams that treat it as a lifecycle control will reduce hidden access faster than teams that only chase leaked credentials.
From our research:
- 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, 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, according to The State of Secrets Sprawl 2026.
- For lifecycle control, the Ultimate Guide to NHIs , What are Non-Human Identities explains how service accounts, API keys, and workload identities should be inventoried and governed together.
What this signals
Ephemeral access does not remove governance debt: as AI systems and automation pipelines proliferate, security teams need controls that follow the identity across runtime use, not just the credential at rest. The practical shift is toward continuous discovery, entitlement review, and ownership mapping before access becomes unmanageable.
With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the access surface is already extending into new integration points that many identity programmes did not design for. Teams that align NHI controls with the NIST Cybersecurity Framework 2.0 and the NIST AI Risk Management Framework will be better positioned to govern these emerging paths.
The next programme priority is to connect machine identity inventory to privilege measurement. That means linking Top 10 NHI Issues to day-to-day access reviews so over-permissioned identities are removed before they become incident paths.
For practitioners
- Inventory every non-human identity as a full chain Record the workload or service that acts as the consumer, the secret used to authenticate it, and the entitlements attached to that identity. Do this across cloud, SaaS, CI/CD, and AI agent environments so ownership is clear.
- Reduce entitlements before you rotate secrets Review whether each service account, token, or role still needs its current permissions, then remove unused access before changing credentials. That sequence cuts blast radius faster than rotation alone.
- Tie secret lifecycle controls to access reviews Set a recurring review for creation, rotation, expiration, and revocation so a secret does not outlive the workload or business process it supports. Link that review to entitlement validation and asset ownership.
- Track AI agents as governed non-human identities Assign each agent an owner, a bounded permission set, and explicit tool access, then monitor whether its runtime actions exceed that scope. Treat agent autonomy as a governance input, not an exception.
Key takeaways
- Non-human identities should be governed as a three-part chain of consumer, secret, and entitlement, not as isolated credentials.
- Scale is the forcing function here, because machine identities now create far more review burden than manual IAM processes can absorb.
- The fastest risk reduction comes from reducing permissions, mapping ownership, and tying secret lifecycle controls to entitlement review.
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-03 | Secret exposure and over-permissioned identities are central to this article. |
| NIST CSF 2.0 | PR.AC-4 | The piece focuses on access control and privilege scope for machine identities. |
| NIST Zero Trust (SP 800-207) | The article's identity-plus-authorization model fits continuous verification for machine access. |
Apply zero-trust principles so each NHI is continuously authenticated and authorised at runtime.
Key terms
- Non-Human Identity: A non-human identity is a machine credentialed entity such as a service account, API key, token, certificate, workload, or AI agent. It authenticates software or automation so it can access systems and data. Governance has to cover its creation, usage, privilege scope, and retirement.
- Secret: A secret is the credential used to prove a non-human identity is allowed to authenticate, such as an API key, token, password, or certificate. It is only one part of the access chain. If the secret is valid but the attached permissions are broad, the identity still creates significant risk.
- Entitlement: An entitlement is the permission set that defines what a non-human identity can access or change after it authenticates. It includes roles, policies, and scoped privileges across cloud and application systems. In practice, entitlement drift is often what turns a routine identity into an incident path.
What's in the full article
Entro Security's full blog covers the operational detail this post intentionally leaves for the source:
- Platform-specific examples of how AWS, Azure, and OpenAI identities map to the consumer, secret, and entitlement model
- The article's visual breakdowns and metaphors showing how each element behaves in a real workflow
- Vendor-specific platform messaging about unified discovery, correlation, and detection workflows
- The step-by-step examples of how the vendor positions its tooling against over-permissioned NHIs
Deepen your knowledge
Consumers, secrets, and entitlements are core themes in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is formalising machine identity governance from this starting point, the course provides a practical baseline.
Published by the NHIMG editorial team on 2025-03-31.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org