Oso

AI agent security and application authorization, honestly reviewed. No marketing fluff — just what it actually does, who it’s for, and what it costs.

TL;DR

• What it is: Oso started as an open-source authorization library and has since evolved into two products: Oso Cloud (hosted authorization-as-a-service for apps using its Polar policy language) and an Agent Security product that monitors and controls what AI agents are allowed to do inside your infrastructure [2][3].
• Who it’s for: Engineering teams at B2B SaaS companies who’ve hit the wall of DIY authorization logic, and teams deploying AI coding agents in production who need audit trails and least-privilege enforcement [1][3].
• Cost: Pricing is not publicly listed — both products require a demo or free trial sign-up. This is enterprise-grade tooling, not a $20/mo SaaS [homepage][4].
• Key strength: The Polar DSL makes expressing complex RBAC, ReBAC, and ABAC policies clean and centralized rather than scattered across application code. Engineering teams report shipping authorization features in roughly 1/10th the usual time [2].
• Key weakness: This is not a self-hostable consumer tool — it’s a developer infrastructure product with opaque pricing. The open-source library exists, but the primary push is toward Oso Cloud. If you’re looking for a managed SaaS you can escape by self-hosting, Oso isn’t the product.
• Caveat on data: The GitHub repository linked in most aggregators (enterprise-oss/osso, 159 stars) is a different project — “Osso,” a Ruby OAuth microservice for SAML SSO. The actual Oso authorization library is separate and has been downloaded millions of times [2]. Worth knowing before you go looking for a self-hosted Docker image.

---

What is Oso

Oso is an authorization platform. The core idea: instead of sprinkling if user.role == "admin" checks across your codebase, you write authorization policy in one place using Polar (Oso’s declarative DSL), and your services query Oso to answer questions like “can this user read that document?” or “which objects can this agent manage?” [3].

The company launched the open-source Oso library in 2020. It was downloaded millions of times and ended up in production at Intercom, Wayfair, Visa, Codecademy, Oxide, Verizon, and Optum — everyone from early-stage startups to Fortune 100s [2]. In 2023 they launched Oso Cloud, the hosted authorization-as-a-service version, which takes the policy engine and turns it into an API you call rather than a library you embed and maintain yourself [2].

More recently the company has pivoted its market-facing message toward AI agent security. The new pitch is “Agent Permissions Posture Management” — the homepage opens with “Your employees ignore 96% of their permissions. Agents won’t.” The idea is that coding agents (Cursor, GitHub Copilot, etc.) inheriting a human’s broad permissions is a security problem, and Oso maps, monitors, and narrows that access automatically [homepage].

In practice, Oso today is two distinct products:

1. Oso for Apps — the authorization engine. You define policies in Polar, sync your authorization data, and call Oso’s API inline wherever your code needs an access decision. Replaces hand-written permission logic and the growing mess it becomes.
2. Oso Agent Security — monitors AI agent sessions, captures every tool call and LLM response, alerts on PII exfiltration or unusual access patterns, and automatically narrows permissions as session risk increases [homepage].

---

Why People Choose It

The case for Oso comes down to one recurring pain: authorization code written by hand doesn’t scale, and every team eventually discovers this the hard way [2][3].

The DIY problem. A microservices.io walkthrough [1] describes the pattern precisely. Services need authorization data that lives in other services. The options — provide it in the token, fetch it at runtime, or replicate it via events — all add complexity, and that complexity compounds as the number of services and relationships grows. Delegating authorization decisions to a dedicated service cuts through that. One centralized policy, queried from any service, rather than a snowflake of conditional logic distributed across the monolith.

The “99% of teams reinvent this” problem. The Oso Cloud GA post [2] states flatly: “99% of engineering teams we meet know only one solution: DIY.” The problem with DIY is that it’s brittle, expensive to change, and the logic is almost never tested in isolation. An engineer at Intercom put it this way: “Oso is A+. As we moved upmarket, being able to implement authz consistently and accurately helped us move faster and resolved a never-ending source of bugs.” [2]

