Cerbos vs Axiomatics

If you are comparing Cerbos with Axiomatics, you are probably making authorization a governed, central service in a regulated organization. Maybe a law now requires you to show why each person could see each record. Maybe authorization is scattered across application code and API gateways, and an audit or a modernization program has made that visible.

Whatever you choose will hold the access rules for hundreds of applications, gateways and AI agents for years, so the question is less which product can make a decision and more who can write, review and prove the rules once they are in it.

Both products externalize authorization and make policy based decisions at runtime. They differ in the language the policy is written in and who can read it, how a change is tested before it ships, how far one set of policies reaches, whether the control plane can be hosted for you, and what each platform costs to buy and to staff.

Cerbos vs Axiomatics at a glance

Question	Cerbos	Axiomatics
What it is	An authorization management platform. Decision points run next to every workload, Cerbos Hub manages policy, testing and audit, and Cerbos Synapse brings in context and connects gateways, data platforms and AI agents.	An authorization platform built on the XACML standard, made up of Authorization Hub for policy administration, the Access Decision Service for decisions, and attribute connectors.
How policy is written	Short YAML policies with conditions in CEL, an open expression language Kubernetes and Envoy also use. An engineer, a security reviewer or an auditor can read them.	ALFA, Axiomatics' policy language, which compiles to XACML 3.0. Axiomatics' own blog notes ALFA is not yet a ratified OASIS standard.
How a change is tested and released	Test suites live next to the policies. Cerbos Hub runs them before it builds each deployment and only builds when they pass.	Testing runs in a separate product, Axiomatics Policy DevOps, built on Gradle and JUnit, according to Axiomatics' documentation (October 2026).
Where it runs	Decision points in your infrastructure. Cerbos Hub hosted, or on-premise and air-gapped for enterprise customers.	Decision service and Authorization Hub both self-managed in your own network. No hosted option.
Coverage	One set of policies across applications, Envoy and Istio, Kafka, Trino, Kubernetes admission control, MCP servers and AI coding agents.	Applications, API gateways and enterprise integrations through enforcement SDKs. Axiomatics' product pages describe agent and MCP authorization.
Standards	Cerbos PDP implements the AuthZEN Authorization API. Alex Olivier, Cerbos cofounder and CPO, co-chairs the OpenID AuthZEN Working Group.	XACML 3.0. David Brossard, Axiomatics' CTO, also co-chairs the AuthZEN Working Group, and Axiomatics' product page says its enforcement interface is built on AuthZEN.
Pricing	Public, by monthly active principals. $0 proof of concept, Development from $25 a month, Production from $933 a month, Enterprise custom.	Not published.
Company	Founded 2021, London.	Founded 2006, Stockholm. A Leonardo company since December 2025, per Leonardo's 2025 annual report.

Where authorization policy lives in Cerbos and Axiomatics, and who can read it

Once authorization is a central service, the rules stop belonging to one team. Security approves them, identity governs them, and an auditor will eventually ask to see the rule that was in force on a particular day. So the policy has to be something those people can read without a translator.

Axiomatics helped shape policy based access control. Its founders contributed to the XACML standard, and its policies today are written in ALFA, a language Axiomatics created as a shorter way to write XACML. ALFA compiles to XACML 3.0, the standard's XML format, and that is what the decision service evaluates. The language is precise and expressive, and it asks a lot of whoever writes it. Attributes are declared with identifiers and categories, conditions work on bags of values, where one attribute can hold several, with functions such as stringOneAndOnly, and rule combining algorithms decide what happens when rules disagree. Teams we talk to often say the people who can read and change these policies are a small group of specialists, and job postings for Axiomatics developers ask for years of XACML and ALFA experience.

Here is one rule, a manager approving purchase orders up to their own limit in their own department, written in ALFA.

policy purchaseOrders {
   target clause attrs.resourceType == "purchase-order"
   apply denyUnlessPermit
   rule managerApprovesWithinLimit {
       target
           clause attrs.actionId == "approve"
           clause attrs.role == "manager"
       permit
       condition stringOneAndOnly(attrs.department) == stringOneAndOnly(attrs.poDepartment)
              && doubleOneAndOnly(attrs.poAmount) <= doubleOneAndOnly(attrs.approvalLimit)
   }
}

And the same rule in Cerbos.

apiVersion: api.cerbos.dev/v1
resourcePolicy:
 version: default
 resource: purchase_order
 rules:
   - actions: ["approve"]
     effect: EFFECT_ALLOW
     roles: ["manager"]
     condition:
       match:
         all:
           of:
             - expr: P.attr.department == R.attr.department
             - expr: R.attr.amount <= P.attr.approvalLimit

In Cerbos, the policy is the file. Conditions are written in CEL, and the structure is short enough that a security reviewer can read it in a pull request. Policies live in Git or in Cerbos Hub policy stores, so every change has an author, a reviewer and a timestamp in a system your auditors already trust. Everything is denied unless a rule allows it, and a deny rule wins over an allow for the same role, so most of what XACML spreads across combining algorithms is decided by the shape of the policy itself. At the scale of thousands of policies, that difference decides who can maintain them.

