Multi-tenant permissions need scoped roles, not global role sprawl

At a glance

What this is: This analysis shows how Slack, Notion, and Linear avoid role explosion by scoping permissions to workspaces, teamspaces, and teams instead of expanding one global role list.

Why it matters: It matters because the same design pattern applies to NHI, autonomous, and human access programmes whenever a central model cannot safely absorb tenant-specific exceptions.

👉 Read WorkOS's analysis of scoped roles and IdP syncing for multi-tenant apps

Context

Multi-tenant authorization breaks down when one shared role catalogue has to satisfy every customer. In practice, the first signs are familiar: global Admin, Member, and Viewer roles start accumulating customer-specific exceptions, and visibility expands faster than governance can keep up. That creates the core governance gap for multi-tenant permissioning, especially in SaaS products that must balance enterprise customization with predictable access control.

The article’s primary lesson is that permission scope, not role count, is the real control boundary. Slack, Notion, and Linear each use a different structure, but they all reduce blast radius by pushing access decisions closer to the tenant, workspace, teamspace, or team that actually owns the risk.

Key questions

Q: How should teams prevent role explosion in multi-tenant applications?

A: Start with a small set of reusable permission primitives, then scope custom roles to the tenant, workspace, or team that owns the access decision. Keep global roles simple and reserve tenant-specific exceptions for the narrowest boundary that matches the business need. This keeps authorization understandable and easier to audit.

Q: Why do tenant-scoped roles work better than one global role catalogue?

A: Tenant-scoped roles keep exceptions local. A global catalogue turns every customer-specific requirement into a permanent application-wide object, which widens blast radius and makes reviews harder. Scoped roles preserve a clean default model while still allowing differentiated access where the risk actually lives.

Q: How do SCIM and SSO mappings affect multi-tenant access governance?

A: They automate entitlement assignment, which is useful only if the upstream directory groups are well designed. If group structure is messy, SCIM and SSO simply distribute bad access faster. Teams should validate group-to-role mappings as part of governance, not treat synchronization as proof of least privilege.

Q: What is the difference between global roles and scoped delegation?

A: Global roles apply everywhere, while scoped delegation limits the same authority to a defined boundary such as one tenant, workspace, or team. Scoped delegation is safer in multi-tenant systems because it reduces accidental overreach and makes each grant easier to reason about during review or incident response.

Technical breakdown

Why global role lists create role explosion

A flat role model works only while every customer accepts the same coarse permissions. Once one tenant needs billing access without user administration, or audit visibility without mutation rights, new roles begin accumulating faster than the model can stay intelligible. The architectural problem is that each new role becomes globally visible, even when it only exists to satisfy one tenant. That turns authorization design into a catalog-management problem instead of a control problem. The practical answer is to separate reusable permission primitives from tenant-scoped assignment logic.

Practical implication: break roles into atomic permissions first, then decide which of those permissions can be safely assembled per tenant.

How scoped delegation changes the control boundary

Scoped delegation means the same permission set can be valid in one organizational boundary and irrelevant in another. Slack’s workspace-scoped roles, Notion’s teamspace overrides, and Linear’s team owners all follow this pattern. The key technical idea is inheritance with exception handling: defaults set the baseline, and the scoped object narrows or extends access inside its own boundary. That keeps authorization decisions local to the object that owns the risk, rather than centralizing every exception in one global role registry.

Practical implication: define the smallest administrative boundary that still matches the business use case, then bind permissions to that boundary rather than to the whole tenant.

Why identity provider mapping is the scaling mechanism

Manual role assignment does not scale because it depends on humans remembering who should hold which entitlement. Group mapping via SCIM or SSO turns directory state into a provisioning signal, allowing access to follow the customer’s existing identity structure. That does not remove governance requirements. It shifts them upstream into group design, role mapping, and boundary validation. Without that discipline, automation simply accelerates bad assignments. The strongest multi-tenant models therefore treat the IdP as the source of membership intent, not as the source of least-privilege design.

Practical implication: align tenant roles to directory groups deliberately, and review whether group structure still reflects business boundaries before enabling automation.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Scoped roles are the real control, not role count. The article shows that the failure mode is not “too many roles” in the abstract. The failure is a globally shared role model that cannot contain tenant-specific exceptions without widening blast radius. That is the same structural issue IAM teams see when entitlement design cannot absorb variance cleanly. The practitioner conclusion is to govern scope first, then role naming.

