Deep dive: authorization

Authorization: what's real

My view as of October 2026: authorization is where apps leak, it's mostly built in-house because every product's rules differ, and the companies selling it on its own haven't found a business, so the useful pieces are becoming open standards and platform features. The weakest evidence is on how many teams build versus buy; I found no survey at all.

Why permission checks fail most

OWASP's 2025 Top 10 keeps broken access control in the top spot and says every application tested had some form of it. Its list for APIs puts broken object-level authorization at the top: an endpoint that takes a record ID and returns the record without checking it belongs to the caller.

Permissions are harder than sign-in for plain reasons:

• Rules are specific to each product. No standard says "a guest on a shared board may comment but not export", so every app writes its own.
• Checks get re-implemented on every endpoint, each one a chance to forget, and tests rarely cover two tenants trying to reach each other.
• Database rules such as row-level security only work if someone turns them on for every table.

AI app builders show what this looks like at scale. In 2025 a scan of showcase apps built on one popular AI app builder found about 10% of 1,645 had database tables open to anyone, because row-level security wasn't set; the builder disputed fault, saying each customer is responsible for its own app's data. In April 2026 the same company disclosed that a backend change had let any signed-in user read other public projects' chat history and source code for about 11 weeks. Login worked throughout both, and a platform that generates apps decides for every one of them at once whether they start with safe defaults.

Build or buy for authorization

Most teams start with roles in their own code, and that's fine for a while. The pressure comes when customers ask for custom roles, sharing and per-record exceptions, and when several products need one model.

Running an engine yourself costs no licence and means operating a highly available service on every request's path. Most of the work is modelling: deciding what the relationships are and moving existing checks into them. AuthZEN, a request format the OpenID Foundation finalised in January 2026, aims to let apps swap engines without rewriting every call.

The standalone vendors are commercially weak

The companies built to sell authorization on its own have struggled. Oso, which raised about $26 million by its own count, sold the assets of Oso Cloud in October 2026 for a reported $1.9 million (Canadian, according to one outlet), on about $5.3 million of annual recurring revenue and roughly 80 customers. Apple hired Open Policy Agent's creators and several engineers from Styra in August 2025; the project stays open at the CNCF, and Oso, a competitor, wrote that Styra's commercial product was being wound down. AuthZed has announced no round since $12 million in June 2024, Permit.io none since 2024 and Cerbos none since 2023.

As far as I can tell, the reasons are structural: the rules are app-specific, so the modelling stays with the customer; open-source engines set the engine's price near zero; and engineering teams get by with roles in code until switching is no longer cheap.

Platforms are absorbing them

Authorization money arrives when it's sold as part of something bigger. WorkOS bought Warrant in 2024 and FusionAuth bought Permify. CrowdStrike agreed in January 2026 to pay about $740 million for SGNL, pitched as authorization for people, machines and agents. Okta sells OpenFGA as a managed service and AWS sells Cedar, and in 2025 OpenFGA moved up a level at the CNCF while Cedar joined it. The engine you pick will probably be open source or bundled with your identity or cloud vendor, so I'd judge the model, its testing tools and the cost of leaving more than the vendor's runway.

Questions to ask about any permission model

1. Where is the one function every endpoint calls, and what does it return when it doesn't know?
2. Which tests prove one customer can't read another's records, and do they run on every change?
3. When a role or share is removed, how fast does every check see it, cached ones included?
4. Can we answer "who can see this record, and why?" for an auditor in minutes?