Rbac From The Ground Up Solving For Autonomy Vs Control

How we built RBAC that scales for the enterprise Announcing our Series F . Learn more

Infrastructure

How we built RBAC that scales for the enterprise

We built our permission model to scale from 3-person teams to 5,000-person enterprises, with nested teams, restricted environments, and granular API keys.

Authors

Matt Howard

Samiksha Pal

Rachel Rapp

Last updated April 23, 2026

Share

RBAC from the ground up: Solving for autonomy vs. control There are two things every organization needs from its inference platform, and they pull in opposite directions. The first is individual autonomy: engineers and researchers need to deploy models, iterate on training jobs, and push changes to workloads without waiting on an admin or filing a ticket (in other words: speed matters). The second is access control: security teams need defined roles and audit trails, platform teams need the ability to take swift action during incidents, and IT needs to be able to provision and deprovision access predictably. Lock everything down, and you've protected your production environment but created a bottleneck for every engineer trying to ship. Open everything up, and you have velocity but no governance. Aside from sacrificing one for the other, the shortcut is to take a high-autonomy solution and retrofit access controls. This is what most inference providers do, and we’ve heard the pain from customers who left them. Instead, we built Baseten's permission model from the ground up: a single organization (previously called a “workspace”) containing multiple teams — each with isolated resources and access controls — while billing, user provisioning, and compliance remain unified at the top. Because scalable RBAC goes beyond permission models and teams, we also provide environment-level restrictions and granular API keys scoped to specific teams, environments, and models. ✕ Baseten's permission model, with the “organization” as the outer container holding unified billing and organization-member roles (Admin and Member), and two isolated team containers nested beneath it. Each team owns its own members, models, Chains, secrets, API keys, environments, and training projects. The result is an RBAC system where a three-person startup and a 5000-person enterprise (and everything in between) can operate without friction, and where the controls necessary at enterprise scale don't come at the cost of the developer experience and velocity our users demand. In the rest of this blog, we’ll explain the design choices we made to build RBAC that scales for the enterprise and what we learned along the way. RBAC day 0: Where companies start You (should) build what your users need. When you're building an AI platform and your earliest users are individual developers and small teams, a flat, user-centric model is the obvious design choice. At that stage, everyone in an organization shares the same context, the same models, and the same level of access. Our first permission model at Baseten reflected that: ✕ A flat permission model, with the organization at the top and members, billing, models, training projects, environments, API keys, and secrets all sitting at the same level. And as a tree: Organization ├── Members ├── Billing ├── Models ├── Training projects ├── Environments ├── API keys └── Secrets In this model, every resource lives under a single organization. Autonomy and velocity are prioritized: an engineer can deploy a model, call it, and share it with a teammate directly. The model starts breaking when a company has multiple teams working independently. Senior engineers have the same permissions as their interns, and even the research team with experimental models can make changes directly to production. As user bases grow, you need a permissions structure that accounts for complex, many-to-many relationships and can accommodate organizations of any size and structure. An aside on building holistic primitives à la Stewart Butterfield Before getting into the technical design, we want to explain why we approached building RBAC the way we did (skip to the next section if you just want the structural details). Before Slack launched, Stewart Butterfield wrote an internal memo making the case for why Slack would win. His argument was about organizational primitives, not features. Communication, context, and how work flows through a company needed to be first-class concepts in Slack. We're selling a reduction in information overload, relief from stress, and a new ability to extract the enormous value of hitherto useless corporate archives. We're selling better organizations, better teams. That’s a good thing for people to buy and it is a much better thing for us to sell in the long run. We will be successful to the extent that we create better teams. The same logic applies here: it would have been straightforward to ship RBAC feature-by-feature with model-level permissions, an environment lock, and a second type of API key. But the result would have been patchwork and would require custom configuration every time an organization changes shape. (Believe it or not, most inference providers’ RBAC — if not nonexistent — is that patchwork. More on that below in “RBAC in the inference landscape”.) We wanted to build an access control model where the answers to "who can modify production?" and "what happens when we spin up a new team?" fall naturally out of the system's structure. It takes longer to build, but it’s an investment that scales. The design decision: Where do groups go in the hierarchy? When you add a grouping to a permission model, the first question seems simple: does it go above the organization, or below it? Above would mean that a single company would have multiple organizations on Baseten, each with their own top-level settings, signup and login, and billing. You're essentially creating multiple independent organizations and giving users a way to switch between them. This is faster to build, and some hyperscalers use this model. The disadvantage is that users end up with a fragmented experience: multiple logins, multiple API key contexts, and admins lose the ability to see what's happening across their teams from a single view. Putting a “team” group below the organization means the organization stays supreme; users belong to the organization, and also to one or more teams within it. Billing, membership, and top-level oversight stay at the organization...