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.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Identity security in 2026”.
By the numbers:
- 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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 4:44 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Identity security in 2026 still breaks at runtime authorization
This post was modified 5 days ago by NHI Mgmt Group