The Feature You'll Rebuild Three Times: Authorization at Scale: Pavan Kulkarni at ERC

This post is part of our ERC 2025 Recap series. Read our full recap post here.

The Question That Sets the Stage

What's that one feature every B2B SaaS application must build and rebuild at least three times as it scales? It's not billing. It's not onboarding. It's authorization—the feature that quietly powers every button click, every API call, and every enterprise deal.

Pavan Kulkarni, Engineering Manager on WorkOS's enterprise team, used this opening question to frame his talk at Enterprise Ready Conference 2025.

You can watch the full session below: 

‍

His answer revealed a fundamental truth: authorization isn't just another feature you can bolt on and forget. It's central to your entire product, evolving alongside your customer base and fundamentally reshaping your technical architecture at each stage of growth.

Why Enterprises Care About Authorization

The distinction between authentication and authorization matters more than many early-stage companies realize. Authentication establishes who you are. Authorization determines what you can do.

Enterprises won't buy software if you cannot guarantee that the right people have the right access at the right time. Access control defines trust at enterprise scale. Pick any compliance acronym—SOC 2, HIPAA, ISO certifications—and you'll find authorization at the core.

As your product matures, you attract larger customers with complex organizational structures: departments, subdivisions, lines of business, and subsidiaries. Their access management hierarchy maps one-to-one with their organization hierarchy, and they expect your application to represent this complexity.

Perhaps most critically, enterprises expect you to expose all authorization controls through their identity systems—Microsoft Entra, Okta, Google Workspace—because that's where they manage everything else. What makes authorization unique is that it doesn't live in an adjacent layer like most enterprise features. It's woven into the fabric of your entire product.

The Figma Case Study: Eight Years of Authorization Evolution

Pavan walked through a detailed case study using Figma as a representative example of how authorization problems evolve at scale.

Day One: Primitive Permissions

On launch day, most SaaS companies start by selling to individual users. For Figma, early authorization was primitive but functional. Files were shared resources with two roles: owners could add, edit, or delete files and manage collaborators, while collaborators had a subset of these permissions.

Year Two: Organizations and Roles

Once you start selling to enterprises, individual designers paying with their own credit cards need to be pulled under centralized management. Companies build the concept of "organization" and introduce two new user types: admins who manage the organization and billing admins who handle payments and compliance.

To support this, companies must list every action possible within their platform and express them as atomic responsibilities abstracted into roles. This helps the product team—as new features get added, they can assign them to existing roles, and every customer automatically receives the new capabilities.

Year Three: User Groups

At enterprise scale, multiple design teams collaborate with multiple engineering teams on different projects. The collaboration boundary evolves from individual users to groups of users.

Introducing groups fundamentally changes the authorization system. When a user gets added to or removed from a group, the system must grant and revoke privileges correctly. Conflict resolution becomes necessary: what happens when a user explicitly receives a role and also inherits that role from group membership?

Year Four: Custom Roles and Role Inheritance

Larger companies have multiple teams owning sub-responsibilities. One team handles payment methods while a separate compliance team manages regulatory requirements. Companies realize it's impossible to predict every permutation of responsibilities and express them as static roles.

The solution: let customers hand-pick permissions to create custom roles. But this creates maintenance overhead, requiring role inheritance where updates to leaf node roles automatically bubble up to all dependent custom roles.

Year Six: IDP Automation and the 2×2 Matrix Problem

Larger customers want to automate everything from their identity provider. If one admin leaves or has their credentials compromised, the company locks itself out, requiring manual intervention from support.

Unfortunately, there's no standard for automating access management. It can happen through SSO or directory sync, represented through groups or user attributes. This creates a 2×2 matrix of implementation approaches, and different customers prefer different combinations based on their internal IDP configuration.

Companies face two hard choices: pick one combination and force every customer to adapt (adding friction and risking security incidents), or invest multiple years supporting all variations across all major identity providers.

Year Six+: Nested Resources and 3D Permission Graphs

Core product users request better abstractions like workspaces and projects, while companies launch new products. These changes fundamentally break the authorization stack.

