Oso
Capability scores
Methodology →- Authentication
- 1.5
- SSO & Federation
- 1.5
- Authorization
- 4.4
- Lifecycle & Provisioning
- 3.0
- MFA & Passwordless
- 1.0
- Governance & Audit
- 3.5
- Developer Experience
- 4.3
- Deployment Flexibility
- 3.5
- Pricing Transparency
- 3.5
- Support & Ecosystem
- 3.5
Scored 0–5 against a published rubric. Independent analysis, no vendor sponsorship.
Overview
Oso provides application authorization built on Polar, its declarative policy language, delivered through Oso Cloud as a managed service that expresses roles, relationships and attributes in a single model. Unlike the policy-as-code tools Cerbos and Open Policy Agent, or the Zanzibar engines OpenFGA and AuthZed, Oso's pitch is one model spanning all three paradigms.
Two changes matter for anyone evaluating it in 2026. The open-source Oso library was deprecated in December 2023, its GitHub repository now titled accordingly, with Oso committing to critical fixes rather than active development. And the company has repositioned around AI agent security: the homepage leads with agent safety, and the published pricing page covers Oso for Agents, while the authorization product, Oso for Apps, carries no public pricing.
What it is good at
Model breadth and data filtering. Expressing RBAC, ReBAC and ABAC together avoids the usual forced choice, and list filtering means you can authorize queries rather than only single decisions. The documentation is honest about scale boundaries in a way competitors rarely are: centralized filtering is documented as optimal up to roughly 10,000 authorized resources per user, with local filtering generating SQL WHERE clauses against your own database for millions. That SQL pushdown is the strongest technical argument for Oso over a pure relationship engine.
Deployment is flexible, with Cloud, Hybrid (local fallback nodes for availability) and fully self-hosted options. Developer ergonomics, documentation and migration guides are good.
Where it falls short
The open-source story has weakened considerably. Teams that chose Oso for an embeddable Apache 2.0 engine now face a deprecated library and a proprietary hosted service, which is a meaningful independence problem next to OpenFGA under CNCF governance or Cerbos.
Pricing for the authorization product is entirely unpublished, and the company's visible commercial focus has moved to agent security, which raises a fair question about roadmap attention for Oso for Apps.
As an authorization-only tool it does nothing for authentication, SSO or MFA. Compliance is thin: SOC 2 with no stated Type, no ISO 27001, and performance claims that are vendor-asserted rather than audited.
Pricing
Oso for Agents is published at 0 dollars for 3 users, 15 dollars per user per month up to 25 users, and custom Enterprise. Oso Cloud authorization pricing is not published and requires a sales conversation.
Best for, and who should look elsewhere
Choose Oso when one unified model across roles, relationships and attributes plus database-level filtering fits the problem, and hosted dependency is acceptable. Choose AuthZed or OpenFGA for Zanzibar-style relationship authorization at scale, or Cerbos for stateless policy decisions. See OpenFGA vs Cerbos.
Bottom line
A capable unified authorization model with genuinely useful SQL-level filtering, now sold by a company whose public attention has moved to AI agent security.
Oso: frequently asked questions
- What does Oso actually sell in 2026?
- Two things, and the emphasis has shifted. Oso's homepage now leads with AI agent security, and the published pricing page covers Oso for Agents rather than authorization: Developer free for 3 users, Growth at 15 dollars per user per month for up to 25 users, and custom Enterprise. A user there is a human invoking agents, with unlimited agents per user. The authorization product still exists as Oso for Apps, with live documentation and an AWS Marketplace listing, but carries no published pricing at all. Anyone evaluating Oso purely as an authorization service should know the company's public shop window is now pointed elsewhere.
- How much does Oso Cloud authorization cost?
- Unpublished. The Oso for Apps page offers a free trial and a demo request with no tiers or figures. Per-tier prices circulating on software directory sites have no primary source, contradict the current live pricing page, and we do not repeat them. Expect a sales conversation.
- Is the open-source Oso library still maintained?
- It is deprecated, not dead. The osohq/oso repository on GitHub carries the title Deprecated: See README, with the deprecation dating to December 2023. Oso states it is not end-of-lifing the library and will continue support and critical bug fixes, and has said a future open-source release is planned. The library is Apache 2.0 with around 3,500 GitHub stars. Oso Cloud itself is proprietary and closed source. Teams that adopted Oso for its embeddable open-source engine should plan on Oso Cloud or an alternative rather than expecting the library to resume active development.
- Is Oso a Zanzibar implementation like SpiceDB or OpenFGA?
- No, and comparing them on Zanzibar fidelity is a category error. Oso is a policy-language system built on Polar, a declarative logic programming language, and supports RBAC, ReBAC and ABAC expressed together in one model. SpiceDB and OpenFGA are relationship databases implementing Google's Zanzibar design with token-based point-in-time consistency. The real axis on which to judge Oso is policy-as-code expressiveness and SQL pushdown for data filtering, not graph consistency semantics.
- How does Oso handle authorizing lists of records?
- Two documented approaches with an explicit threshold between them. Centralized list filtering fetches authorized resource IDs from Oso Cloud and then queries your database, which the documentation says works best up to roughly 10,000 authorized resources per user, at one API call per list operation. Local list filtering has Oso Cloud generate SQL WHERE clauses executed directly against your database, documented to support millions of resources per user. The docs do not name specific supported database engines, so confirm yours during evaluation. This SQL pushdown capability is Oso's strongest technical argument against pure relationship engines.
- How can Oso be deployed?
- Three models: Cloud, fully hosted by Oso; Hybrid, with Oso Cloud as primary plus local fallback nodes for availability; and Self-Hosted, running the full stack in your own infrastructure. There is no separate VPC option, and the documentation publishes no latency service level objectives. Oso's marketing pages claim more than a million requests per second, sub-10 millisecond p90 latency and 99.99 percent uptime across 30 or more availability zones, all vendor-asserted and unaudited.
- Is Oso secure and compliant?
- Oso states it is SOC 2 certified and operates a trust centre, but its security page does not specify Type I or Type II, so we do not assert Type II. No ISO 27001, GDPR or HIPAA claim appears there. On vulnerabilities, the osohq/oso GitHub repository has no published security advisories, no CVE surfaced in the National Vulnerability Database, and no CISA KEV entry. As with any closed-source hosted service, absence of published CVEs is limited evidence.
- What are the best Oso alternatives?
- AuthZed SpiceDB or OpenFGA if you want a relationship-based engine following Zanzibar, particularly where sharing and hierarchy dominate. Cerbos if you want stateless policy-as-code decisions with no central data store. Open Policy Agent if you need general-purpose policy beyond application authorization. Oso remains a reasonable choice where the requirement is one unified model across roles, relationships and attributes plus database-level filtering, and where its shift in focus toward agent security is not a concern.
More Authorization vendors
All Authorization →- AuthZed4.3/5
- Styra / Open Policy Agent4.3/5
- OpenFGA4.2/5
- AWS Verified Permissions4.1/5
- Warrant (WorkOS)4.1/5
Related on Start with Identity
- VendorAserto
strong
- Comparisonauthzed-vs-openfga
AuthZed (the company behind SpiceDB) and OpenFGA are the two leading open implementations of Google Zanzibar-style relationship-based access control (ReBAC). Bo
- VendorAWS Verified Permissions
strong_contender
- GuideFrom RBAC to ReBAC: when and how to migrate
RBAC is great until your customers need to share individual resources, not entire roles. The moment you find yourself adding a 50th role named like `editor_for_
- GuideImplementing Attribute-Based Access Control (ABAC): A Practical Guide
Design and deploy attribute-based access control with policy engines, XACML, dynamic authorization, and practical guidance on when ABAC beats RBAC.
- GuideImplementing RBAC in the Enterprise
A hands-on guide to implementing Role-Based Access Control in the enterprise, covering role modeling, role mining, role hierarchy design, RBAC vs ABAC considera
By SWI Community Team · Last evaluated 2026-09-20
Independent, community-driven analysis. No vendor sponsorship. Compiled from public research and community input and verified on a best-effort basis, so details may be incomplete or out of date. Scores are opinions, not advice. Trademarks belong to their owners; mention does not imply affiliation or endorsement. See the full disclaimer, or send corrections to community@startwithidentity.com.