Runtime authorization is the missing layer in NHI governance

At a glance

What this is: This article argues that NHI management is incomplete without runtime authorization, because discovery, rotation, and lifecycle controls do not answer whether a service should be allowed to act on a specific request.

Why it matters: IAM teams need to treat NHI authorization as a policy problem, not just a secrets problem, because the same overprivilege patterns now affect service accounts, workload identities, and AI-driven system access.

By the numbers:

• Non-human identities now outnumber human users in most organizations by roughly 17 to 1.
• Only 15% of organizations feel confident in their ability to secure NHIs, according to the NHI Management Group.
• 50% of surveyed organizations had a breach in the past year tied to compromised machine identities, with poorly scoped API keys, SSL/TLS certificates, and service account tokens as the most common vectors.

👉 Read Cerbos' article on runtime authorization for non-human identities

Context

NHI runtime authorization is the missing governance layer for service accounts, API keys, workload identities, and increasingly AI agents. The article's core point is simple: identity teams can discover credentials, rotate secrets, and assign ownership, yet still leave every request over-permitted if policy is not evaluated at execution time.

That gap matters because non-human identities behave differently from human users. They do not log in interactively, they rarely have a clear owner, and they are often granted broad permissions to keep pipelines and services moving. In that model, runtime policy becomes the only reliable way to answer whether the identity should be allowed to perform a specific action on a specific resource in the current context.

Key questions

Q: How should security teams implement runtime authorization for non-human identities?

A: Start by identifying the service-to-service requests that matter most, then enforce policy at the decision point rather than in application code. Each request should be evaluated against the principal, action, resource, and context. This gives teams a consistent way to apply least privilege to workload identities, API keys, and service accounts without relying on broad IAM roles.

Q: Why do non-human identities create more overprivilege risk than human users?

A: Because machine identities are often granted broad permissions to keep systems running, and those permissions persist even when the underlying workload only needs a narrow action set. Human IAM can depend on interaction and review cycles, but service accounts act continuously. That means a single over-scoped credential can expand the blast radius across multiple downstream systems.

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

A: Look for consistent allow and deny decisions at runtime, complete audit logs for each request, and fewer services that need code-level permission checks. If teams still rely on service-wide roles or cannot explain why a request was allowed, authorization is not being enforced tightly enough. The signal is decision precision, not credential rotation frequency.

Q: Should organisations treat workload identity frameworks as enough for NHI governance?

A: No. Workload identity improves authentication, but it does not decide whether a specific action should be allowed on a specific resource. Organisations need both strong identity proofing for machines and a policy layer that evaluates requests in context. Without that second layer, verified identities can still be overprivileged.

Technical breakdown

Why lifecycle controls do not solve runtime authorization

Discovery, inventory, rotation, and offboarding are governance controls, but they do not decide whether a request should be allowed in the moment. A service account can be well catalogued, rotated, and owned, yet still hold broad rights that exceed the action it is performing. The article's key technical point is that authorization must evaluate the principal, the action, the resource, and context every time. That is the difference between managing the credential and governing the decision.

Practical implication: pair NHI lifecycle controls with a policy engine that evaluates every request, not just every secret.

How policy-based access control applies to service-to-service requests

Policy-based access control centralises the decision logic that teams otherwise scatter across application code and infrastructure rules. In a non-human identity model, a service authenticates with a workload identity or secret, then sends the principal, resource, and action to a decision point. The policy engine returns allow or deny based on conditions such as trust domain, service identity, environment, and requested action. This is more precise than coarse service-level IAM roles because it narrows access to what the workload actually needs.

Practical implication: define policies at the action and resource level instead of granting blanket service-level permissions.

Why Zero Trust for NHIs requires contextual authorization

Zero Trust for machine identities is not just about verifying the credential once. It requires continuous, contextual evaluation of whether the identity is still allowed to act in that situation. Workload identity frameworks such as SPIFFE provide stronger authentication primitives, but they do not by themselves answer authorization questions. The runtime decision layer has to enforce least privilege on each request, and it has to log the reason for the decision so security and compliance teams can trace access later.

Practical implication: use workload identity for authentication, then enforce contextual allow and deny decisions with auditable policy checks.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Runtime authorization is the point where NHI governance becomes enforceable. Discovery and rotation help teams see and refresh machine identities, but they do not constrain what those identities can do at request time. Without a policy decision layer, the programme can catalog excess privilege without actually limiting it. The implication is that NHI control maturity should be measured by decision precision, not by inventory completeness.

