Notifications
Clear all
Topic starter
10/06/2026 10:58 pm
TL;DR: Identity security now spans human users, workloads, service accounts, and AI agents, but most programmes still fail at the runtime authorization layer where each request is actually allowed or denied, according to Cerbos. The missing control is not more login logic but externalised, context-aware decisioning at the moment of access.
NHIMG editorial — based on content published by Cerbos: Identity security in 2026 and the runtime authorization gap
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- How Cerbos models runtime authorization as a dedicated decision layer between applications and identity sources.
- How policy is written, versioned, and tested before it reaches production workloads.
- How Synapse enriches decisions with live identity context from IdPs, databases, and infrastructure systems.
- How the platform applies the same policy pattern to workloads, services, and AI agent tool calls.
👉 Read Cerbos' full analysis of identity security and runtime authorization →
Runtime authorization in identity security: where the gap still is?
Explore further
12/06/2026 4:44 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity security in 2026 still breaks at runtime authorization
