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

At a glance

What this is: This is an analysis of OPA’s ecosystem changes and Cerbos’ case for purpose-built authorization, with the key finding that new projects now face greater uncertainty around long-term stewardship and support.

Why it matters: IAM and platform teams need to re-evaluate authorization architecture choices because maintainability, supportability, and governance model matter as much as policy expressiveness when access control spans apps, APIs, and non-human identities.

Context

Open Policy Agent is a general-purpose policy engine, but authorization teams often need something narrower: a clear model for who or what can do which action on which resource. When a policy platform becomes the default control plane for app access decisions, its operating model matters as much as the syntax used to express rules.

The governance concern in this article is not only technical fit but ecosystem stability. Cerbos frames the OPA changes as a risk for teams starting fresh, because support, roadmap clarity, and policy lifecycle ownership influence whether authorization can scale safely across human, non-human, and agentic use cases.

Key questions

Q: How should teams evaluate a policy engine after a major stewardship change?

A: Teams should look beyond syntax and compare roadmap continuity, support model, policy lifecycle tooling, and whether the platform is still aligned to the access-control problem they need to solve. A project can remain technically sound while becoming operationally harder to govern if the surrounding ecosystem is less stable.

Q: When does a general policy engine create more operational burden than value?

A: It becomes burdensome when teams need straightforward application authorization but must invent their own role model, resource hierarchy, tenant boundaries, and deployment workflows. At that point, flexibility turns into engineering overhead, and the access layer starts behaving like a custom framework rather than a control.

Q: What signs show that authorization logic is too brittle?

A: Common signs include repeated access-related rewrites, developers adding new if-statements for every new customer requirement, difficulty explaining why an action was allowed, and pressure to delay enterprise sales because access control is not flexible enough. Those are indicators that the authorization model is no longer scaling with the product.

Q: What breaks when organisations rely on ad hoc access control for APIs and AI agents?

A: Ad hoc access control usually creates duplicated logic, inconsistent policies, and harder audits. In practice, teams rebuild the same authentication and authorization patterns across projects, which increases cost and raises the chance of misconfiguration. It also makes it harder to manage token issuance, revocation, and policy updates consistently across APIs, applications, services, and machine-based workloads.

Technical breakdown

What changes when a general policy engine loses its original stewards?

OPA’s value has always been breadth: it can express many policy types across infrastructure and application environments. The tradeoff is that breadth depends heavily on a mature ecosystem, clear stewardship, and surrounding operational tooling. When maintainers and commercial backing shift away from the core project, new adopters inherit more uncertainty around roadmap direction, enterprise support, and long-term investment. That does not break existing deployments overnight, but it changes the procurement and governance calculus for teams that are still deciding whether to standardise on it for new authorization projects.

Practical implication: Treat stewardship continuity as a selection criterion, not a side issue, when evaluating policy engines for new authorization programmes.

Why does purpose-built authorization reduce policy sprawl?

A purpose-built authorization engine starts from access control assumptions, not from a blank policy substrate. That matters because application teams usually need RBAC, ABAC, ReBAC, tenant isolation, derived roles, and resource-scoped decisions rather than arbitrary policy logic. General engines can model those patterns, but only after teams define their own schemas, data structures, and enforcement conventions. The result is often duplicated logic across services and more opportunities for inconsistent decision semantics. A domain-specific authorization layer reduces that drift by making the core concepts explicit from the start.

Practical implication: Standardise on an authorization model that encodes roles, resources, and conditions natively instead of rebuilding those concepts in each application.

How do stateless policy decisions change operational risk?

The article highlights a key architectural distinction: a stateless policy decision point evaluates inputs without needing to reach out to external systems during the decision path. That design keeps latency predictable and reduces surprise dependencies, especially when authorization must sit in front of APIs or agent-driven workflows. By contrast, policy engines that fetch data at evaluation time can become coupled to downstream services, which makes performance and availability part of the access-control problem. In practice, the more runtime lookups an authorization layer performs, the more governance risk shifts into the policy path itself.

Practical implication: Prefer authorization designs that keep the decision path predictable and isolate external data enrichment from the core policy evaluation.

Threat narrative

Attacker objective: The relevant objective here is not an external adversary’s compromise but the internal outcome of preserving reliable authorization while avoiding a fragile control stack.