The speed argument. Multiple testimonials converge on the same number: engineering teams using Oso Cloud ship authorization features in roughly 1/10th the time compared to building from scratch [2]. An engineer at Oyster HR: “It used to take us months to add new roles. With Oso we cut that time 10x.” [2]

The AI agent angle. The authzed.com 2024 review [5] provides useful framing on why authorization has gotten harder: breaches increasingly come from broken access control (Kia’s dealer registration bug, Dropbox’s service account compromise, Dell’s partner portal leak). AI agents that inherit broad user permissions introduce the same class of problem but with automated, high-velocity actions. Oso’s agent security product is an early answer to this [homepage][3].

Why not just use OPA or SpiceDB. The authzed.com piece [5] draws a useful distinction between “policy engines” (OPA, Cedar) and “Zanzibar-style” relationship-based systems (SpiceDB, AuthZed). Oso sits somewhere between — Polar supports RBAC, ReBAC, and ABAC in one language. The WorkOS comparison [3] notes that Oso’s Rust-based engine is designed for sub-10ms latency inline on the request path. The Duolingo engineer in the homepage testimonials confirmed: “Oso is a compelling fit because of their singular focus on authz, plus the flexibility of their Polar rule definitions. In twenty minutes we’d managed to define a custom Polar definition to handle our current use case.”

---

Features

Authorization engine (Oso for Apps):

• Polar DSL for expressing RBAC, ReBAC, and ABAC in a single policy file [3][homepage]
• Enforcement APIs: can(user, action, resource)? checks plus list queries for “what can this user see?” [2]
• Sync authorization data into Oso or keep it in your own database — flexible integration model [homepage]
• Idiomatic SDKs in multiple languages [homepage]
• Inline policy tests and regression testing [homepage]
• Logging and debugging built in [homepage]
• Scales to 1M+ requests/sec, 99.99% uptime across 30+ availability zones, <10ms p90 latency [homepage]
• Implementation in Rust [homepage]

Agent Security:

• Real-time capture of every prompt, tool call, and MCP server invocation [homepage]
• Default alerts for PII exfiltration, unusual velocity, access to sensitive resources [homepage]
• Custom rule authoring for your own alert conditions [homepage]
• Automatic permission narrowing as session risk score increases [homepage]
• Deterministic controls for high-risk actions (not just LLM judgment) [homepage]
• Full audit trails with backwards visibility for incident response [homepage]
• Compliance reporting [homepage]

What’s not there: No Docker-compose self-hosted image for Oso Cloud. The original open-source Oso library can be embedded without calling back to a hosted service, but Oso Cloud itself is a managed API. If you need the full suite with audit logs and agent monitoring, you’re calling their cloud [3].

---

Pricing: SaaS vs Self-Hosted Math

This section is short because Oso doesn’t publish prices.

The homepage offers two CTAs: “Book a demo” for Agent Security and “Try for free / Meet an Eng” for Oso for Apps. No pricing tier page exists publicly. The SourceForge listing [4] has no pricing data either.

Based on the customer roster — Roblox, Brex, Clay, Spring Health, Productboard, Intercom, Wayfair, Visa — and the “Book a demo” gate, this is enterprise-grade SaaS pricing. Expect five figures annually once you’re past the free tier.

The self-hosted alternative is the original open-source Oso library. It’s a policy engine you embed directly in your application, runs in-process, and has no per-query cost. You maintain your own data sync and don’t get the hosted scale guarantees. The trade-off: free and fully in your control vs. managed with 99.99% uptime SLA. If your authorization model is straightforward, the open-source library might cover you. If you’re running microservices at scale and need centralized policy management across teams, you’ll eventually look at Oso Cloud or a competitor.

Comparison to building it yourself: The cost framing in [2] is not about SaaS subscription pricing — it’s about engineering time. If rolling your own authorization takes 6 engineer-weeks and breaks every time someone adds a new role, the opportunity cost is orders of magnitude higher than whatever Oso charges. That’s the real math.

---

Deployment Reality Check

If you’re expecting to spin this up with docker compose up on a $6 VPS, that’s not this product. Oso Cloud is an API you integrate into your existing application. Deployment means:

