Non-human identity governance fails when authorization is missing

At a glance

What this is: The article argues that NHI security breaks down when teams stop at discovery and credential hygiene instead of governing what machine identities are actually allowed to do.

Why it matters: That matters because IAM, IGA, and PAM teams need runtime authorization models that work for NHIs, autonomous agents, and human access patterns, not just inventories and rotation schedules.

By the numbers:

• Non-human identities now outnumber human identities by 45:1 in the enterprise.
• 60% of NHI credentials are either stale or carry far more privilege than the workload requires.
• Around 31% of breaches involve stolen credentials.

👉 Read EnforceAuth's analysis of non-human identity authorization gaps

Context

Non-human identity governance is the discipline of controlling what service accounts, API keys, tokens, certificates, and AI agents can do once they are authenticated. In this article, the core failure is not discovery or rotation. It is the absence of fine-grained authorization for machine identities that act at runtime and can chain actions faster than a human reviewer can intervene.

That distinction matters because many IAM programmes still treat NHI work as an inventory problem. The article shows why that is incomplete: a clean spreadsheet can still leave a production database exposed to an agent that was never denied access in the first place. The primary keyword here is non-human identity governance, and the real control gap is authorization, not cataloguing.

Key questions

Q: What breaks when non-human identity programmes stop at discovery?

A: Discovery tells you what identities exist, but it does not govern what those identities can do. That leaves service accounts, API keys, tokens, and AI agents free to use valid credentials for excessive actions if authorization is coarse or missing. The control gap is runtime permissioning, not inventory quality.

Q: Why do non-human identities create more risk than human accounts in many environments?

A: NHIs often hold broader, longer-lived access than human users and can act at machine speed without intervention. If their permissions are static or overly broad, a single credential can expose multiple systems, datasets, or workflows. The risk is not the secret alone, but the blast radius attached to it.

Q: How do security teams know if NHI governance is actually working?

A: Look for evidence that access is scoped to specific actions, data, and contexts, not just that identities are inventoried and rotated. If you can describe every workload only in terms of ownership and expiry, the programme is still weak on authorization. Strong governance leaves a clear decision trail for each sensitive action.

Q: Who should own NHI authorization decisions in an enterprise?

A: Ownership should sit with the teams that control policy, identity governance, and application enforcement together. If security, platform, and application teams each assume another group handles the decision, over-privilege tends to persist. The practical test is whether someone can explain who approves each sensitive action and under what conditions.

Technical breakdown

Authentication is not authorization for NHIs

Authentication proves a workload, bot, or AI agent is presenting valid credentials. Authorization determines which actions that identity can perform after it is accepted. In NHI environments, teams often overfocus on key rotation, certificate validity, and inventory hygiene because those are visible lifecycle controls. But a valid secret can still unlock excessive access if the policy layer is coarse or missing. The risk rises sharply when the identity is persistent, widely scoped, or used by an AI agent that can change context across requests. Practical governance depends on binding permissions to action, resource, and context, not to the mere existence of an identity.

Practical implication: separate authentication hygiene from runtime authorization decisions, and review both as distinct controls.

Why RBAC breaks down for machine identities

Role-based access control works reasonably well when identities map to stable human job functions. It becomes blunt when the subject is a non-human workload that may change purpose, dataset, or execution path every few seconds. A static role cannot express whether an AI agent may read one record set, combine it with another, or write derived output back into a different system. That is why decision-centric models are becoming necessary for NHIs. The policy has to evaluate the actor, action, resource, and current context at the moment of access, rather than assuming the role assignment still fits the task.

Practical implication: move high-risk NHI decisions out of static role grants and into policy evaluation at request time.

Runtime policy enforcement for agentic workflows

When an AI agent can reason, call tools, and continue a workflow without human intervention, governance must operate at the pace of the session, not the pace of the access review cycle. The technical challenge is not just tool access, but the combination of tool chain, data path, and downstream consequence. If a policy only checks initial entry, the agent may still pivot into actions that were never intended for that context. Runtime enforcement closes that gap by evaluating each decision before the next action occurs. This is the point where NHI authorization becomes operational, not just documented.

Practical implication: require policy checks before each sensitive tool call, data read, or write action in agentic workflows.

Threat narrative

Attacker objective: The objective is to use legitimate NHI access to reach sensitive production data without triggering credential theft or obvious misconfiguration alerts.

1. Entry occurred through valid NHI credentials that authenticated successfully, so the system treated the actor as trusted.
2. Credential access was not the issue because the identity already held permissions, but those permissions were broader than the task required.
3. Impact followed when the AI agent queried a production database it had no business accessing, showing that authorized access can still be unsafe when scope is undefined.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Discovery is not governance: cataloguing NHIs, classifying them, and rotating their secrets solves identity visibility, but it does not answer what those identities are permitted to do at runtime. That is the gap the article exposes, and it is the gap most programmes still treat as optional. Practitioners should stop equating an inventory with control.

