Identity security in 2026 still breaks at runtime authorization

At a glance

What this is: This is an identity security analysis showing that the discipline now spans humans, machines, and AI agents, but still breaks most often at runtime authorization.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes can look complete on paper while still making unsafe allow-or-deny decisions at the point of request.

👉 Read Cerbos' full analysis of identity security and runtime authorization

Context

Identity security has become the control plane for modern access decisions, because the perimeter has already dissolved and every important request now depends on who or what is calling a service. For IAM teams, the hard part is no longer only authentication or provisioning, but the runtime decision that grants or blocks access at the moment of use.

That shift matters for both NHI and human identity programmes. A platform can manage joiners, movers, leavers, privileged access, and posture, yet still leave a critical gap if the final authorization decision lives inside application code or inconsistent service logic.

The article frames identity security as a stack made up of access management, IGA, PAM, ITDR, ISPM, and an identity fabric. The unresolved problem is how to make that stack enforceable at runtime across workloads, service accounts, and AI agents, not just visible in reports.

Key questions

Q: How should security teams implement runtime authorization in identity security programmes?

A: Security teams should move the final allow-or-deny decision out of application code and into a dedicated policy layer that evaluates identity, resource, action, and context at request time. That keeps authorization consistent across services, makes policy change auditable, and prevents each team from inventing its own access logic.

Q: Why does identity security become harder when workloads and AI agents are part of the access model?

A: Identity security becomes harder because workloads and AI agents create delegated access paths that are not fixed like a human login. They can inherit permissions, call tools, and trigger downstream actions, so the programme has to govern runtime behaviour as well as provisioning and review.

Q: What breaks when authorization is embedded inside application code?

A: When authorization lives inside application code, policy changes require redeployments, audit questions require code inspection, and access decisions can vary from service to service. The result is inconsistent enforcement and weak visibility, which makes identity governance harder to prove and harder to defend.

Q: How do IAM teams know if their identity fabric is actually working?

A: They should look for one policy model, one audit trail, and one enforcement path across human users, workloads, and agents. If access rules differ by service, if decisions are not queryable, or if privileged requests bypass the central policy layer, the fabric is not yet operating as designed.

Technical breakdown

Runtime authorization versus admin-time identity controls

Admin-time controls decide who gets access assigned, while runtime authorization decides whether a live request should be allowed right now. That distinction matters because provisioning, access reviews, and PAM can all be correct and still miss the real risk if the request decision is buried in application code or duplicated across services. In a modern identity fabric, the policy engine must evaluate identity, resource, action, and context continuously rather than relying on static role assignment alone. The runtime layer is where least privilege becomes executable rather than theoretical.

Practical implication: externalise authorization decisions from application code so every service evaluates the same policy at request time.

Identity fabric and externalised policy enforcement

An identity fabric is the architectural idea that identity data, policy, and enforcement should work across systems rather than remain trapped inside each application. Open standards such as OIDC, SCIM, and SPIFFE help connect identities, but they do not by themselves decide access. That decision requires a dedicated policy decision point that can consume live attributes, relationships, and context. Without that separation, teams get fragmented rules, inconsistent outcomes, and poor auditability. With it, identity becomes a governed control plane instead of a set of disconnected checks.

Practical implication: treat policy as infrastructure and centralize decision logic so identity rules are versioned, tested, and auditable.

AI agents and non-human identities in the identity graph

AI agents do not replace the identity model, they widen it. When an agent acts on behalf of a user, calls tools, and inherits permissions, it becomes a non-human principal that must be governed alongside workloads and service accounts. The challenge is not just authentication, but whether the runtime policy can express what the agent may do in context, with which tool, and under which boundaries. That is why agent access cannot be managed only through static roles or one-time approvals. The control has to see the agent as a first-class identity object.

Practical implication: model AI agents as governed principals and apply live authorization checks to every tool call and delegated action.

Threat narrative

Attacker objective: The objective is to use legitimate identity paths to gain trusted access that the organization cannot reliably constrain, detect, or explain at runtime.

1. Entry begins when attackers or rogue actors use valid identities, stolen tokens, or over-permissioned service accounts to reach trusted systems without breaking perimeter controls.
2. Escalation occurs when static roles, buried application logic, or standing privilege let the actor move from initial access to broader resource use without a fresh authorization decision.
3. Impact follows when the identity layer cannot explain or constrain who can do what with sensitive data, leaving teams unable to contain misuse or prove accountability.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 control plane gap that identity security still leaves open. IGA, PAM, and ITDR all matter, but they mostly govern setup, detection, and privileged accounts. The real decision point is the live allow-or-deny call made when a user, workload, or agent hits a service. If that decision is embedded in application code, the programme is not truly identity-secure. Practitioners should treat runtime authorization as a first-class identity control, not an application convenience.

