Notifications
Clear all
Topic starter
06/06/2026 1:37 am
TL;DR: Flat roles, permission flags, and patched RBAC break down as multi-tenant B2B apps add workspace hierarchies, enterprise IdP sync, and AI agents that need resource-scoped access, according to WorkOS. The governance problem is no longer just role design; it is whether authorisation can express bounded access without spawning a combinatorial role explosion.
NHIMG editorial — based on content published by WorkOS: How to build flexible authorization for multi-tenant B2B SaaS
By the numbers:
- FGA provides sub-50ms p95 response times and strong consistency, meaning role changes take effect immediately.
Questions worth separating out
Q: How should security teams model authorization for multi-tenant SaaS products?
A: Security teams should model authorization around the product’s real resource boundaries, then attach roles to those boundaries instead of to the tenant root alone.
Q: Why do flat roles break down in enterprise B2B applications?
A: Flat roles break down because enterprise customers rarely fit a single access pattern.
Q: What is the difference between org-wide RBAC and resource-scoped authorization?
A: Org-wide RBAC answers who can do broad actions across a tenant, while resource-scoped authorization answers who can act on a specific object or subtree.
Practitioner guidance
- Map your real access boundaries before adding roles Start with the tenant, workspace, project, or branch boundaries that actually define who can act on what.
- Replace role explosion with permission reuse Convert repeated job-specific checks into stable permission slugs, then attach those permissions to roles instead of cloning new roles for every request pattern.
- Scope AI agents to a resource subtree Do not let an agent inherit the full user token when its task only touches one project or branch.
What's in the full article
WorkOS's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of permission and role configuration in the dashboard for enterprise tenants
- Implementation details for resource types, resource instances, and assignments in a live hierarchy
- Code-level JWT and API check patterns for enforcing org-wide and resource-scoped access
- Incremental rollout guidance for replacing patched RBAC checks without a full rewrite
👉 Read WorkOS's guide to flexible authorization for multi-tenant B2B SaaS →
B2B SaaS authorization hierarchies: are your controls keeping up?
Explore further
06/06/2026 2:50 am
Flat RBAC is a tenant-level assumption, and that assumption fails under resource-scoped product design. The model was designed for access decisions that map cleanly to job function, not to workspace, project, or branch-level variation. Once customers expect different rights on different objects, the governance problem becomes role multiplication and policy drift. Practitioners should treat that as a structural limit of the model, not a tuning problem.
A few things that frame the scale:
- FGA provides sub-50ms p95 response times and strong consistency, meaning role changes take effect immediately, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to GitGuardian and CyberArk research.
A question worth separating out:
Q: How should teams scope AI agents without over-granting access?
A: Teams should scope AI agents to the smallest resource set needed for the task and avoid reusing the human account’s full access token. The agent’s entitlement should reflect the job it will perform, not the full breadth of what the user could do manually across the tenant.
👉 Read our full editorial: Flexible authorization for B2B SaaS and AI agent scoping
