Cerbos and OPA: what OPA’s shift means for authorization

At a glance

What this is: This is Cerbos’s comparison of Styra + OPA and Cerbos, arguing that OPA’s ecosystem shift makes purpose-built authorization a better fit for new projects.

Why it matters: It matters because IAM, PAM, and non-human identity teams need authorization patterns that can handle application users, workloads, and AI-driven access without building a policy control plane from scratch.

👉 Read Cerbos’s full comparison of Cerbos vs. OPA for authorization

Context

Open Policy Agent has long been used as a flexible policy layer, but the governance question changes when the original commercial steward exits and the tool is left to community maintenance. For teams starting new authorization work, the issue is not whether policy-as-code is useful, but whether a general policy engine still matches the operational burden of modern IAM, NHI, and application authorization programmes. That is why the primary keyword here is authorization.

In practical terms, this is a control-design problem. Teams must decide whether they want to model roles, resources, and tenant boundaries themselves or adopt a system that already encodes those patterns. The same question now applies across human access, workload access, and AI-mediated access paths, especially where policy decisions need to be explainable and maintainable over time.

Key questions

Q: How should teams decide between a general policy engine and a purpose-built authorization layer?

A: Teams should decide based on how much of the authorization control plane they are willing to own. If they need to model roles, tenancy, auditability, and policy distribution themselves, a general policy engine can fit. If they want built-in authorization semantics and lower operating overhead, a purpose-built layer is usually easier to govern.

Q: When does policy-as-code create more operational risk than it removes?

A: Policy-as-code creates more risk when the policy language becomes a specialised development discipline and only a few engineers can safely change it. At that point, access governance slows down, exceptions proliferate, and review quality depends on scarce expertise rather than clear operating models.

Q: How can IAM teams judge whether authorization logic will stay maintainable?

A: IAM teams should test whether policy rules are understandable without deep platform-specific knowledge, whether audit evidence is produced automatically, and whether policy updates can be distributed without custom tooling. If any of those require bespoke engineering, maintainability is already being traded for flexibility.

Q: What should organisations do if their current policy engine is becoming hard to govern?

A: Organisations should first separate the policy model from the implementation burden. Then they should measure how much custom code, distribution logic, and specialist knowledge the current approach needs. If governance depends on a handful of experts, the architecture has outgrown its original operating model.

Technical breakdown

General-purpose policy engines vs purpose-built authorization

OPA is designed as a general policy engine, so it can evaluate policy across many environments but does not impose a native application-authorization model. That makes it flexible, but teams must define their own concepts for roles, resources, tenancy, and decision structure. Cerbos takes the opposite path: it narrows the problem to authorization and ships with built-in patterns such as RBAC, ABAC, ReBAC, derived roles, and tenant isolation. The technical tradeoff is clear. Flexibility reduces built-in assumptions, but it increases the amount of control logic teams must design, test, and operate themselves.

Practical implication: decide whether your team is prepared to own the policy model, not just the policy language.

Policy language, policy data, and maintainability

OPA’s Rego is expressive, but it is a separate language with its own mental model. That can slow adoption and make policy maintenance a specialised skill. Cerbos uses YAML with CEL expressions, which lowers the learning curve and keeps policy definitions closer to configuration than programming. This matters because authorization logic tends to grow incrementally, and complexity often accumulates in edge cases, tenant-specific rules, and exception handling. The more custom code you need to keep policy understandable, the more likely the authorization layer becomes a parallel software product inside the organisation.

Practical implication: treat policy readability and staffing model as architecture criteria, not documentation preferences.

Stateless decisioning and external data enrichment

Cerbos keeps the PDP stateless and avoids external calls during decision evaluation, which makes decisions more predictable and easier to scale. When additional context is needed, enrichment can happen in a separate layer such as Cerbos Synapse before the decision point. OPA can fetch data at runtime through bundle loading or HTTP calls inside policy, which increases flexibility but also creates hidden dependencies on downstream systems. In authorization, hidden runtime dependencies are not a convenience. They are a source of latency, blast radius, and operational ambiguity when policies or data sources change.

Practical implication: map where policy decisions depend on live data, and eliminate surprise runtime calls from the critical path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OPA’s transition from commercial stewardship to community maintenance changes the risk profile for new adopters. Existing users may continue running the platform, but new projects inherit ecosystem uncertainty at the exact moment they need stable governance and clear operational ownership. Authorization layers are not experimental scaffolding once they carry application access, workload access, or AI-adjacent entitlements. Practitioners should treat stewardship continuity as part of control design, not as a vendor-relations footnote.