Until this stage, the permission graph was two-dimensional. Someone logged in as an admin was an admin everywhere. Introducing nested resources creates a three-dimensional permission graph—someone is an organization admin, workspace collaborator, and project member simultaneously depending on context. The permission graph grows exponentially in complexity.

Everything built so far won't scale. A complete re-architecture becomes necessary, introducing patterns like resource-scoped RBAC or ReBAC. But these solutions require steep learning curves and ongoing synchronization overhead. Company-wide migrations take over a year, but product development can't wait.

Year Seven+: Attribute-Based Access Control and Policies

Customers from finance and healthcare bring unique requirements. The system becomes context-sensitive—it's no longer just about who you are, but when, where, and under what conditions you perform actions.

A finance company might request: "Block all exports during financial close week." A healthcare customer might require: "Patient records are only accessible on-site or from allow-listed IP addresses."

Once policies exist, customers request manual override capabilities for edge cases, requiring workflow engines on top of policy engines. The authorization system evolves from a static access check to a dynamic decision-making system, requiring another re-architecture to ensure scalability.

Year Eight+: Enterprise Grid

Fortune 50 companies introduce subsidiaries that already use your platform as separate organizations. Microsoft wants to sign a deal but also wants to bring GitHub and LinkedIn into one unified IDP system.

This requirement breaks the fundamental assumption that "organization" cleanly maps to "customer." Any solution requires reaching out to every product and feature team to update their implementations. Companies like GitHub and Slack spent multiple years solving this problem.

Key Takeaways

Every stage in authorization evolution fundamentally changes product and technical architecture. Unlike other enterprise features that sit in adjacent layers, authorization is woven through the core application. One small bad decision compounds over time, slowing enterprise adoption.

Off-the-shelf models like RBAC, ABAC, FGA, and ReBAC address specific problems but don't solve the entire lifecycle. Companies need authorization systems that evolve gracefully alongside their product and customer base. And automating access management from identity providers remains a mess with no unified consensus—every application implements a different combination.

The Timeline Is Compressing

Figma's journey from day one to Fortune 50 customers took approximately eight to ten years. But today's rapid-scale companies reach Fortune 50 stage in one to two years, making the authorization evolution problem three to four times harder.

The AI Agent Challenge

AI agents introduce entirely new complexity. Pavan highlighted two emerging patterns.

Agent Access for Automation

Applications now receive requests to allow agents to log in on behalf of users and perform automated actions. This creates a new type of actor that must behave like a user but operates at machine speed.

Agents should not inherit the entire permission graph of the user they represent. They must receive scoped, just-in-time privileges following the principle of least privilege. And AI agents must not be able to escalate their own roles, change permissions, mint tokens, or change credentials.

AI-Native Features and RAG Authorization

If your application builds AI-native features with local RAG systems that index customer documents, authorization becomes critically important. Enterprises will abandon products if AI features access resources the user doesn't have permission to view.

You're fundamentally trying to marry a deterministic authorization system with a probabilistic LLM model. You must enforce guardrails programmatically—fetching relevant document IDs, applying the authorization layer to filter out inaccessible documents, and only then sending the filtered set to the LLM.

More interesting problems continue emerging. LLMs have memory—what happens when a user loses access to a document the model previously processed? Nobody has definitive answers yet.

How WorkOS Is Thinking About Authorization

For over seven years, WorkOS has worked on enterprise problems, integrating with tens of thousands of customers. For over two years, the team has worked on AuthKit, their user management product, understanding what rapidly scaling companies need.

The goal: abstract authorization jargon and acronyms into a simple, unified interface that gracefully evolves with customers. Whether you're handling basic role checks today or building complex attribute-based policies tomorrow, the system should grow with you rather than requiring complete rewrites at each stage.

Pavan Kulkarni is an Engineering Manager on the enterprise team at WorkOS. His talk at Enterprise Ready Conference 2025 drew on years of observing how authorization systems evolve across thousands of customer implementations.

Read our full ERC Recap 2025 post here.