Identity security in 2026 still breaks at runtime authorization

At a glance

What this is: This analysis frames identity security as a control plane problem and argues that runtime authorization, not login, is where modern identity programmes still break.

Why it matters: IAM, PAM, IGA, and NHI teams need to treat request-time authorization as a first-class control because static governance does not decide access in real time.

By the numbers:

• Machine identities are the fastest growing identity type, and 93% of organisations experienced two or more identity-related breaches in the prior year, according to CyberArk research cited by Cerbos.
• Enterprise agent deployments reached roughly 42% of large organisations actively deploying in just over a year, according to KPMG AI Pulse reporting cited by Cerbos.
• The human element was involved in 60% of breaches, and 88% of basic web application attacks involved stolen credentials, according to Verizon DBIR findings cited by Cerbos.
• The average breach cost reached $4.88 million, with compromised-credential breaches among the most expensive and slowest to contain, according to IBM research cited by Cerbos.

Context

Identity security has become the control plane for modern environments because the perimeter is no longer a reliable security boundary and access decisions now hinge on who or what is making the request. In practice that means identity security must cover humans, workloads, service accounts, and AI agents, with runtime authorization deciding whether each request is allowed.

The governance gap is that most programmes still spend their effort on admin-time controls such as provisioning, access reviews, and privileged access management. Those controls are necessary, but they do not answer the real-time question that modern systems face: should this principal be allowed to do this action on this resource right now?

That gap matters because the strongest identity programmes are no longer judged only by coverage or certification cadence. They are judged by whether policy can be evaluated continuously, outside application code, with enough context to make a defensible decision at the moment of access.

Key questions

Q: What breaks when authorization ignores the calling application?

A: When authorization ignores the calling application, the API cannot tell whether a request came from the right actor, in the right workflow, with the right purpose. That leads to over-permissioned integrations, unsafe delegated access, and policy decisions that look correct on paper but fail at runtime. Application identity must be part of the trust decision.

Q: Why do identity programmes need context-based access policies?

A: Because static roles cannot capture changing request conditions such as device, location, risk, resource sensitivity, or delegated context. Without those signals, the programme can only certify entitlement assignment, not the real-time decision that determines exposure.

Q: What are the signs that runtime authorization is failing?

A: Look for inconsistent access behaviour across services, repeated policy logic in code, slow manual change cycles when rules move, and decision logs that cannot explain allow or deny outcomes. Those are signs the authorization layer is not operating as a shared control.

Q: How should teams govern access when AI agents and service accounts share the same business systems?

A: Treat them as different identity subjects with the same governance obligation. Create one access model that covers ownership, entitlement scope, review cadence, and offboarding across human and non-human identities, then apply role-appropriate controls to each class. The goal is not separate programmes. It is one risk model that can follow access across systems and workflows.

Technical breakdown

Why runtime authorization is the control that decides access

Runtime authorization is the decision point that evaluates an identity, a requested action, the target resource, and current context before allowing or denying access. Unlike authentication, which proves identity, or IGA, which governs entitlement assignment, runtime authorization answers the question at the moment of use. In modern architectures, that decision should be externalised so it can be versioned, tested, audited, and enforced consistently across services. When it lives inside application code, policy drifts from one service to the next and changes require redeploying every caller. That creates a control-plane gap that is hard to audit and easy to bypass.

Practical implication: Move authorization decisions out of scattered application logic and into a dedicated runtime control layer.

Why static roles break down for NHI and agent access

Static RBAC is weak when the subject is a workload, service account, or AI agent because the principal’s risk changes with context, not just with role assignment. A service account may be valid in one service and dangerous in another, while an agent may inherit a user’s permissions but then chain into tool calls that were never intended at provisioning time. Runtime authorization can evaluate attributes, relationships, and request context on each call, which is essential when identities are non-human and delegation chains are dynamic. The problem is not only overprivilege; it is that the request path itself becomes fluid.

