Cerbos vs PlainID

If you are comparing Cerbos with PlainID, you are probably running a program to put authorization under one set of rules. That might mean entitlements spread across hundreds of applications, some of them inherited through acquisitions. It might be a decision that authorization has to move out of application code so the identity team can govern it, now that AI agents act on behalf of your users too.

Both products answer the same runtime question, whether this person, service or agent may take this action on this resource. They differ in how the policy behind that answer is written, reviewed and governed once you have thousands of rules, where the decision runs, how far one policy set reaches, and what the platform costs to run for the next five years.

This comparison goes through each of those, with what we have learned from teams that evaluated both.

Cerbos vs PlainID at a glance

Question	Cerbos	PlainID
What it is	An authorization management platform. Decision points run next to every workload, Cerbos Hub manages policy and audit, and Cerbos Synapse brings in context and connects gateways, data platforms and AI agents.	A policy-based access control platform with a policy administration console, decision points and prebuilt connectors called Authorizers. Relaunched in October 2026 as a runtime authorization platform.
How policy is written	Short YAML policies with CEL conditions that a security reviewer can read, reviewed in pull requests and tested before they ship.	Visual authoring in PlainID's console, plus Structured Rego, a constrained Rego format tied to PlainID metadata and platform objects.
Where decisions run	Inside your infrastructure, as a service, sidecar, DaemonSet, serverless function or in the browser. Decision points keep serving the last policy if Cerbos Hub is unreachable.	SaaS, hybrid or on-premises.
Where policy is managed	Cerbos Hub, hosted, or fully on-premise and air-gapped for enterprise customers.	PlainID’s administration console, hosted by PlainID or on-premises.
Coverage	One set of policies across applications (SDKs in eight languages plus Laravel), API gateways and service meshes (Kong, Apigee, Envoy and Istio), data platforms and event streams, Kubernetes, MCP servers and AI agents.	Applications, API gateways, data platforms and AI frameworks through Authorizers.
Data filtering	Query plans turn policy into database filters for ORMs and vector stores.	Query rewriting with row, column and cell filtering and masking across named databases, including Snowflake and Databricks.
Audit evidence	Every decision logged with its inputs, the policy version that made it and the outcome, collected across every decision point, searchable and exportable.	Authorization and administration audit reports, with SIEM export.
Standards	Alex Olivier, Cerbos cofounder and CPO, co-chairs the OpenID AuthZEN Working Group. The Cerbos PDP implements the AuthZEN API.	Appears in published AuthZEN interoperability results.
Pricing	Public. $0 proof of concept, Development from $25 a month, Production from $933 a month, Enterprise custom.	Quote only. No public pricing or free tier.
Company	Founded 2021, London.	Founded 2014, Tel Aviv and New York.

Where authorization policy lives in Cerbos and PlainID, and who can review it

A program that ends with thousands of policies is decided by how a rule gets written, checked and approved, and by the record that leaves behind. Sooner or later an auditor asks to see the policy that was in force when something happened, and who signed it off.

PlainID's model starts in its console. Business and security users build rules visually, and Structured Rego is there for teams that want policy as code. A console works well while a few administrators maintain a few hundred rules. It is harder to keep consistent across thousands, and in our conversations with teams that evaluated PlainID, policy authoring and curation at that scale is the gap they raised. Structured Rego helps less than it sounds, because it is a constrained Rego format that depends on PlainID's own metadata and platform objects. Your team learns a Rego dialect, and the code stays tied to the console it came from.

In Cerbos, a policy is a short YAML file. A rule like "analysts can read accounts in their own region" is a few lines a security reviewer can read and check, with the condition written in CEL, the open expression language that Kubernetes and Envoy also use. Policies live in Git or in Cerbos Hub policy stores. Changes go through the pull request review your organization already uses for production code, so every change has an author, a reviewer and a timestamp. Tests run against every change, and a policy that fails them never reaches a decision point. Cerbos Hub records which policy build was live on every decision point at any moment, links each logged decision back to the policy version that made it, and rolls back to an earlier build in one step.

People who do not write YAML every day can work in the Cerbos Hub playground. Its RBAC policy generator builds a starting policy from plain answers about roles, resources and actions, and a permissions matrix shows who can do what. Products that let their own customers manage roles update policy stores through the Hub API.

