On-prem authorization is becoming board-level identity control

At a glance

What this is: This is an independent analysis of why authorization is moving into the identity control plane, with on-prem deployment increasingly chosen for regulated, air-gapped, and AI-heavy environments.

Why it matters: It matters because IAM teams now need to govern runtime access decisions for humans, non-human identities, and AI agents with the same auditability, determinism, and policy control.

By the numbers:

• Broken access control has held the #1 spot on the OWASP Top 10 since 2021 and maintained it in 2025, with 100% of tested applications showing some form of access control vulnerability.
• Stolen credentials have appeared in nearly one-third of all breaches over the past decade, according to the Verizon 2024 Data Breach Investigations Report.
• Among organizations that experienced an AI-related breach, 97% lacked proper access controls, according to IBM's 2025 Cost of a Data Breach Report.

👉 Read Cerbos' analysis of on-prem authorization for AI agents and regulated systems

Context

Authorization has become the runtime control that decides, millisecond by millisecond, whether a request is allowed or denied. That makes it different from authentication or identity governance, because the decision happens at execution time and must hold up for humans, service accounts, API calls, and AI agent actions under the same policy model.

The case for on-prem authorization is strongest where auditability, sovereignty, and determinism matter more than convenience. Regulated enterprises, air-gapped environments, and AI-heavy platforms all need the same thing: a defensible answer to who could access what, under which policy, and with what evidence when an incident or audit arrives.

Key questions

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. That gives teams one governed access model for humans, workloads, and agents while preserving auditability. The practical test is whether the team can explain every allow or deny decision from policy, context, and logs alone.

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. Service accounts, workloads, and AI agents need decisions that evaluate resource state, relationships, and session context. If the model cannot express that, it will either overgrant or block legitimate work.

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. If incident response or audit requires code archaeology, authorization governance is not working. Evidence quality is the signal, not policy volume.

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.

Technical breakdown

Policy-as-code and centralized policy administration

Modern authorization platforms separate policy definition from application code. Policy-as-code keeps access rules version-controlled, testable, and reviewable, while a centralized Policy Administration Point distributes those rules to enforcement points across services, APIs, and agent workflows. That architecture reduces drift between teams and makes access decisions more defensible because the policy version, context, and outcome can all be traced later. The key design point is not simply centralisation. It is keeping the decision logic consistent while letting enforcement happen wherever the request originates.

Practical implication: move authorization rules out of scattered code paths and into a centrally governed policy lifecycle.

Why deterministic runtime authorization matters

Runtime authorization is not the place for probabilistic judgment. The decision must be fast, repeatable, and explainable, because it sits in the path of every access request. AI can help upstream by modelling policy, analysing over-provisioning, or spotting patterns, but the final allow or deny decision needs deterministic evaluation so auditors and responders can reproduce it exactly. This is especially important for AI agents and other non-human identities, where access can be requested at machine speed and the evidence trail must survive scrutiny after the fact.

Practical implication: keep AI in policy analysis and use deterministic engines for the actual runtime decision.

On-prem deployment, audit trails, and sovereignty

On-prem authorization keeps policies, decision logs, and sensitive context inside the enterprise perimeter. That matters when authorization data itself becomes regulated evidence, especially in environments that cannot rely on external connectivity or third-party processing. In practice, on-prem deployment is about preserving the chain from request to policy to decision without depending on a cloud service to explain the result. For regulated sectors, the deployment model is part of the control, not just an infrastructure preference.

Practical implication: treat deployment location as an audit and resilience control, not only an operations choice.

Threat narrative

Attacker objective: The objective is to turn a valid identity or stolen credential into broader access than the original context should have allowed, then exploit the resulting authorization gaps.

1. Entry occurs when a workload, user, or agent reaches an application path whose access logic is scattered across multiple codebases, making policy inconsistencies easy to exploit.
2. Credentialed access is then abused because stolen credentials still remain a common breach vector, and weak authorization makes those credentials more powerful than they should be.
3. Impact follows when responders cannot quickly answer what the account could access, which policy allowed it, or which decisions were made at runtime.

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

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.