Practical implication: Treat NHI and agent access as request-scoped decisions, not fixed role assignments.

How identity fabric and externalized authorization fit together

An identity fabric separates identity data, policy, and enforcement so applications can ask a simple yes-or-no question without embedding business rules. The fabric model depends on open standards, central policy, and decentralized enforcement, which is why it pairs naturally with externalized authorization and structured decision logs. Those logs are not just compliance evidence. They are the signal source for ITDR, incident response, and control validation, because they show what was requested, what was allowed, and why. Without that layer, identity security remains partial: strong at provisioning, weak at decision time.

Practical implication: Instrument every authorization decision so policy, response, and audit teams can see the same evidence.

Breaches seen in the wild

• Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.

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 now the decisive control layer in identity security. Identity programmes have spent years improving authentication, provisioning, and privileged access, but the actual allow-or-deny decision still happens at request time. That makes runtime policy the point where identity security either becomes enforceable or remains theoretical. Practitioners should treat request-time authorization as the control plane, not a feature buried in application code.

Standing privilege remains the structural weakness that runtime policy is meant to contain. The common assumption is that access can be granted ahead of time and then reviewed later, but that model breaks down when workloads, service accounts, and agents act continuously across changing contexts. Standing access creates an exposure window that only grows unless the policy layer evaluates every request. The implication is that governance must shift from entitlement review to decision-time enforcement.

Identity security is converging on an identity fabric model because fragmented enforcement no longer scales. Humans, NHIs, and AI agents now share the same operational dependency on consistent context and auditable decisions. A fabric approach makes the policy layer portable across services while keeping identity systems, PAM, and IGA in their proper roles. The practitioner conclusion is simple: if the policy is not externalised, the programme is already fragmented.

Runtime authorization is the named concept that explains why many identity programmes still underperform. The issue is not the absence of identity tooling, but the absence of a trusted decision layer between identity context and resource access. That gap matters most when an application must decide in milliseconds across changing risk signals and delegated principals. Teams should recognise runtime authorization as a distinct governance domain, not a sub-feature of IAM.

What this signals

Identity security programmes are increasingly judged by whether policy is enforceable at the moment of access, not by how complete the access review workbook looks. That shifts the centre of gravity from provisioning and certification toward runtime decisioning, where humans, workloads, and agents are all subject to the same request-time control.

Runtime authorization gap: when identity policy is embedded in application code, the programme loses consistency, observability, and auditability at the exact point where access is granted or denied. Teams should read that as a design flaw in the control plane, not as an application hygiene issue.

For practitioners

• Externalize authorization decisions Pull allow-or-deny logic out of application code so policy can be versioned, tested, and enforced consistently across services and workloads.
• Map every identity class to runtime policy Include humans, workloads, service accounts, and AI agents in the same authorization model so delegated and non-human access is not treated as an exception.
• Shift from role review to decision-time evaluation Use current context, resource sensitivity, and relationship data at request time instead of relying on role assignment alone.
• Log authorization outcomes in a queryable format Capture who requested what, which context was evaluated, and why the system allowed or denied the action so ITDR and audit teams can use the same evidence.

Key takeaways

• Identity security is no longer just an IAM umbrella term. It is the control plane through which humans, workloads, service accounts, and AI agents all have to pass.
• The weak point is not authentication or entitlement assignment alone. It is the runtime decision that determines whether a specific request should succeed.
• Programmes that externalise authorization and log every decision create a more defensible identity security posture than those that leave policy buried in application code.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Identity Fabric: An identity fabric is a connected control model that shares context across governance, privileged access, and access management. It is not a product category. The aim is to make identity decisions coherent across the full lifecycle so ownership, privilege, and enforcement reinforce each other.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Externalized Authorization: A design pattern where access decisions are removed from application code and handled by a separate policy layer. This makes authorization easier to govern, test, audit, and reuse across services, especially when roles, attributes, and request context change frequently.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.