Cerbos scope permissions and tenant isolation in multi-tenant SaaS

At a glance

What this is: This article explains how Cerbos uses scopes, role policies, and scoped resource policies to enforce tenant isolation in multi-tenant SaaS while preserving tenant-specific customisation.

Why it matters: It matters because IAM and IGA teams building SaaS platforms need authorization boundaries that prevent cross-tenant access without making every tenant change a manual policy rewrite.

Context

Multi-tenant SaaS creates a simple-sounding but difficult authorization problem: each tenant must be isolated without turning policy management into a brittle, centralized bottleneck. The core issue is not just whether users can be denied access, but whether the authorization model can express tenant boundaries, role variation, and auditable decisions at the same time.

The article frames Cerbos as a policy layer for that problem, using hierarchical scopes, role policies, and scoped resource policies to keep tenant-specific permissions inside platform-defined guardrails. That makes the discussion relevant to SaaS identity governance, where the boundary between flexibility and overreach is often the difference between safe customization and cross-tenant exposure.

Key questions

Q: How should security teams enforce tenant boundaries in multi-tenant SaaS?

A: They should require tenant context to travel with every authentication event, API call, and database query, then deny any request that cannot be tied to a known tenant. The goal is not just to authenticate the user, but to ensure every authorization decision is tenant-scoped end to end.

Q: When does scoped resource policy delegation become too risky in multi-tenant SaaS?

A: It becomes risky when tenant-authored allows can take effect without approval from the parent scope. At that point, tenant policy is no longer just a constrained customisation layer. It becomes a second source of authority that can widen access, weaken isolation, and create cross-tenant exposure if the model is misused.

Q: What signs indicate multi-tenant authorization is failing in practice?

A: The main warning sign is when tenant roles or scoped rules begin to reintroduce actions that the platform layer never meant to expose. Another signal is when access decisions depend on too many exceptions, because that usually means the policy model is no longer expressing the tenant boundary cleanly. Auditable denials should outnumber unexpected approvals.

Q: What should SaaS teams verify before letting tenants manage their own access policies?

A: They should verify that tenant policy management can only narrow permissions within a platform-approved ceiling, and that every allow decision is traceable to a parent policy. If tenants can define access freely, the question is no longer operational convenience. It is whether the product still enforces a shared security boundary across all customers.

Technical breakdown

How scoped policies preserve tenant boundaries

Cerbos scopes let policies be organised hierarchically, typically with a root layer for platform-wide rules and child scopes for individual tenants. In multi-tenant SaaS, that means the same resource type can be governed once at the platform level and then refined per tenant without flattening everything into one monolithic rule set. The key mechanism is evaluation order: a request is checked against the relevant scope, and the result depends on how scoped role and resource rules combine. This structure matters because tenant isolation is not a single control, it is a policy boundary that must survive customisation.

Practical implication: define the platform-wide tenant boundary first, then let scoped policies narrow access without ever widening it.

Why role policies are narrower than parent roles

Role policies move permissions into a role-centric model instead of attaching every rule directly to the resource. In Cerbos, a scoped role policy can inherit from parent roles, but it can only narrow what those parents already allow. That is an important governance pattern for SaaS platforms because it lets tenant-specific roles exist without becoming a route to privilege expansion. Implicit deny also matters here: if an action is not listed, it is not granted. For multi-tenant systems, that prevents a tenant admin role from silently acquiring capabilities that belong only at the platform layer.

Practical implication: treat tenant roles as constrained subsets of platform roles, not as independent permission sources.

How parental consent controls tenant-authored resource policies

Scoped resource policies add another layer of control, but their behaviour changes depending on scope permission mode. With SCOPE_PERMISSIONS_REQUIRE_PARENTAL_CONSENT_FOR_ALLOWS, a tenant-scoped allow only takes effect if the parent policy also permits that action. That is the safeguard that stops tenants from writing policies that expand beyond platform intent. The more permissive override mode gives tenants autonomy, but it also shifts more trust into tenant-authored policy. For SaaS HR or finance data, that distinction is the difference between delegated policy management and delegated exposure.

Practical implication: use parental consent mode when tenant policy authorship must remain bounded by platform-approved maximum permissions.

Threat narrative

Attacker objective: Exploit policy flexibility to obtain actions across tenant boundaries or on resources that should remain platform-restricted.