Purpose-built authorization is becoming the more defensible model for modern IAM programmes. The article’s core comparison is really about control complexity: general policy engines push teams to assemble their own authorization domain model, while purpose-built engines encode common authorization patterns directly. That difference matters for human IAM, workload identity, and non-human identity because each needs clear policy semantics, not just a decision engine. Practitioners should judge the architecture by how much governance they must build around it.

Policy readability is an access-governance issue, not just a developer-experience issue. Rego’s power is real, but the harder a policy language is to maintain, the easier it is for authorization drift to hide inside bespoke logic. When access rules are hard to inspect, audit, and evolve, governance becomes dependent on a small number of specialists. The implication is straightforward: teams should prefer authorization systems that keep policy comprehensible to the wider IAM and application security function.

Stateless evaluation and explicit enrichment reduce hidden authorization dependencies. When policy engines call out to external systems at decision time, the control plane gains flexibility but also inherits fragility from every downstream dependency. That creates uncertainty in latency, reliability, and change management, especially when authorization spans multiple identity types and tenant boundaries. Practitioners should favour designs where enrichment is controlled, visible, and isolated from the decision core.

Named concept: authorization control-plane debt. This is the extra governance burden created when teams must build, maintain, and support the policy model, data model, distribution workflow, and observability layer themselves. The article shows that the problem is not only policy syntax but the hidden operating system around policy. Practitioners should recognise this debt early, because it expands every time authorization logic is used beyond a single application.

From our research:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For broader context on where the category is heading, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for the governance direction that many programmes are already being pulled toward.

What this signals

Authorization control-plane debt: the hidden cost of a general policy engine is not only language complexity, but the governance stack teams must build around it. Once policy distribution, testing, and evidence are custom work, the IAM programme owns another platform rather than a simpler control.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per The 2026 Infrastructure Identity Survey, the broader signal is that identity programmes are already behind the access patterns they will need to govern. That makes policy architecture choices more consequential, not less.

Teams evaluating authorization platforms should also look at lifecycle fit, not just evaluation speed. The real test is whether the model supports human access, workload access, and agent-adjacent access without forcing each programme to invent its own policy semantics.

For practitioners

• Map your authorization control plane before choosing a policy engine. List who owns policy design, distribution, testing, review, and audit evidence for each application, workload, and tenant boundary. If those responsibilities are not already staffed, a general-purpose engine will force you to create them on the fly.
• Score policy readability as a governance requirement. Have IAM, application security, and platform engineers review sample policies for roles, resource hierarchy, and exception handling. If only a policy specialist can explain the rule, the organisation is carrying avoidable maintenance risk.
• Separate data enrichment from the decision path. Document where live identity, resource, and relationship data enters the authorization flow, then remove any surprise HTTP calls from the evaluation step. Predictable decisions are easier to audit and scale than policies that depend on hidden runtime lookups.
• Plan migration around governance ownership, not just syntax conversion. When moving from Rego-based policies to a purpose-built authorization model, translate the policy model, audit expectations, and deployment workflow together. Otherwise, you simply relocate complexity instead of reducing it.

Key takeaways

• OPA’s shifting stewardship matters because authorization is a governance layer, not just a technical component.
• Purpose-built authorization reduces the amount of policy-model engineering teams must carry themselves.
• Teams should choose based on maintainability, observability, and control-plane ownership, not language expressiveness alone.

Key terms

• Authorization Control Plane: The authorization control plane is the set of systems and processes that define, distribute, evaluate, and audit access decisions. It includes policy design, policy storage, decision services, enrichment, testing, and evidence generation, all of which determine whether access can be governed consistently over time.
• Policy-as-Code: Policy-as-code is the practice of expressing access rules in a machine-readable format that can be versioned, tested, and deployed like software. In identity governance, it improves repeatability, but it also increases the need for change control, review discipline, and operational ownership.
• Policy Enrichment: Policy enrichment is the process of adding identity, resource, or relationship context before an authorization decision is made. It helps policies evaluate real conditions instead of static inputs, but it must be controlled carefully because enrichment paths can create latency, dependency, and visibility problems.
• Stateless Decision Point: A stateless decision point evaluates authorization requests without keeping session state or making surprise external calls during evaluation. This makes behaviour more predictable and easier to scale, especially when access decisions must be repeatable, observable, and fast across many applications.

Deepen your knowledge

Authorization architecture and policy governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are evaluating how access decisions should scale across apps, workloads, and agentic systems, it is a relevant starting point.

This post draws on content published by Cerbos: an analysis of Styra, OPA, and Cerbos for authorization. Read the original.