People who do not write YAML every day work in the Cerbos Hub playground, where a permissions matrix shows who can do what before a change is proposed and a trace shows which rule produced each decision.

Testing and releasing authorization policy in Cerbos and Axiomatics

A policy change is a production change. The question for a CISO or a platform lead is what stops a wrong rule from reaching a decision point.

Axiomatics' documentation describes its Authorization Hub as covering most of the policy lifecycle, and says requirements gathering and testing need tooling outside it. Testing is a separate product, Axiomatics Policy DevOps, built on Gradle and JUnit, so policy tests are Java test code your team writes and runs in its own pipeline.

In Cerbos, tests are part of the policy. A test suite is a YAML file next to the policies, listing principals, resources and the decision you expect for each action. Cerbos Hub runs the suites before it builds each deployment and only builds when they pass, so a failing policy never reaches a decision point. Hub records which build was live on every decision point at any moment and rolls back to an earlier build in one step. The same suites run locally and in any CI system, and the Cerbos agent skills let an AI coding agent draft a policy and its tests from rules written in plain words, for a reviewer to approve.

Tests written in the same format as the policy are tests the policy owner can read, which is what makes them evidence rather than engineering detail.

Decision time attributes in Cerbos and Axiomatics

Policy based decisions depend on attributes, the person’s department and clearance, the record’s owner and classification, the time and the channel. Both platforms fetch the ones a request does not carry from the systems that hold them, when the decision is made. Axiomatics does it with attribute connectors to LDAP and Active Directory, SQL databases and HTTP services.

In Cerbos, the application sends the attributes it already has, and Cerbos Synapse fetches the rest from the identity provider, database or API that owns them, with caching set to how often each one changes. A department change in the directory applies on the next decision, as we show in looking up identity attributes at decision time. Synapse is also what Envoy, Istio, Kafka and Trino call for their decisions, so the layer that brings in attributes is the same one that connects your gateways and data platforms to the policies.

Where Cerbos and Axiomatics run decisions, and where the control plane runs

Regulated buyers usually ask two things, whether decisions run inside their network, and whether the control plane can too.

Axiomatics is self-managed. Authorization Hub is deployed on your Kubernetes cluster from Axiomatics' registry with a license file, and the Access Decision Service runs as a Java service, centrally, as a sidecar or at the edge. The decisions and the management stay in your network, and your team runs both.

Cerbos makes every decision inside your infrastructure too. Decision points 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. If Hub is unreachable, running decision points keep serving the last policy they received, and new ones start from the last built copy. Cerbos Hub is offered hosted, so there is nothing to install to start, and on-premise, including air-gapped, for enterprise customers who need the control plane in their own network.

On-premise, the two look alike, with the control plane and the decisions inside your network. The difference is the hosted option. Axiomatics does not offer one, and with Cerbos Hub hosted, a team that does not need the control plane in its own network has nothing to install or operate before the first decision.

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

A central authorization service is only as useful as its reach, because the same rule has to apply everywhere the data can be reached. Axiomatics reaches applications and API gateways through enforcement SDKs and integrations, and its product pages describe authorizing agent tool calls and MCP traffic.

Cerbos covers each of these layers from one set of policies and one audit log, and most of it needs no application code.

• Applications call Cerbos through an SDK, one call in place of permission checks scattered through the codebase.
• API gateways and service meshes use Cerbos Synapse as the external authorization service for Envoy and Istio.
• 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.
• Kubernetes admission requests follow the same policy language.
• Applications you cannot change are governed at the gateway in front of them, with no code changes.
• AI agents have every tool call checked against policy before it runs, down to the arguments, through an MCP server or gateway, or through the hooks of coding agents like Claude Code, as we describe in governing AI coding agents. The person behind the agent can be checked in the same decision.

Agents follow access, not instructions, so a prompt is never the control. Put Cerbos in front of an agent's tool calls without enforcing anything at first, and every call is logged with the person behind it, the tool, its arguments and what policy would have decided. Write the policy from that record, then narrow it, read-only on financial systems or a cap on payment amounts, and each change applies on the next call.

Data filtering and the "who can access this" question in Cerbos and Axiomatics

Two questions come up in most evaluations. Which records can this person see, so a list or a search only returns those. And who can access this record, for entitlement reviews.

Axiomatics answers both with its Contextual Authorization Query, a reverse query that evaluates policy with some values left open. It is mature, and Axiomatics holds patents on the approach.

Cerbos answers the first with query plans. Ask which records a person may read, and Cerbos returns the conditions as a filter your data layer applies, with documented adapters for Prisma, Drizzle, Mongoose, Convex, SQLAlchemy and LangChain with ChromaDB. On Trino the filter is applied by the query engine itself. For the second question, Cerbos checks each candidate user against the record, drawn from the people who could plausibly hold access, such as the members of a tenant or a department. That covers access reviews for a record or a team, and for an estate-wide entitlement report, keep the report where it runs today and move the runtime decisions first.