1. Entry occurs when teams adopt a policy engine for new authorization work without fully pricing in the ecosystem transition around stewardship and commercial support.
2. Escalation follows as the organisation discovers that its policy model, tooling, and maintenance assumptions have to be built around a more uncertain project lifecycle.
3. Impact is slower adoption, higher operational overhead, and a greater chance that authorization becomes a bespoke engineering programme instead of a governable control layer.

Breaches seen in the wild

• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

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

NHI Mgmt Group analysis

Stewardship continuity is now part of authorization risk, not just vendor risk. When the original maintainers of a policy engine move on and commercial support winds down, new adopters inherit uncertainty about roadmap velocity, support depth, and long-term governance. That matters because authorization is infrastructure for every application decision it touches. The implication is that teams must evaluate policy platforms as enduring control systems, not just as syntax choices.

Purpose-built authorization reduces the amount of governance teams must invent. General policy engines are flexible, but flexibility often means every team has to define its own role model, resource hierarchy, and lifecycle conventions. A focused authorization layer makes those patterns explicit, which lowers implementation ambiguity and improves auditability. The implication is that application-layer access control should minimise bespoke policy engineering wherever possible.

Stateless decisioning is a governance choice, not just a performance choice. If the policy decision point never calls out during evaluation, the control path stays more predictable and easier to reason about. That changes the failure mode from runtime dependency drift to policy content quality. The implication is that teams should separate enrichment from enforcement so access decisions remain stable under load.

Authorization for AI agents and non-human identities needs deterministic control boundaries. As authorization expands into AI agents, APIs, and workload contexts, policy systems cannot rely on implicit human review or loosely defined runtime lookups. The control layer has to express who or what is acting, under which scope, and with which entitlement boundary. The implication is that identity governance for non-human actors must be designed around explicit decision semantics, not inferred intent.

OPA’s broad expressiveness is valuable, but broadness is not the same as fit. The article underscores a familiar pattern: teams often choose a general policy engine because it can do many things, then spend time building the missing authorization framework around it. That overhead is manageable for some infrastructure use cases, but it is often unnecessary for application access control. The implication is that teams should match tool scope to the governance problem they actually need to solve.

What this signals

Policy stewardship is now part of the authorization architecture review. Teams choosing a policy engine for new projects should treat maintainer continuity, support depth, and lifecycle ownership as selection criteria alongside language expressiveness. A control that is hard to operate or hard to sustain stops being a control and becomes a dependency.

Purpose-built authorization is likely to gain share where teams want fewer invented conventions. The more an engine forces teams to define roles, resource hierarchies, and distribution mechanisms from scratch, the more likely they are to seek a narrower authorization layer. That shift matters most in application, API, and non-human identity contexts where policy clarity is more valuable than generality.

For practitioners

• Assess policy-engine stewardship risk Review whether the authorization platform you are evaluating still has clear maintainers, commercial backing, and a support model that matches your deployment horizon.
• Map your access-control model before choosing tooling Document whether your application needs RBAC, ABAC, ReBAC, tenant isolation, or derived roles so you can test whether the platform natively supports those concepts.
• Separate enrichment from enforcement Keep identity and resource lookups out of the core decision path where possible so policy evaluation stays predictable under production load.
• Check how much custom policy infrastructure you would need Estimate the amount of schema design, lifecycle tooling, and distribution logic required if the engine does not provide first-class authorization primitives.
• Test authorization for app and agent contexts separately Validate whether the same policy model can govern human users, APIs, and AI agents without introducing ambiguous decision boundaries or duplicated rules.

Key takeaways

• The article argues that OPA’s ecosystem transition changes the buying question for new authorization projects, because stewardship and support now matter as much as policy expressiveness.
• For application and API access control, the biggest cost of a general policy engine is often the custom governance layer teams must build around it.
• The practical decision is whether your authorization programme needs a broad policy framework or a focused control layer with clearer operational ownership.

Key terms

• Authorization Engine: A centralized system that evaluates whether an authenticated identity can perform a requested action on a resource. In modern application stacks, it separates policy from code, but it still depends on accurate identity, tenant, and lifecycle data to make trustworthy decisions.
• 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.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.

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.