Inside Brex’s Journey to Smarter, Faster Authorization with Oso

The Modern Finance Software Platform

Brex powers financial operations for 30,000+ companies across 120 countries. It combines a corporate card and high-yield banking with software for expenses, bill pay, accounting, and travel, giving finance teams real-time visibility and control. Brex’s AI-driven automation and service remove manual expense and accounting work, saving 11 million employee hours. 

Customers include ServiceTitan, Anthropic, Wiz, Robinhood, Five Guys, and Sonos. Many companies start with Brex early: 75% of Y Combinator startups use Brex.

Billions of Decisions, Zero Tolerance for Failure

Brex’s Identity & Access Management (IAM) group owns authentication and authorization across a large, microservices-based platform. Justin Cohler, Staff Engineer and team lead alongside Abhidnya Patil, Senior Software Engineer, are core members of the team. Their brief is simple and unforgiving: keep authorization fast, correct, and consistent everywhere.

Authorization isn’t a feature. It’s the safety of our customer accounts.

‍‍Justin Cohler, Staff Engineer 

A bypass would be catastrophic: cross-tenant data exposure, fraudulent approvals, and regulatory violations. Because every user interaction traverses the authorization path, amounting to billions of transactions every day, the team targets a minimum of sub-10 ms P50 decision latency, so permissions never become the bottleneck.

The Breaking Point of Build-Your-Own Authorization

Brex’s authorization journey followed a familiar pattern: simplicity up front giving way to complexity at scale.

An early graph database prototype was built to capture relationships between users, roles, and permissions. It worked conceptually but failed in practice. It was too abstract, too hard for developers to reason about, and too slow to evolve with product needs.

The team replaced that approach with a custom-built role-based access control (RBAC) library, consolidating permissions into a single repository that handled standard roles like admin, employee, and bookkeeper. For a time, that served them well. But as Brex added new products e.g., separate Card and Banking offerings, roles multiplied, with parallel permission sets that had to interoperate. As Brex moved upmarket, enterprise customers required fine-grained, resource-aware permissions: hierarchical visibility (manager vs. admin), budget ownership and child budgets, and “zero/partial/full” data views determined by relationships between roles and resources. 

The complexity didn’t stop there. Brex also needed to onboard third-party partners such as travel providers, credit card processors, and other financial platforms. Each required its own authorization model to govern what data and actions they could access. Every new integration introduced yet another branch of logic to maintain, multiplying the surface area for bugs and inconsistencies.

To keep up, the team extended their RBAC framework into a broader system spanning dozens of microservices. Maintaining performance under those conditions required aggressive caching with hand-tuned invalidation logic. Each authorization session had to resolve the current state of users, accounts, and roles from different services, cache that data locally, and invalidate it instantly when anything changed. The caching system itself became an intricate subsystem comprising multiple layers, complex invalidation triggers, and service-specific edge cases designed to preserve sub-10ms latency across the authorization path.

Over time, this codebase ballooned into thousands of lines of authorization logic scattered across services, with overlapping responsibilities and brittle interdependencies. Any small feature change risked unintended regressions elsewhere. The system worked, but it had reached the limits of safe maintainability. Two particularly hard problems—listing actors and listing resources (list filtering)—became the canaries for both correctness and speed at scale.

We needed to break this cycle: simplify our model, centralize policy logic, and maintain millisecond performance without sacrificing security and carrying the weight of a bespoke framework. That’s when we started looking for an alternative.

Justin Cohler, Staff Engineer

The Search for a Smarter Model

With the limits of their in-house system reached, the Brex IAM team began searching for a platform built to handle both RBAC and relationship-based authorization (ReBAC) at scale. They needed a solution that could model the demands of their growing business, spanning customers, users, resources, time zones, and organizational hierarchies, not just roles and permissions.

The team evaluated several options, including Zanzibar-style systems. Those platforms offered flexibility, but at a cost: they were too generic, too abstract, and required mapping every authorization rule into tuple relationships that few developers could reason about.

The new system had to be reliable and efficient above all. It also needed to be a developer-friendly solution, freeing engineers to implement permissions safely and easily, so they could focus on improving the product.

The team prioritized four things:

1. ReBAC support to model real-world relationships beyond roles.
   
2. Performance predictability, matching or beating their sub-10 ms P50 latency and tightening tail behavior at P99.
   
3. Developer ergonomics, including APIs and naming conventions that mirrored how Brex engineers already reasoned about permissions.
   
4. A clear migration path that would let them transition to the new system safely without freezing development.

When Brex tested Oso, the difference was immediate. The nouns and verbs in Oso’s SDKs mirrored their internal APIs, letting engineers map existing permissions directly instead of translating them into new abstractions. 

The API language felt native to how we already think. We recognized that familiarity reduces migration friction and makes it feasible for product teams, not just us in IAM, to author and test policies.‍

Abhidnya Patil, Senior Software Engineer