Tenant-local delegation is a better authorization primitive than central exceptions. Workspace-scoped, teamspace-scoped, and team-scoped permissions all reduce the number of people who can accidentally overgrant access. That mirrors a basic NHI governance lesson: the farther an access decision travels from the object it protects, the harder it is to explain, audit, and contain. The practitioner conclusion is to place control at the narrowest durable boundary.

Least privilege becomes enforceable only when access is bound to context. A single global role cannot express “can manage invoices for this tenant but nothing else” without leaking capability into other tenants. This is the same access-pattern problem that shows up in NHI programmes when one credential is reused across multiple operational contexts. The practitioner conclusion is to make context a first-class part of the authorization model.

IdP synchronization is necessary, but it is not governance by itself. SCIM and SSO mappings can automate assignment, yet they also propagate directory mistakes at speed if the upstream groups are sloppy. That means the control plane must include both role engineering and group governance. The practitioner conclusion is to treat directory mapping as an enforcement layer, not as proof of correct entitlement design.

Multi-tenant permission design is converging on structural boundaries. The common pattern across Slack, Notion, and Linear is not a larger role catalog but a stronger boundary model. That aligns with OWASP-NHI and ZT-NIST-207 thinking: access should be narrow, contextual, and auditable at the point of use. The practitioner conclusion is to redesign authorization around scope, not around endless role proliferation.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• 15% of commit authors have leaked at least one secret in their contribution history, which shows that access governance fails when human process and technical controls drift apart.
• For a broader view of how secret sprawl compounds authorization risk, see Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Scoped authorization is becoming the default pattern across identity programmes. Multi-tenant SaaS is not the only place where broad role catalogues break down. The same boundary-first logic applies to NHI and human access programmes whenever central governance cannot safely encode local exceptions. Teams that still rely on one universal role model should expect pressure to move control closer to the tenant or workload boundary.

Role engineering now sits between identity governance and application design. Access models fail when engineering teams treat authorization as a late-stage product feature rather than a structural control. The strongest programmes will align directory structure, permission primitives, and application boundaries before custom access multiplies beyond review capacity. For a related control baseline, see the OWASP Non-Human Identity Top 10.

For practitioners

• Inventory role explosion hotspots Map every global role that exists for a single customer or team, then identify which permission atoms could be moved into tenant-scoped roles instead of remaining globally visible.
• Define the smallest durable boundary Choose the authorization boundary that actually owns the risk, such as tenant, workspace, teamspace, or team, and make that boundary the unit for delegated access.
• Separate permission primitives from assignment logic Keep permission atoms reusable, then build tenant-specific roles from those atoms so custom access does not contaminate the global model.
• Govern SCIM and SSO mappings as entitlement policy Review directory groups, mapped roles, and fallback defaults together so identity provider sync does not turn stale group structure into persistent over-privilege.

Key takeaways

• Multi-tenant authorization fails fastest when a global role list absorbs every customer exception.
• Scoped delegation reduces blast radius because the control boundary stays aligned to the entity that owns the risk.
• Directory sync scales access assignment only when group design and role design are governed together.

Key terms

• Scoped Delegation: Scoped delegation is the practice of limiting an administrative or permission grant to a defined boundary such as one tenant, workspace, or team. It keeps authority local to the object that owns the risk, which makes access easier to audit, revoke, and explain during reviews or incidents.
• Role Explosion: Role explosion happens when a shared authorization model accumulates too many narrowly tailored roles, often because every customer or team request becomes a permanent global role. The result is a harder-to-understand access catalogue, broader blast radius, and weaker governance over who can do what.
• Permission Primitive: A permission primitive is the smallest meaningful unit of capability in an authorization system, such as viewing invoices or managing users. Well-designed systems build roles from these atoms so access can be composed cleanly, without forcing every customer-specific need into a monolithic global role.
• IdP Group Mapping: IdP group mapping links directory groups from an identity provider to application roles or access scopes. It scales assignment, but it only works well when the upstream groups are cleanly designed and reviewed, because the mapping will faithfully propagate whatever structure the directory contains.

Deepen your knowledge

Scoped delegation and boundary-based authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing access governance for multi-tenant systems, the course is a practical next step.

This post draws on content published by WorkOS: Multi-tenant permissions done right: What Slack, Notion, and Linear can teach us. Read the original.