1. Sign up for Oso Cloud
2. Write your policy in Polar
3. Sync your authorization data (users, roles, resources) to Oso
4. Replace inline permission checks in your code with Oso API calls

The WorkOS comparison [3] notes that Oso “does not overlap with what WorkOS provides today” — meaning it doesn’t handle authentication, user management, or session handling. You need an existing identity layer (Auth0, WorkOS, Clerk, your own sessions) before Oso is useful. Oso answers “what can this user do?” — not “who is this user?”

For Agent Security, the deployment reality is less clear from public documentation. The demo-gated flow suggests it involves some kind of agent proxy or SDK instrumentation, but specifics aren’t publicly available.

The open-source library deploys as a dependency in your codebase with gem install oso-oso or the equivalent for your language. No external network calls, no managed service. You get the Polar policy engine locally with full control and zero per-query cost. The trade-off is that you’re responsible for policy management and data sync across services yourself.

Realistic time to integrate Oso Cloud into a working app with a simple RBAC model: a few hours for a developer familiar with the concepts. The microservices.io walkthrough [1] describes integrating Oso into a microservice architecture as substantially less complex than implementing fetch-and-replicate authorization patterns manually.

---

Pros and Cons

Pros

• Polar is genuinely expressive. Unlike hand-written authorization code, Polar can express RBAC, relationship-based access, and attribute-based rules without switching paradigms. The microservices.io deep-dive [1] shows complex multi-service authorization scenarios that would be nightmarish to implement in SQL queries and application code.
• Proven at scale. Intercom, Wayfair, Visa, Verizon — this isn’t a startup running theory in production. The Rust engine delivers <10ms p90 at 1M+ req/sec [homepage].
• Reduces authorization sprawl. Centralizing policy means security teams can audit it, engineers can test it, and changes don’t require hunting across 40 services [2][3].
• AI agent angle is early and real. The “agents inherit your permissions” problem is not hypothetical. Oso is one of the first products explicitly addressing it with deterministic controls rather than prompting [homepage][3].
• Strong testimonials from engineering teams. The quotes across [2] and the homepage are specific, name real outcomes (months to add roles → 10x faster), and come from recognizable B2B companies.

Cons

• No public pricing. “Book a demo” for enterprise tooling means you don’t know what you’re getting into until you’re in a sales cycle. Budget uncertainty is a real cost for small teams evaluating options [4][homepage].
• Oso Cloud is SaaS, not self-hosted. If your threat model includes vendor lock-in or infrastructure control, Oso Cloud doesn’t answer that. The open-source library does, but with significantly reduced scope [3][homepage].
• Authentication is out of scope. Oso does authorization only — you need a separate identity layer. That’s an additional integration and another vendor to manage [3].
• The AI agent pivot muddies the product. The homepage now leads with agent security. The application authorization product — which has years of proven production use — is demoted to a second product track. Unclear how development resources are split or which product gets prioritized [homepage].
• Polar is a new language to learn. It’s expressive once you’re in it, but it’s not SQL or TypeScript — there’s a learning curve, and your authorization policy becomes dependent on Oso’s ecosystem [1][3].
• Agent Security specifics are thin publicly. The features described on the homepage are compelling, but there’s no public documentation on how the agent monitoring layer works architecturally, what the SDK looks like, or what the false positive rate is in practice [homepage].
• Alternatives in this space are active and competitive. SpiceDB/AuthZed, OpenFGA, Cerbos, and AWS’s Cedar are all viable options with more open-source surface area [5].

---

Who Should Use This / Who Shouldn’t

Use Oso if:

• You’re an engineering team at a B2B SaaS company and your authorization logic has become a maintenance problem — roles are hardcoded, permission changes require deployments, and you dread every “can we add a new role?” ticket.
• You’re running more than two services and need consistent authorization decisions across them without implementing fetch-and-replicate patterns yourself [1][3].
• You’re deploying AI coding agents inside your company and need audit trails and least-privilege enforcement before something goes wrong [homepage].
• You have a technical co-founder or engineering team who can own the integration. This is not a no-code tool.

Skip it if:

• You’re a non-technical founder looking to replace a SaaS tool you’re paying for. Oso is authorization infrastructure for developers — it’s something you add to an application you’re building, not something that replaces Notion or Zapier.
• You need simple authentication (login/logout, SSO). Oso doesn’t do authentication at all [3].
• You want fully self-hosted with no vendor dependency. Use the open-source Oso library or look at Cerbos, OpenFGA, or OPA directly.
• You’re a solo developer with a simple application where role checks are two lines of code. The complexity isn’t worth it at that scale.
• You need public pricing to plan your budget. Oso will not help you here until you’re deep in a sales conversation.

---

Alternatives Worth Considering

The authorization-as-a-service space has gotten crowded. From [5] and broader context:

• SpiceDB / AuthZed — open-source, Zanzibar-inspired, relationship-based authorization. More transparent licensing and deployment options than Oso Cloud. The authzed.com piece [5] is a competitor writing about the space, so take framing with a grain of salt, but the technical comparison is useful.
• OpenFGA — Auth0/Okta’s open-source implementation of Zanzibar. Fully open-source, well-documented, good if you want Zanzibar semantics without a managed service.
• Cerbos — open-source authorization service with YAML-based policies. Can be fully self-hosted. Good alternative if you want Oso’s centralized policy model without Oso Cloud dependency.
• OPA (Open Policy Agent) — the CNCF project, widely used in infrastructure access control (Kubernetes, Envoy). More oriented toward infrastructure decisions than application-level RBAC/ReBAC. Policy in Rego.
• AWS Cedar — Amazon’s policy language and engine, open-sourced in 2023. Strong formal verification story. Worth considering if you’re AWS-native.
• DIY with middleware — the baseline everyone starts with and eventually regrets at scale [2]. If you’re small enough that it’s fine, keep doing it.
• Auth0 Fine-Grained Authorization (FGA) — listed as an alternative on SourceForge [4]. Bundles authorization with authentication in the Auth0 ecosystem. Convenient if you’re already using Auth0; vendor lock-in risk if you’re not.

For teams specifically looking at AI agent access control, Oso’s agent security product is among the earliest to market. There’s no clear open-source equivalent with comparable production telemetry at the time of this writing.

---

Bottom Line

Oso is a credible solution to a real problem — authorization logic written by hand is a maintenance trap, and AI agents with inherited permissions are a security trap. The engineering track record is solid: years of production use at recognizable companies, a policy engine built in Rust with 1M+ req/sec throughput, and enough testimonials to believe the “10x faster to add roles” number is grounded in reality. The pivot toward AI agent security is timely and addresses something most companies haven’t wired up yet.

But it’s not a self-hosted tool in the way most readers of this site are probably thinking. You’re not spinning it up to escape a recurring SaaS bill — you’re integrating it into software you’re building to avoid a different kind of bill (engineering time and security incidents). The pricing opacity is a real problem for small teams, and the SaaS model means your authorization logic runs on Oso’s infrastructure, not yours. If that trade-off works for you — managed service, fast integration, proven scale — it’s worth the demo call. If you need full control, the open-source Oso library or Cerbos gives you the same centralized policy model without the vendor dependency.

---

Sources

1. Chris Richardson, microservices.io — “Authentication and authorization in a microservice architecture: Part 5 - implementing complex authorization using Oso Cloud” (December 9, 2025). https://microservices.io/post/architecture/2025/12/09/microservices-authn-authz-part-5-using-an-authorization-service.html

2. Oso Blog — “Oso Cloud is Generally Available”. https://www.osohq.com/post/oso-cloud-GA

3. WorkOS Blog — “Oso for AI Agent Security: Features, Pricing, and Alternatives” (November 4, 2025). https://workos.com/blog/oso-vs-workos-agent-authorization-enterprise-authentication

4. SourceForge — “Oso Cloud Reviews in 2026”. https://sourceforge.net/software/product/Oso-Cloud/

5. Jake Moshenko, AuthZed — “Authorization: 2024 Year in Review”. https://authzed.com/articles/authorization-2024-year-in-review

Primary sources:

• Official website: https://www.osohq.com
• Oso Cloud GA announcement: https://www.osohq.com/post/oso-cloud-GA