On-prem authorization is becoming board-level identity control

At a glance

What this is: This analysis argues that authorization has become a board-level identity control because runtime allow or deny decisions now govern humans, workloads, and AI agents under regulatory and incident-response pressure.

Why it matters: It matters because IAM, PAM, and NHI programmes must now prove who could access what, why, and under which policy version, especially when regulated data, AI agents, and auditability converge.

By the numbers:

• Broken access control has held the #1 spot on the OWASP Top 10 since 2021 and maintained it in 2025.
• Stolen credentials have appeared in nearly one-third of breaches, or 31%, over the past decade.
• Forty percent of enterprise applications are expected to integrate task-specific AI agents by the end of 2026.
• Among organizations that experienced an AI-related breach, 97% lacked proper access controls.

Context

Authorization is the runtime control that decides, request by request, whether access should be allowed. In this article, Cerbos argues that authorization has moved from a developer concern to a governance issue because boards and regulators now need defensible answers about who could access what, why, and under which policy version.

That shift is especially relevant for regulated systems, AI agents, and non-human identities. When access decisions are scattered across application code, identity governance and access management can describe entitlements, but they cannot always prove the live decision path that produced them.

Key questions

Q: What breaks when authorization is spread across multiple applications instead of one source of truth?

A: When authorization is spread across multiple applications, revocation becomes unreliable, team changes can leave stale access behind, and audits become fragmented. Different services may interpret the same entitlement differently, which creates inconsistent decisions and operational blind spots. A single source of truth helps ensure access is updated quickly and applied the same way everywhere.

Q: Why do stolen credentials become more dangerous when authorization is weak?

A: Stolen credentials provide entry, but weak authorization determines how far the attacker can go. When access rules are coarse or inconsistent, a valid identity can reach sensitive systems, tool chains, and data paths that should have been blocked at runtime.

Q: What are the signs that an authorization model is failing in practice?

A: Common signs include inconsistent decisions across services, repeated permission errors, unexpected access to restricted resources, and policy changes that are hard to trace. Another warning sign is privilege creep, where users or service identities accumulate more access than they need. If teams cannot clearly explain why an access decision was made, the authorization model is likely too weak.

Q: When should organisations choose on-premise authorization over cloud-hosted control?

A: Choose on-premise when policy data, decision logs, or runtime availability must stay inside a regulated boundary. That is most defensible in sovereign, air-gapped, defense, healthcare, and financial environments where external dependency would turn access control into an availability risk.

Technical breakdown

Why runtime authorization is different from identity governance

Authorization answers a different question from authentication or IGA. Authentication proves who or what is present, and identity governance records standing entitlement, but authorization evaluates each access request in context. That context can include role, attributes, resource sensitivity, session state, delegation, and policy version. In modern systems, the decision must happen at runtime and often at millisecond latency. That is why authorization becomes the control plane for enforcement, while governance remains the control plane for review. When authorization logic is dispersed across codebases, the organisation loses a single accountable decision point.

Practical implication: Centralise policy decisions so security teams can explain each allow or deny outcome from one governed layer.

Why AI agents and non-human identities change the access model

AI agents and other non-human identities do not just consume access, they can initiate actions at runtime across tools and services. That creates a harder problem than static role assignment because the request path, delegation chain, and session context can change during execution. If an agent can call tools, access data, and continue operating without human approval between steps, the identity model must govern the action as it happens, not after the fact. This is where policy-based authorization, not coarse access management, becomes the practical control for both NHI and agentic workflows.

Practical implication: Treat agent and service access as dynamic runtime behaviour that needs policy evaluation on every sensitive action.

Why on-premise policy control matters for regulated and air-gapped systems

On-premise authorization matters when the policy engine, decision logs, and audit trail contain sensitive operational data that cannot leave the environment. Regulated sectors, defense-adjacent workloads, and disconnected sites need authorization to keep working even when external connectivity is lost. A cloud dependency turns access control into an availability risk, which is unacceptable when every API call, workload decision, or agent action depends on the PDP. The architecture problem is not just where policies are stored, but where the decision authority lives.

Practical implication: Place decision and audit infrastructure inside the trust boundary when residency, sovereignty, or isolation are part of the security requirement.

Threat narrative