1. Entry occurs through a tenant-specific access request against a shared SaaS authorization layer, where the first risk is whether scope resolution correctly identifies the tenant boundary.
2. Escalation happens if tenant-authored role or resource policies can widen access beyond parent policy intent, especially when scoped allows are not constrained by platform guardrails.
3. Impact is cross-tenant data exposure or unauthorized action on resources such as salary records, leave requests, or tenant settings.
4. The attacker objective is to turn tenant flexibility into permission expansion without triggering a visible policy violation.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

NHI Mgmt Group analysis

Multi-tenant SaaS authorization fails when tenant flexibility outruns the platform boundary. The article shows that hierarchical scopes are only useful if the parent policy remains the true ceiling on tenant-specific access. Once tenants can widen permissions rather than narrow them, the authorization model stops behaving like governance and starts behaving like delegation without guardrails. Practitioners should treat the platform maximum as the non-negotiable control plane.

Scoped role policies are most valuable when they preserve least privilege by construction. Cerbos's inheritance model is useful because it allows tenant-specific roles without forcing a fresh permission model for every customer. The important governance point is that tenant roles must be subsets of platform roles, not parallel sources of authority. That keeps role design scalable without giving each tenant a separate path to privilege creep.

Parental consent for scoped allows is the control that separates customisation from overreach. Tenant-authored resource rules are attractive in multi-tenant SaaS, but the article makes clear that override semantics can weaken isolation if they are chosen casually. Scoped allow without parental consent: This is the specific governance concept that should stay front of mind, because it defines whether tenant policy is constrained administration or tenant-level authority expansion. Practitioners should design for bounded delegation, not policy freedom.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

Tenant isolation is a governance design problem, not just an authorization feature. Multi-tenant SaaS teams should assume that every custom role, scoped allow, and delegated policy authoring path is a potential boundary test. If the platform cannot prove that tenant-specific access remains subordinate to root policy, then the authorization layer is already carrying more trust than it can safely absorb.

Scoped delegation is only durable when the platform retains the last word. The practical lesson for IAM and IGA teams is that self-service policy management must be bounded by a higher-order control, not by tenant preference. That principle applies equally to human admins and machine-driven administration flows because the risk is the same: authority drift across a shared boundary.

For practitioners

• Define the platform ceiling first Set root policies so every tenant-specific rule is evaluated against a fixed maximum permission boundary. Keep tenant scopes for narrowing access only, especially on shared objects such as salary records and tenant settings.
• Use tenant scopes for subtraction, not expansion Model scoped role policies so each tenant role is a constrained subset of a parent role. Verify that missing actions remain denied by default and do not reappear through inherited permissions.
• Require parental consent for tenant-authored allows Where tenants can author scoped resource policies, use a mode that forces platform approval of every allow decision. Reserve override-style scope permissions for cases where tenant autonomy is acceptable and explicit.
• Test cross-tenant conditions with negative cases Exercise policy evaluation against resources from other tenants, departments, and scopes to confirm that tenantId and attribute checks block unintended access paths. Include deny-focused test cases, not just happy-path approvals.
• Log and review scope decisions at the boundary Keep audit records of every tenant-scoped allow and deny so reviewers can see when access depended on parent policy, scoped policy, or both. Use those logs to spot policy drift before it becomes cross-tenant exposure.

Key takeaways

• Multi-tenant SaaS authorization needs a hierarchy, not a flat set of per-tenant exceptions, if tenant data is to remain isolated.
• The critical control question is whether tenant-scoped permissions can only narrow access, or whether they can accidentally widen it.
• Platform teams should treat tenant policy authoring as bounded delegation and keep the root policy as the enforcement ceiling.

Key terms

• Scoped Role Policy: A scoped role policy defines what a role can do within a specific policy boundary, such as a tenant or environment. In multi-tenant SaaS, it lets platform teams narrow permissions per tenant without creating separate global roles for every customer.
• Scope Permission Mode: A scope permission mode determines how a child-scoped resource policy interacts with its parent policy when both can evaluate the same request. It is the control that decides whether local allowances can stand alone or must remain dependent on parent-level consent.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
• Parental Consent For Allows: Parental consent for allows is a control pattern where a child policy can only grant access if the parent policy also permits it. It preserves delegated flexibility while preventing tenant-authored rules from expanding beyond the platform's maximum authority.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.