Runtime authorization is the new control boundary for NHI and AI-agent access. Static roles and coarse application permissions are too blunt for service accounts, workload identities, and AI agents that request access dynamically. Fine-grained policy decisions need to follow the request context, not a pre-baked role catalogue. Practitioners should recognise that the access model has shifted from provisioning-time grants to decision-time enforcement.

The assumption that least privilege can be defined once at provisioning time breaks when authorization is evaluated at millisecond speed across changing context. That assumption was designed for stable identities and predictable request patterns. It fails when the actor is a service, workload, or agent whose effective access depends on resource state, relationship data, and session context. The implication is that identity governance has to rethink where privilege is expressed, because static entitlement thinking no longer matches runtime reality.

On-prem authorization is becoming a compliance and defensibility choice, not merely a deployment preference. In regulated environments, decision logs and policy evidence are part of the control surface. If those records sit outside the perimeter, responders and auditors inherit extra dependency and extra exposure. Practitioners should evaluate authorization platforms on evidence control, residency, and reproducibility, not just on API compatibility.

AI adoption is forcing identity teams to own the authorization bill. Boards may approve AI strategy, but the security team is left with the access model that makes the strategy safe enough to run. That is why authorization is now competing with IAM, IGA, and PAM for programme priority. The practical implication is that teams should stop treating authorization as a back-end utility and start treating it as governed security infrastructure.

From our research:

• 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.
• For a deeper governance lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which maps provisioning, rotation, and offboarding to controlled access.

What this signals

Authorization is becoming the control plane that determines whether AI adoption is governable at all. With 70% of organisations granting AI systems more access than human employees in the 2026 Infrastructure Identity Survey, the problem is not just privilege creep. It is that runtime access decisions now need to be provable, repeatable, and attributable across human and non-human actors.

Identity teams should expect authorization to absorb more of the governance burden previously split across IGA, PAM, and application teams. That shift will be clearest in regulated environments where audit evidence must survive incident response and external review. Teams that still treat authorization as a code pattern will struggle to defend access decisions when scrutiny arrives.

Policy evidence is emerging as the named concept that separates mature authorization programmes from fragmented ones. If a team cannot reconstruct policy version, context, and decision outcome quickly, it does not yet have a defensible control surface. The practical response is to measure whether authorization records can support both operational containment and audit inquiry without manual reconstruction.

For practitioners

• 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.
• Treat deployment location as a control requirement For regulated or air-gapped environments, keep policies, decision logs, and sensitive context inside the controlled perimeter to preserve evidence.

Key takeaways

• Authorization is now a board-level identity control because it determines access at runtime, not just at provisioning time.
• Broken access control and stolen credentials remain a dangerous combination, and AI-related breaches show how quickly weak runtime controls become incident multipliers.
• The defensible path is centralised policy, deterministic decisions, and deployment models that preserve audit evidence inside the controlled perimeter.

Key terms

• Policy-as-Code: Policy-as-code stores authorization rules in version-controlled files rather than hidden application logic. That makes access decisions testable, reviewable, and auditable. In practice, it is the difference between a control that can be governed and one that can only be hoped for.
• Policy Decision Point: A Policy Decision Point is the component that evaluates a request against policy and returns allow or deny. In distributed systems, it becomes the runtime authority for access decisions, while enforcement points apply the outcome close to the application or API.
• Authorization Sprawl: Authorization sprawl is the condition where access logic is duplicated across services, repositories, or teams with no single source of truth. It produces inconsistent decisions, weak auditability, and hard-to-defend access paths, especially when humans, workloads, and agents all consume the same systems.
• Deterministic Authorization: Deterministic authorization means the same request, policy, and context always produce the same decision. That property matters because security teams need access controls they can reproduce during audits, investigations, and incident response. It is especially important when AI is involved upstream but not at the decision boundary.

Deepen your knowledge

Authorization policy design and runtime enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving authorization out of application code and into governed identity control, the course is a practical next step.

This post draws on content published by Cerbos: authorization as a board-level infrastructure decision. Read the original.