Before making a decision, the team built a lightweight proof of concept with a simplified RBAC version running in Brex’s own environment to validate performance and integration points. Once that baseline worked, they extended it to cover list_resources and other resource-centric operations, confirming that Oso could handle their most demanding use cases before committing to full rollout.

At that point, the decision was less about whether Oso could meet technical requirements and more about how quickly it could help Brex consolidate years of scattered logic into a single, centralized policy layer.

Rolling Out Change Without Breaking the Path

Brex’s move to Oso wasn’t a single cutover; rather it was  an incremental rollout designed to build confidence. The IAM team executed authorization checks through their legacy framework and Oso in parallel. This allowed them to compare latency, correctness, and tail behavior at production scale before shifting all traffic over.

Performance remains a non-negotiable benchmark. Brex measures authorization in milliseconds and Oso’s architecture has to sustain that load across thousands of checks per second—about a quarter-billion decisions daily across tens of millions of facts (the platform’s authorization-relevant data including unique roles, relationships, attributes, and context). 

Early tests hit the sub-10 ms P50 target. When P99 latencies spiked under skewed data distributions, Oso collaborated closely with Brex to tune index statistics, cutting tail latency by roughly 5x. 

Operational stability is another test. Oso developed an asynchronous client with built-in retries and timeouts making the system more resilient to transient network or dependency issues.

Now live on a growing share of Brex traffic, Oso is simplifying the team’s day-to-day work. By handling the hard parts of authorization, such as policy logic, performance, and safety, Oso lets product engineers ship features faster with less risk.

Thousands of lines of bespoke caching and invalidation logic are targeted for retirement as services move onto centralized Polar policies. The team continues to monitor latency and error budgets closely while cleaning up legacy code paths that no longer need to exist.

Daily standups and direct Slack access with Oso’s engineers meant we solved issues in hours, not days. That level of collaboration built real confidence in production.

Abhidnya Patil, Senior Software Engineer

Meeting Demands Today and Tomorrow with Oso

Brex’s implementation of Oso is still expanding, but the impact is already visible and the long-term upside is clear.

• Cleaner architecture: Brex is retiring thousands of lines of legacy authorization code, consolidating logic into a single, auditable permissions layer that enforces access control across all microservices, APIs, and AI models.
  
• Developer self-service: Oso’s familiar SDKs and policy language lets engineers write and test their own policies, reducing bottlenecks on the IAM team.
  
• Consistent performance: Authorization now runs with stable P99 latency regardless of query complexity, meeting sub-10 ms targets and keeping decisions predictable under load. Performance gains come without compromising correctness or security.
  
• Partnership in delivery: Oso’s professional services team worked directly in Brex’s codebase, helping refine policies to meet new customer demands.
  
• Future-proof flexibility: With Oso proven at scale, Brex has confidence it can handle any new use case or enterprise integration while delivering richer features faster across its financial platform.

Oso gives us leverage. To replicate its functionality and stability ourselves, we’d need about four times our current team. And we’d be writing infrastructure code instead of shipping features.

Justin Cohler, Staff Engineer

Next up for Oso at Brex: finer-grained controls for legal entities and multi-parameter decisions—“not just can this user do this thing, but can this user do this thing to this thing. It's a whole level of additional complexity that we know we can handle with Oso” Abhidnya explains.

Brex also has the option to use local authorization in select services if needed, though Oso’s current performance may make that unnecessary.

Lessons for Engineering Leaders

From their experiences of authorization and Oso, Justin and Abhidnya share these lessons:

1. Make authorization first-class. You can’t bolt it on later. Design for least privilege, tenant isolation, and auditability from day one. “Remember, authorization bypasses are catastrophic,” says Justin.
   
2. Beware the “lava flow pattern.” Incremental patches to homegrown libraries create forks and backward-compatibility deadweight. “Choose a system that covers the hardest cases out of the box,” Abhidnya advises.
   
3. Optimize for tails and resilience, not just averages. P50 is table stakes. Engineer for P90 as a minimum.
   
4. Prioritize developer ergonomics. Clear nouns, policy tooling, and intuitive APIs drive adoption across many teams, determining how quickly and safely they move.
   
5. Buy where specialization compounds. With a lean IAM team and enterprise scope, partnering with an authorization specialist accelerates features, reduces risk, and avoids rebuilding a second company’s worth of infrastructure.

Oso has allowed us to deliver a more powerful product without needing any additional engineers.

Matthew Fanto, Platform Security Manager at Brex

What’s Next?

Brex’s journey shows how quickly authorization can evolve from a homegrown utility into critical infrastructure. By partnering with Oso, they’re transforming a complex, bespoke system into a unified, high-performance foundation built for market expansion and serving the most sophisticated enterprises. Brex operates at financial scale, where precision and trust are non-negotiable.

If you’re facing similar challenges with fragmented authorization or scaling fine-grained access control, talk to an Oso engineer. Our team can help you centralize policy logic, cut complexity, and build the foundation for secure, developer-friendly authorization at enterprise scale.