Decision-centric authorization is now the real NHI control plane: static roles cannot express context-sensitive machine behaviour, especially when AI agents chain multiple actions in one session. The article shows why policy must move from provisioning time to decision time, where actor, resource, and action can be evaluated together. IAM teams should re-centre their NHI strategy on runtime authorization.

Standing privilege creates an identity blast radius that inventory tools cannot see: the problem is not whether the secret exists, but whether the identity can touch data or systems far beyond its business purpose. This is the named concept to track because over-scoped access, not missing discovery, is what turns a managed identity into a breach path. Practitioners should measure blast radius, not just count identities.

NHI security maturity has been misread as lifecycle maturity: many organisations have improved discovery, classification, and decommissioning, yet still leave action-level permissions untouched. That breaks the assumption that lifecycle work automatically reduces exposure. The implication is straightforward: recertification without authorization review leaves the highest-risk behavior unchanged.

AI agents make the governance problem sharper, not newer: the article's strongest signal is that agentic behaviour collapses the old separation between identity and action. A machine identity that can decide, chain, and execute work needs governance that follows the decision path, not just the credential lifecycle. Security teams should treat agentic access as a distinct policy class, not a renamed service account.

From our research:

• 60% of NHI credentials are either stale or carry far more privilege than the workload requires, according to Top 10 NHI Issues.
• From our research: 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, according to Guide to the Secret Sprawl Challenge.
• From our research: For teams moving from discovery to enforcement, Ultimate Guide to NHIs , Static vs Dynamic Secrets explains why lifecycle hygiene does not close the authorization gap.

What this signals

Standing privilege is the next metric teams need to watch: once discovery is in place, the question becomes how much damage each identity can do if it acts exactly as provisioned but beyond business intent. The 60% over-privilege figure from Top 10 NHI Issues shows that the real problem is not identity count, but uncontrolled reach.

Authorisation models for NHIs are converging with zero-trust design, but only where policy can be evaluated at the point of action. That shift matters because auditability without decision enforcement is still post-event visibility, not prevention. Teams that keep treating NHIs as lifecycle objects will miss the operational control plane.

The practical signal for programmes is whether a machine identity can be asked to prove its business purpose at each sensitive step. If the answer is no, the environment still depends on trust in credentials rather than trust in decisions. That is where NHI governance and runtime policy management start to overlap.

For practitioners

• Map NHI access by action, not just by identity Inventory every service account, token, and agent against the specific actions and data paths it can touch. Replace system-level labels like read-only or admin with a task-level access map that shows what can actually happen in production.
• Separate authentication review from authorization review Keep credential rotation, ownership, and expiry checks in one workflow, and run a distinct review for the actions each identity can perform at runtime. A valid secret should never be treated as proof that the access scope is acceptable.
• Introduce policy checks at decision time for high-risk workflows For AI agents and other machine identities that can chain actions, enforce policy before each sensitive read, write, or tool call. If the access decision only happens once at the start of the session, the later actions remain effectively ungoverned.
• Recertify blast radius, not just ownership Use access reviews to ask what damage an identity can do if it behaves as designed but beyond business intent. Tie recertification to data sensitivity, cross-system reach, and downstream write permissions, not just to who owns the account.

Key takeaways

• The article shows that NHI governance fails when teams mistake discovery and secret hygiene for actual authorization control.
• The scale of the problem is visible in over-privilege and credential-breach data, which makes machine identity blast radius a board-level concern.
• The control that changes outcomes is runtime, action-level policy enforcement tied to what each identity is allowed to do right now.

Key terms

• Non-Human Identity: A non-human identity is any machine- or workload-based identity used to authenticate and access systems. That includes service accounts, API keys, tokens, certificates, bots, and AI agents. The governance problem is not simply knowing these identities exist, but controlling what they can do after authentication.
• Runtime Authorization: Runtime authorization is the act of deciding whether a specific request should be allowed at the moment it occurs. For NHIs, it matters because credentials can be valid while the requested action is still unsafe. The control must consider identity, action, resource, and context together.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. In NHI programmes, it increases blast radius because a valid credential can be reused for actions far outside the intended task. The longer the privilege persists, the more time there is for misuse or lateral movement.
• Decision-Centric Security: Decision-centric security shifts control from identity ownership to action-level approval. Rather than asking only who has the credential, it asks whether a specific action is authorized right now. For machine identities, this is the practical way to govern fast, context-changing access patterns.

Deepen your knowledge

NHI authorization and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is strong on discovery but weak on runtime decisions, this course is a useful next step.

This post draws on content published by EnforceAuth: non-human identity authorization and decision-centric security. Read the original.