Attacker objective: The attacker seeks to turn a valid identity into broad, hard-to-audit access across applications, data, and agent workflows.

1. Entry begins when an attacker uses stolen credentials or a compromised identity to reach a service whose access rules are scattered across application code.
2. Escalation occurs when weak or inconsistent authorization logic allows the same identity to reach more resources than intended, especially across APIs, SaaS services, or agent tools.
3. Impact follows when the attacker can enumerate, access, or alter sensitive data and actions without a single decision layer able to explain or block the path.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

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 has become the board-level control because it is the only layer that can explain live access decisions. Identity governance can inventory entitlements, but it cannot on its own answer why a specific request was allowed at a specific moment. That gap matters when regulators, auditors, and boards expect a defensible trail from request to policy to outcome. The practitioner conclusion is that authorization is now a governance instrument, not just an application utility.

Policy sprawl is the real enterprise risk hiding behind scattered authorization logic. When each codebase implements access rules differently, organisations create inconsistent decisions, weak reviewability, and hidden exceptions that no central review can fully reconstruct. This is not just operational messiness; it is a control failure that weakens incident response and disclosure readiness. The practitioner conclusion is to treat policy consistency as a security control in its own right.

Non-human identities make runtime authorization a structural requirement, not an optimisation. Service accounts, workloads, and agents can move faster than access reviews and often act across multiple systems in one session. That means the decisive control is the decision point, not the entitlement register. The practitioner conclusion is that NHI governance now depends on runtime policy enforcement as much as lifecycle management.

Air-gapped and sovereign environments expose the dependency assumption baked into cloud-hosted authorization. If the policy engine needs external reachability, access control becomes another availability dependency that regulated operators cannot always accept. In those environments, the question is not deployment preference but whether the control survives isolation, outage, and regulator scrutiny. The practitioner conclusion is to align authorization architecture with the environment's operational constraints before deployment.

Runtime authorization is the missing link between AI strategy and defensible control. Boards may approve AI agents, but security teams must still prove which actions an agent could take, under what policy, and with what audit evidence. That requirement creates a new governance centre of gravity around deterministic policy decisions. The practitioner conclusion is to make authorization part of AI operating model design, not a post-launch retrofit.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: NHI Lifecycle Management Guide

What this signals

Policy locality is becoming a design requirement: when authorization decisions, logs, and policy versions stay inside the operating boundary, teams can keep proving access outcomes even in regulated or disconnected environments. That shifts the conversation from deployment convenience to control survivability.

AI agent governance depends on deterministic runtime decisions: a policy model that cannot explain each action at the moment it happens will not withstand board, audit, or incident-response scrutiny. According to the State of Secrets in AppSec, 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases. That concern becomes more acute when agents are allowed to act with unresolved authorization scope.

For practitioners

• Map authorization ownership to a single control plane Identify where policy is currently implemented across services, scripts, and platform layers, then consolidate decision authority so teams can answer who can access what without code spelunking.
• Separate policy decision from policy enforcement Use a central policy decision point with distributed enforcement points so API services, workloads, and agents all evaluate the same rules at runtime.
• Define runtime controls for non-human identities Require every service account, workload, and AI agent to pass through the same authorization logic for sensitive actions, including delegation and tool use.
• Keep sensitive decision logs inside your boundary Retain policy data, decision logs, and audit trails in the deployment model that matches residency, sovereignty, and air-gap requirements.
• Test incident questions before the incident Verify that your team can trace a decision back to the exact policy version and evaluated context without waiting for a vendor export or support workflow.

Key takeaways

• Authorization is now a governance control because runtime decisions determine whether humans, workloads, and AI agents can act under a defensible policy.
• Scattered access logic creates audit and incident-response blind spots that identity governance alone cannot close.
• Enterprises with residency, sovereignty, or agentic workloads need policy decisions they can explain, log, and enforce inside the environment.

Key terms

• Authorization Management Platform: A control layer that evaluates policy, identity data, and context to decide whether access should be allowed. In practice, it sits between identity sources and applications so teams can apply consistent authorization rules across different systems and non-human identities.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Policy Administration Point: A policy administration point is the control layer where authorization rules are created, reviewed, tested, and distributed. In practice, it acts like an identity policy plane, so its change management, ownership, and auditability matter as much as the policy language itself.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.