Identity security is now a cross-domain discipline, not an IAM subset. The article is right that modern programmes must cover human identity, machine identity, and delegated AI behaviour together. The governance mistake is to keep these lanes separate when the attack paths are converging through shared APIs, shared policies, and shared audit expectations. A mature programme must present one identity graph, one policy model, and one enforcement story across all three actor types. Practitioners should stop designing identity controls around organisational silos.

Authorization logic buried in services creates an identity blast radius that teams cannot govern cleanly. When every microservice carries its own rules, any policy change becomes a deployment problem and any audit question becomes code archaeology. Identity blast radius: the amount of access misbehaviour that spreads when authorization is fragmented across systems. The implication is not just technical debt, but governance debt. Practitioners need a model where access decisions are explainable, versioned, and enforced in one place.

Dynamic AI and workload identities expose the limits of static least privilege planning. AI agents inherit permissions, chain tool calls, and shift context during execution, which means the access story is not fixed at provisioning time. That does not make them magically autonomous, but it does make their governance more fragile than a human login flow. The right lens is to treat every delegated action as a governed identity event. Practitioners should reassess whether their current identity fabric can represent those delegation chains at all.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access can outgrow governance.
• That visibility gap is one reason the Ultimate Guide to NHIs remains relevant when teams are trying to connect access, audit, and runtime policy.

What this signals

Runtime authorization will become the deciding layer in identity programmes that already look mature on paper. Teams that have strong IGA and PAM but weak decisioning at the point of request will keep finding that governance evidence does not match actual access outcomes. The practical signal is simple: if a policy change still requires application redeployments, the identity programme is not finished.

Identity blast radius: the spread of access failure when policy is fragmented across services. That problem will intensify as more workloads and AI agents become first-class principals, because each new delegated path adds another place where governance can drift away from enforcement.

For teams mapping this to standards work, the most relevant reference point is the externalized decision model described in the SPIFFE workload identity specification, which reinforces the need for portable identity and trustworthy runtime context.

For practitioners

• Externalize runtime authorization Move allow-or-deny decisions out of application code and into a dedicated policy layer so every service evaluates the same rules at request time.
• Model workloads and agents as governed principals Assign explicit identity objects, context attributes, and audit trails to service accounts, workloads, and AI agents instead of treating them as side effects of application access.
• Separate provisioning from decisioning Keep joiners-movers-leavers, PAM, and certification workflows in governance tools, but require a live authorization decision before sensitive actions are executed.
• Audit for fragmented service-side policy Find every place where access logic is duplicated in code, configs, or middleware and replace those islands with one policy source of truth.

Key takeaways

• Identity security in 2026 is no longer just about provisioning and detection, because runtime authorization now determines whether access is actually safe.
• Machine identities and AI agents expand the control problem, but the deepest gap remains the same: inconsistent policy at the point of request.
• Practitioners should treat externalised, auditable authorization as a core identity control, not as an optional application design choice.

Key terms

• Runtime Authorization: Runtime authorization is the live decision that allows or denies a request when a user, workload, or agent tries to access a resource. It differs from provisioning because it evaluates current context at the moment of action, not just a prior role assignment or approval.
• Identity Fabric: An identity fabric is an architectural approach that connects identity data, policy, and enforcement across many systems instead of leaving each application to handle access on its own. In practice it depends on central policy, distributed enforcement, and consistent identity context.
• Externalized Authorization: Externalized authorization means access logic lives outside application code and is enforced by a separate decision layer. That separation improves consistency, auditability, and change control, especially when humans, workloads, and AI agents all need governed access.
• Identity Blast Radius: Identity blast radius is the amount of damage that spreads when authorization is fragmented, stale, or inconsistent across systems. It is a useful governance term because it captures how small policy errors can become broad access failures across services, identities, and delegated actions.

Deepen your knowledge

Runtime authorization and identity fabric design are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already managing workloads, service accounts, or AI agents, this is a relevant next step.

This post draws on content published by Cerbos: Identity security in 2026 and the runtime authorization gap. Read the original.