TL;DR: Broken access control remains the most exploited flaw in modern software, while stolen credentials appear in nearly one-third of breaches and AI-related incidents often lack proper access controls, according to Cerbos and referenced industry research. Authorization is shifting from an application detail to a board-level identity control because runtime decisions now govern humans, workloads, and AI agents alike.
NHIMG editorial — based on content published by Cerbos: authorization as a board-level infrastructure decision
By the numbers:
- Among organizations that experienced an AI-related breach, 97% lacked proper access controls, according to IBM's 2025 Cost of a Data Breach Report.
Questions worth separating out
Q: How should security teams implement authorization for AI agents and service identities?
A: They should separate policy from code, enforce decisions at runtime, and keep the decision engine deterministic.
Q: Why do coarse access models fail for non-human identities?
A: Coarse access models fail because non-human identities often act with task-specific context that changes faster than static roles can represent.
Q: How do organisations know if authorization governance is working?
A: They should be able to answer who can access what, why the policy allowed it, and which version of the policy produced the decision within minutes.
Practitioner guidance
- Centralise authorization policy management Move access rules out of application code and into a single policy lifecycle with version control, testing, approval, and audit logging across services and APIs.
- Separate policy decisions from enforcement Use a centralized decision point and deploy lightweight enforcement in services, APIs, and agent workflows so the same rules apply everywhere.
- Use deterministic runtime decisions Reserve AI for policy analysis and access pattern discovery, but require deterministic allow or deny decisions at the runtime boundary.
What's in the full article
Cerbos' full research-style article covers the operational detail this post intentionally leaves for the source:
- Policy architecture examples for central administration with decentralized enforcement across APIs and services
- Deployment-model considerations for regulated, hybrid, and air-gapped environments
- Detailed discussion of Cerbos Hub, PDP, Synapse, and enforcement SDKs in a distributed stack
- Standards references including AuthZEN and how it fits into enterprise authorization design
👉 Read Cerbos' analysis of on-prem authorization for AI agents and regulated systems →
On-prem authorization for AI agents and regulated systems?
Explore further
Authorization sprawl is now an identity governance failure, not just an application design flaw. When access logic is scattered across codebases, no one can answer who can access what without reconstructing policy from fragments. That is a governance problem because it breaks auditability, reviewability, and accountability at the point where access is actually granted. The practical implication is that authorization must be treated as a governed identity control plane, not as local application logic.
A few things that frame the scale:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who is accountable when authorization decisions are wrong?
A: Accountability sits with the teams that define, approve, and operate the authorization policy, because runtime decisions become part of the security control surface. In regulated environments, the ability to produce policy evidence, logs, and decision history is what makes the control defensible. Shared responsibility does not remove ownership.
👉 Read our full editorial: On-prem authorization is becoming board-level identity control