Audit logs and compliance evidence in Cerbos and Axiomatics

What a security team needs is a fast answer to "show me the policy that was in effect at the time", for any decision, months later.

Axiomatics’ product pages say every decision is logged, versioned and traceable, and can be streamed to a SIEM.

A Cerbos decision log records the request inputs and the outcome of every decision, linked to the policy version that made it. Cerbos Hub collects those logs from every decision point into one searchable trail, filtered by person, resource, action or outcome, and you can export them, encrypted, into your own archive or SIEM. To see why a decision came out the way it did, open the same request in the playground against the same build, and the execution trace shows every rule and condition it went through. Hub keeps logs for three months on Development, a year on Production and as long as you need on Enterprise. Because one set of policies covers applications, gateways, data platforms and AI agents, their decisions are in the same trail, next to the Git history of every policy change.

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

XACML obligations and Cerbos policy outputs

XACML lets a policy attach obligations and advice to a decision, such as "log this approval" or "show this message". An enforcement point that cannot fulfill an obligation must not act on the decision.

Cerbos rules can return outputs, a value computed in CEL and returned next to the allow or deny, when a rule matches or when its condition is not met. A rule can return "log this approval with the approver and the amount" on an allow, or "this needs a second approver" on a deny, and the enforcement point acts on it. Cerbos does not enforce a must-fulfill contract on the enforcement point, so the code that reads an output decides what to do with it. In XACML too, it is the enforcement point that carries out an obligation, so the logic that acts on it already exists in your applications.

Standards, portability and lock-in with Cerbos and Axiomatics

XACML is an open OASIS standard, and that is Axiomatics' case for portability. The portability is real in principle and narrower in practice. ALFA, the language your team actually writes, is Axiomatics' own and not a ratified standard, and policies lean on attribute identifiers and connectors configured in Axiomatics' platform. OASIS is working on the next version of XACML, which adds JSON and YAML formats.

Cerbos policies are readable YAML with conditions in CEL. The decision engine at the core of the platform, Cerbos PDP, is open source under Apache 2.0, so the component in your request path can be inspected line by line, and the policies carry their own test suites, which are the most portable description of what your rules do.

On the request side, both vendors back AuthZEN, the OpenID Foundation's Authorization API for how enforcement points ask for decisions. Cerbos PDP implements it. Alex Olivier, our cofounder and CPO, and David Brossard, Axiomatics' CTO, are both among the co-chairs of the AuthZEN Working Group, so read either vendor's view on it with that in mind. A standard request format means your enforcement points do not have to change if your decision service does.

Axiomatics has been part of Leonardo, the Italian aerospace, defense and security group, since December 2025, and describes itself as a core Zero Trust component of Leonardo's cybersecurity platform. Ask any vendor how its roadmap fits your sector over the life of the contract.

Cerbos and Axiomatics pricing

Cerbos publishes its pricing, based on monthly active principals, the people and services that get an authorization decision in a month.

• Proof of concept. $0, with a week of unified audit logs.
• Development. From $25 a month, with three months of audit logs.
• Production. From $933 a month, with unlimited workspaces, decision points and tenants, and a year of audit logs.
• Enterprise. Custom, adding SSO, self-hosted Cerbos Hub, custom audit log retention and phone support.

Axiomatics does not publish pricing, and there is no free tier to try it on.

The license is only part of the cost. Model the people too. A platform whose policy language needs specialists needs those specialists for as long as you run it, for every new rule, every audit question and every attribute source. A platform whose policy your existing engineers and reviewers can read spreads that work across the teams who already own the applications.

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 and on KuppingerCole's policy based access management, API security and generative AI defense reports.

When Axiomatics may still fit

If a regulator or contract requires XACML itself, or your entitlement reporting depends on asking who can access every resource across the whole estate at once, Axiomatics answers those directly. Keep that report where it runs, and move the runtime decisions to Cerbos service by service, which the migration guide walks through.

Moving from Axiomatics to Cerbos

There is no converter from ALFA or XACML to Cerbos, and a line by line conversion would carry XACML's structure into a place that does not need it. Teams write each rule from its intent, with a test that proves it, and run Cerbos beside Axiomatics until every decision matches. Most of the work is listing the attributes your attribute connectors resolve today and deciding whether the application or Cerbos Synapse supplies each one. The migration guide maps every XACML concept, including each combining algorithm, and translates a rule with passing tests.

Choosing between Cerbos and Axiomatics

For an organization making authorization a governed service across applications, gateways, data platforms and AI agents, Cerbos is the stronger choice. The policy is something your engineers, security reviewers and auditors can all read, and it is tested before it ships. One set of policies reaches the gateway, the data platform and the agent, with every decision in one trail linked to the policy that made it. The control plane runs in your own network or is hosted for you, and the price is published.

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, or book a call to map your Axiomatics setup to Cerbos with our team and leave with a migration plan your security and audit teams can review.

---

Go deeper:

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