Enforcer

Authorization tools, grouped by how they actually work

Most lists in this category rank tools one to twenty, which is close to useless because the tools are not doing the same job. A Zanzibar engine and an identity platform are not competing for the same slot in your stack; picking between them is picking an architecture.

So this is grouped by model. Find the group that matches your problem, then the trade-off inside it is a real comparison.

We make one of these. It is in the fourth group and its limitations are listed with the rest.

1. Relationship engines (Zanzibar-style)

You store relationships between subjects and objects as tuples, and the engine answers by walking that graph. Google's Zanzibar paper is the origin. The defining strength is reverse lookup: "list every document this user can read" is fast and correct.

The defining cost is the same for all of them: the engine needs its own copy of your relationship data, so every write goes to your database and again to the authorization store, and the two can drift.

Tool	Shape	Consider it when
OpenFGA	CNCF, open source, hosted option via Auth0 FGA	You want the Zanzibar model with a neutral governance story
SpiceDB / AuthZed	Open source with a commercial cloud	You want the most mature tooling in this group
Permify	Open source	Smaller, simpler, less ecosystem
Ory Keto	Open source, part of the Ory stack	You are already running Ory for identity

Pick this group if list filtering is your hard requirement. Do not pick it if you cannot commit to keeping a second datastore honest.

2. Policy engines (policy-as-code)

You write rules in a policy language, hand the engine the facts at request time, and it returns a decision. Nothing is stored, so there is nothing to sync. The cost is the mirror image of group one: because the engine holds no data, answering "list everything this user can see" is awkward, and teams end up building a translator from policy to SQL.

Tool	Shape	Consider it when
Open Policy Agent	CNCF, Rego, open source	You want one engine across infrastructure and application. Rego is the most common complaint
Cerbos	Open source, YAML policies, stateless	You want the shortest path to a running PDP
AWS Cedar / Verified Permissions	Open source language, AWS-managed service	You are on AWS and want the managed version
Casbin	Library, many languages	You want authorization in-process with no service to run

3. Commercial platforms over an engine

These wrap one of the above with a UI, policy management, and an SDK story. You are buying the operational layer rather than the algorithm.

Tool	Shape	Consider it when
Permit.io	Hosted, UI-led, MCP gateway	Non-engineers need to see and change permissions
Oso	Polar policy language, Oso Cloud	You want a purpose-built authorization language rather than Rego
Aserto	Hosted, decision logs a first-class feature	Auditability is the driver
Styra	The commercial company behind OPA	You have standardised on Rego and want support

4. Identity platforms that include authorization

Sign-in and permissions from one system. The pitch is that the decision point already knows who the caller is, so you are not passing identity around between services. The trade-off is coupling: your authorization model now lives wherever your identity does.

Tool	Shape	Consider it when
Auth0 / Okta	CIAM plus FGA, agent identity in early access	You already run Auth0 and want to extend it
WorkOS	Enterprise SSO plus FGA plus agent registration	Selling to enterprises and you need SSO anyway
Descope	CIAM with agentic identity features	Flow-builder approach to auth appeals
Keycloak	Open source, self-hosted, Red Hat	Self-hosting is a requirement and you have the ops budget
Frontegg	CIAM for B2B SaaS	You want end-user-facing admin screens out of the box
Enforcer	Identity, policy and audit in one service. Decisions return a reason and the rule id	You want one system, and a refused call to say why. No list filtering, same gap as group two

5. Agent runtimes

A newer group. These sit between an AI agent and the tools it calls, holding credentials and deciding whether a given tool call proceeds. They overlap with authorization but solve a different problem: connecting an agent to third-party APIs on a user's behalf.

Tool	Shape	Consider it when
Arcade.dev	Tool-calling runtime, token vault, hosted execution	Your problem is connecting an agent to many third-party SaaS APIs
Microsoft Entra Agent ID	Agent identity in Entra, GA April 2026	Microsoft shop
Google Agent Identity / Gateway	Part of Gemini Enterprise, April 2026	Google Cloud shop

If you are a Microsoft or Google shop at enterprise scale, groups one to four are largely a question of whether you want something your platform vendor does not yet cover. That is an honest thing to check before evaluating anyone in this list.

How to actually choose

Do you need "list everything X can see"? If yes and it is core, you want group one and you accept the dual write. Nothing else in this list does it well, us included.
Is your policy about attributes rather than relationships? Amounts, times, states, KYC status. Group two or four.
Do non-engineers change the rules? Group three, or group four with an admin surface.
Are you buying sign-in at the same time? Group four, or you will be integrating two vendors.
Is the caller an AI agent? Then ask a question most of this list answers badly: does a refusal tell you why. An agent that gets a bare deny retries the same call.

Last updated 11 September 2026. Grouped by architecture rather than ranked, because the groups are not substitutes. Enforcer is in group four and we have said where it does not fit. Corrections welcome. Deeper comparisons: OpenFGA, Cerbos, Permit.io. Docs at docs.instruxi.dev.