Overprivileged access is the structural failure mode here, not secret hygiene alone. The article shows a familiar pattern: broad service-level permissions are easier to assign than action-level rules, so teams accept excess access to keep systems moving. That is how a valid credential becomes a wide blast radius. The relevant lens is OWASP-NHI and NIST Zero Trust, because least privilege has to be expressed as a runtime decision, not an entitlement assumption.

Service-account governance has now reached the same point human IAM reached years ago. Human programmes learned that authentication does not equal authorisation, and NHI programmes are now repeating that lesson at machine scale. The difference is volume and speed: service accounts, API tokens, and workload identities generate far more requests than human users ever will. Practitioners should treat NHI authorization as a separate control plane, not an extension of human access review.

Identity blast radius is the right named concept for this problem. A single over-scoped NHI can touch many downstream systems, so the real risk is not just compromise but the scope of what a valid credential can reach before anyone notices. That blast radius expands when permissions are granted at service level instead of action level. The practitioner conclusion is to govern reach, not just existence, when assessing machine identity risk.

SPIFFE-style authentication becomes incomplete without policy enforcement. Strong workload identity tells you what authenticated, but it does not tell you what should happen next. This is why machine identity programmes that stop at attestation and secret management leave the hardest question unresolved. The field should now treat authentication and authorisation as inseparable parts of NHI governance, with policy evaluation as the missing control.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most programmes still cannot govern machine identity sprawl end to end.
• For the lifecycle angle, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how ownership, rotation, and offboarding support runtime control.

What this signals

Identity blast radius will become a board-level NHI metric as more teams realise that discovery without runtime policy only measures inventory, not exposure. The governance question is shifting from how many machine identities exist to how far each one can reach before a deny decision intervenes. That is the operational boundary practitioners need to watch.

NHI programmes should expect stronger pressure to combine workload identity with externalized authorization, especially in service meshes, API gateways, and AI-assisted application tiers. The practical signal is simple: if a service can still make broad requests after rotation and review, the control plane is too coarse.

With 97% of NHIs carrying excessive privileges in the NHI Mgmt Group research cited across the field, the problem is not theoretical privilege creep but structural overreach. Teams should prepare for tighter policy enforcement, more granular audit expectations, and a clearer separation between authentication and authorisation.

For practitioners

• Map the highest-risk service-to-service flows first Start with the interactions that can reach customer data, payment systems, or production admin paths, then define the exact actions each workload needs rather than granting service-wide access.
• Move authorization decisions out of application code Centralize policy evaluation so teams stop duplicating if statements and ad hoc checks across services, which creates inconsistent access behaviour and uneven auditability.
• Require action-level policy rules for every sensitive resource Write allow conditions around the specific action, resource, identity, and context, then deny everything else by default so a valid secret cannot automatically imply broad access.

Key takeaways

• NHI governance is incomplete unless runtime authorization decides each request, not just each secret.
• Service-level permissions create a wide blast radius, which is why overprivilege is the central control failure.
• Teams should treat workload identity, policy enforcement, and auditability as one control chain rather than separate projects.

Key terms

• Non-Human Identity: A non-human identity is any credentialed software actor that accesses systems on behalf of a workload, integration, or automated process. It includes service accounts, API keys, tokens, certificates, and machine identities that need governance even though no person signs in directly.
• Runtime Authorization: Runtime authorization is the decision made at the moment of a request about whether a principal may act on a resource. In NHI environments, it is the missing control between authenticated identity and actual access, and it is what prevents valid credentials from implying unrestricted use.
• Workload Identity: Workload identity is the mechanism that proves a service, container, or workload is the caller without relying on human credentials. It is stronger than shared secrets, but it still needs policy enforcement to determine what that workload may do after it is authenticated.
• Identity Blast Radius: Identity blast radius is the scope of systems and data a single credential can reach if it is overprivileged or compromised. For non-human identities, it is often larger than teams expect because machine permissions are assigned for convenience and then reused across many downstream actions.

Deepen your knowledge

Runtime authorization for non-human identities is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy-based control for service accounts or workload identities, it is worth exploring.

This post draws on content published by Cerbos: runtime authorization for non-human identities. Read the original.