The Company That Followed the Permission Slip

A prospect had spent twelve months rebuilding application authorization. Oso had built an alpha product for infrastructure security. The conversation should have been a polite demo and a follow-up email. Instead, the prospect asked whether Oso could help with the permission system. More prospects asked much the same thing. Graham Neray and his team did the expensive, sensible thing: they threw away the code.

That decision, described in Oso's 2021 Series A announcement, gave a New York startup its real subject. Authorization sounds like an obscure cousin of login. Login establishes that you are you. Authorization decides whether you may read this document, edit that field, invite a colleague, or see a row in a database. Every growing application acquires these questions. Many answer them with little if statements tucked into dozens of services, each convinced it is the final authority.

The useful question was in the room

Neray and Sam Scott founded Oso in 2018. Scott, a cryptographer and Rust enthusiast, served as co-founder and CTO until 2025. The first idea was broad: make backend security easier for developers. Its customers narrowed the brief. They were already spending months on the humbler matter of permission checks. An engineer's complaint was more informative than a founder's elegant architecture diagram.

The replacement was an open-source authorization library with a policy language called Polar. Its Rust engine let developers describe roles, relationships, and attributes in one place. A rule could say that a member may view a project, an editor may change it, and an owner may invite others. Applications would still enforce the answer, but the meaning of the rule no longer had to be reinvented in every controller. Oso also supplied guides, a debugger, and an Authorization Academy. Teaching the category was part of selling into it.

The company raised an $8.2 million Series A led by Sequoia in 2021. Two years later, a $15 million Series A-1 led by Felicis supported Oso Cloud. The cloud service stores policy and permission data, answers authorization checks over an API, and can return the resources a user is allowed to see. For a SaaS product with tenant roles and shared projects, the advantage is operational as much as conceptual: one policy can govern several applications or microservices. Oso reported more than $25 million raised after the 2023 round.

The small question with a large bill

What did authorization cost before a specialist arrived? The answer is usually hidden in engineering calendars. Productboard described rules scattered through a Ruby monolith, then a growing need for custom roles, field controls, and consistent decisions across microservices. Its engineers considered building a new service themselves. They instead stress-tested vendors against millions of data points in one tenant and chose Oso. In its published case study, Productboard says production checks stayed below 10 milliseconds at the 95th percentile. That is a customer's result, not a promise that every deployment will match it.

Tamr's comparison is even more tactile. Its head of engineering said the team built an Oso sample application in an afternoon, versus several days with other options it evaluated. After going live in 2024, Tamr reported that the work of maintaining its previous self-hosted Keycloak setup - roughly a quarter to a third of one DevOps engineer's time - had fallen close to zero. Duolingo reported that permission changes which once took days could be made in minutes. The pattern is clear: permission work carries a maintenance bill long after the first check returns true.

Oso's competitors include a company's own permission code, OpenFGA, SpiceDB, and policy systems built around Open Policy Agent. These are serious alternatives with different shapes. Oso's claim is that its application-focused language, managed service, list filtering, and developer tools let a team express a messy product model without turning every permission change into a small migration project. It has also added Local Authorization for cases where application data should stay in an existing database rather than be copied wholesale into Oso Cloud.

Then the user stopped being human

The AI agent did not create overpermissioning. It made the old bargain uncomfortable. A human employee may have access to hundreds of actions and use only a handful; judgment, fatigue, and routine limit the rest. An agent can inherit the same credentials, call tools repeatedly, and make a mistake at machine speed. Oso's 2026 study with Cyera analyzed 2.4 million workers and 3.6 billion application permissions. Across its 90-day window, 96% of granted permissions were unused. The study covers a slice of organizations that already invest in security, so its number should not be treated as a universal census.

That research explains Oso's move into agent security more persuasively than any science-fiction warning. Oso for Agents inventories agent activity, records approved sessions, flags risky tool use or sensitive information, and lets security teams apply rules to agent behavior. Its public product screens show an agent catalog and session timeline. The company launched an early coding-agent release with Tailscale Aperture as its first gateway integration. Its current product page describes broader discovery, monitoring, detection, control, and reporting. Buyers should check the scope of each integration and deployment before treating the whole catalog as one switch.

In an April 2026 essay, Neray offered a sharper example: a lawyer’s agent reads a client email, then tries to send mail. A blunt rule might ban sending altogether. His proposed rule would allow a reply to people already in the thread and deny a message to an outsider. The permission narrows because of what the agent has already seen. Oso says it demonstrated this behavior in a Claude session. That is a useful design idea; a buyer would still need to test how it works with the tools and data in their own environment.

The customer also changes. Oso Cloud speaks mainly to developers and platform teams building SaaS applications. Agent visibility and controls speak to security and IT teams who need to know what tools are running across laptops, browsers, and gateways. Oso's published agent pricing is $0 for a three-user Developer tier, $15 per human user per month for a Growth tier of up to 25 users, and custom Enterprise pricing. The meter counts people invoking agents, rather than each agent they use. Enterprise lists cloud or on-premises deployment; other features vary by tier.

A playbook written in permissions

The move worth copying starts before buying software. Ask which access decisions your team keeps rebuilding, then draw the line between identity and permission. Put the rules somewhere engineers can read and test them. For agents, audit the permissions a human actually used, issue a separate identity, begin with read-only work, log tool calls, and add write access a task at a time. Oso and Cyera recommend this sequence in their research. It is useful even if another vendor or an internal service enforces the checks.

There are limits. A small application with simple roles may be better served by a few well-tested checks. A company that cannot operate a policy service, map its data, or enforce decisions at every relevant action will not get safety merely by purchasing one. Agent session visibility depends on traffic being routed through the supported path. The point is not that every application needs Oso. It is that authorization stops being a dull detail when a product grows, or when a new actor can spend the permissions its human owner never touched.

Oso followed that detail from an awkward prospect meeting to a cloud service and then to agents. The original pitch did not survive. The customer's question did.