Where the source of truth is a vendor console, the review history lives in that vendor's interface. A policy file that goes through code review puts the history in a system your auditors already trust, with tests your engineers already run.

Where Cerbos and PlainID run decisions, and what happens when something is down

Both platforms can run decisions in your own infrastructure while the vendor hosts the management layer, and both offer a fully on-premise option. The difference is in what the decision points are and how they behave if something is down.

Cerbos makes every decision inside your infrastructure. Decision points are stateless, so they run wherever the workload does, as a shared service, a sidecar, a DaemonSet, a serverless function or in the browser through WebAssembly, and they scale by adding instances. Cerbos Hub sends policy to them encrypted with each deployment's own credentials, so only that deployment's decision points can read it. If Hub is unreachable, running decision points keep serving the last policy they received, and new ones start from the last built copy. Decisions never wait on a vendor service.

For regulated teams that cannot depend on a hosted control plane at all, Cerbos Hub runs on-premise, including in air-gapped environments. A self-hosted control plane is one of the first requirements large financial services teams put to us.

Authorization across applications, gateways, data platforms and AI agents in one policy set

PlainID covers these layers with Authorizers, prebuilt connectors for application stacks, API gateways, data platforms and AI frameworks. The catalog is broad. Each Authorizer is also another PlainID component to deploy, configure and keep current across your estate.

Cerbos covers the same layers from one set of policies and one audit log, and most of it needs no application code at all.

• Applications call Cerbos through an SDK, one call in place of the permission checks scattered through most codebases.
• API gateways and service meshes use Cerbos Synapse as the external authorization service for Envoy and Istio, so every request through the gateway or mesh is checked.
• Data platforms get Cerbos answering Trino's authorization calls, so a query returns only the rows and columns a person may see, and Kafka's, so only approved services read or write a topic.
• Applications you cannot change are governed at the gateway in front of them, with no code changes.

A role change made once applies on the next request in every one of these places, and every decision goes into the same audit trail.

AI agent and MCP authorization in Cerbos and PlainID

PlainID's agent story leads with discovery, finding agents, tools and data sources before policy is written. It adds Authorizers for agent frameworks and an evaluation of the user's prompt and intent before the agent acts.

Cerbos starts from a different premise. Agents follow access, not instructions. A prompt is a request, not a control, so Cerbos does not try to judge what an agent meant. It decides what the agent is allowed to do at the moment it acts, and that decision holds however cleverly the agent was prompted.

• Tool calls, wherever you enforce them. Cerbos checks each tool call against policy before it runs, down to the arguments the agent passes. You can enforce it in the agent harness through hooks, as with Claude Code, at an MCP gateway or proxy, or in the MCP server itself.
• AI gateways. When the traffic between an application and its models passes through an AI gateway such as LiteLLM or agentgateway, the same policies apply there, to tool calls and to routing decisions such as which models an agent may use. We walk through it in governing AI agents at the gateway.
• AI coding agents. For tools like Claude Code, the hook settings roll out through device management so nobody switches them off locally. We wrote up how that works in governing AI coding agents.
• The person behind the agent. The user's identity can be sent alongside the agent's in the same request, so one decision checks both.
• Retrieval. Query plans filter what an agent can retrieve, including a documented adapter for LangChain with ChromaDB.

PlainID also discovers agents, tools and data sources, which Cerbos does not. Discovery tells you what exists. It does not decide what an agent may do when it acts, and that decision is where the risk sits. With Cerbos you can start in audit mode. Put Cerbos in front of an agent’s tool calls without enforcing anything, and every call is logged with the user behind it, the tool, its arguments and what policy would have decided. Write the policy from that record, switch enforcement on, then tighten access step by step, read-only on financial systems, no shell commands for one team, no payments above a set amount. Each change applies on the next call, without redeploying the agent. A security team can say yes to an agent rollout with controls it can show an auditor, rather than blocking it or signing a risk acceptance.

Data filtering and masking with Cerbos and PlainID

PlainID rewrites database queries to filter rows and mask columns and cells across a list of named data platforms, including Snowflake and Databricks.

Cerbos handles filtering through query plans. The application asks which records a person may see, Cerbos returns a filter derived from policy, and an adapter turns it into a query for the ORM or vector store you already use. The same policy that decides a single check decides the list, so a user never sees a record in a list that they could not open on its own. For a query engine such as Trino, Cerbos Synapse returns row filters and column masks from the same policy and the engine enforces them, so analysts only see the rows and columns they may, with no change to the queries they write.

If you rely on masking inside Snowflake or Databricks specifically, keep it where it runs today. Move the rest of authorization onto one policy set first, which is where most of the duplicated work sits.

Audit logs and compliance evidence in Cerbos and PlainID

Both platforms log decisions. What differs is how quickly you can answer the question every investigation, regulator and auditor asks, show me the policy that was in effect at the time.

Cerbos logs every decision with the request inputs, the policy and version that matched, and the outcome. Cerbos Hub collects those logs from every decision point into one searchable trail. You filter by person, resource, action or decision, follow a logged decision straight to the policy file that produced it, mask sensitive fields before they leave your environment, and export the logs for long-term archiving. Pair that with the Git history of every policy change and Hub's record of which build was live when, and the evidence for an access question is a search, not a three-week reconstruction.

Cerbos itself holds a SOC 2 Type II attestation. The decision and policy change records are what give your own SOC 2, ISO 27001, HIPAA or PCI DSS audits their evidence.

PlainID provides authorization and administration audit reports and sends authorization activity to SIEM tools.

Standards, portability and lock-in

Authorization is a long-lived decision. The policies you write in the first year will still be running in year five, so it matters what they are written in and whether they can move.

Cerbos policies are readable YAML with CEL conditions, a format any engineer or reviewer can open without vendor tooling. The decision engine at the core of the platform, Cerbos PDP, is open source under Apache 2.0, so the component sitting in your request path can be inspected line by line. Cerbos PDP also implements the AuthZEN Authorization API, the OpenID Foundation standard for how applications ask for authorization decisions. Alex Olivier, our cofounder and CPO, co-chairs the AuthZEN Working Group, so read our view on it with that in mind.

PlainID is a proprietary platform. It appears in published AuthZEN interoperability results, and its Structured Rego can be exported, but that export depends on PlainID's metadata and objects. Moving off it later means rebuilding the policy, not copying it.

Cerbos and PlainID pricing

Cerbos publishes its pricing, based on monthly active principals.

• Proof of concept. $0.
• Development. From $25 a month.
• Production. From $933 a month, with unlimited workspaces and tenants and a year of audit logs.
• Enterprise. Custom, adding SSO, self-hosted Cerbos Hub and phone support.

Large programs run on enterprise contracts, and you can model the cost before the first sales call.

PlainID sells by quote, with no public pricing or free tier, and evaluation starts with a demo request. Budget for the rollout too. One independent review describes PlainID as "a heavyweight enterprise platform" and says "the deployment, modeling, and rollout effort is significant" (Start with Identity, June 2026).

Cerbos at enterprise scale

The Cerbos platform runs more than 2 billion authorization checks a month. Utility Warehouse uses it to govern access across 4,500 services and millions of non-human identities. Analysts cover it too, in our posts on Gartner's AuthZEN research, on KuppingerCole's policy-based access management and generative AI defense reports, and more.

When PlainID may still fit

If your program depends on masking inside Snowflake or Databricks today, or on business users authoring every rule in a visual console with no engineering review, PlainID covers those cases directly.

Choosing between Cerbos and PlainID

For an enterprise putting authorization for applications, gateways, workloads and AI agents under one set of rules, Cerbos is the stronger choice. Policy stays readable and reviewable by the teams accountable for it, through the review process you already trust. Decisions run in your own infrastructure, with a control plane you can host yourself. One policy set reaches the gateway, the data platform and the agent. And every decision is on record when someone asks.

As Je Sum Yip, Chief Engineer at Human Managed, put it, "Having to modify authorization is a five-minute job now."

Try Cerbos with your own policies. Your engineers stop rebuilding permission checks in every service, your identity team manages access for people, services and AI agents from one set of rules, and your security team can show who was allowed to do what, and why, whenever an auditor asks. To plan the move from PlainID, book a call with our team and leave with a migration plan your security and audit teams can review.*

Go deeper:

• A CISO's benchmark for authorization maturity (eBook), for scoring where your program stands today
• How Cerbos works