Canvas exposed the authorization gap in multi-tenant SaaS

At a glance

What this is: This is an independent analysis of the Canvas incident, which showed how a legitimate login path and support workflow can still produce unauthorized high-trust actions in multi-tenant SaaS.

Why it matters: It matters because IAM teams, SaaS security owners, and identity architects must treat authorization as a first-class control across NHI, autonomous, and human access paths, not as a post-authentication assumption.

👉 Read EnforceAuth's analysis of the Canvas authorization failure in multi-tenant SaaS

Context

In multi-tenant SaaS, the key problem is not always authentication failure. A system can correctly identify a subject and still allow that subject to do the wrong thing, to the wrong tenant, at the wrong time, through the wrong workflow. That is the authorization gap this incident exposes for identity and access programmes.

For IAM and security architects, the takeaway is broader than one application. When support channels, self-service signup, token issuance, and content-management actions are governed in code rather than in a central policy layer, the blast radius becomes difficult to reason about. The primary question is not who logged in, but what that subject was able to do once inside.

Key questions

Q: What breaks when authentication is correct but authorization is weak in SaaS platforms?

A: A platform can verify identity correctly and still let the wrong subject perform high-impact actions. In multi-tenant SaaS, that means support reads, exports, token issuance, or content changes can cross tenant boundaries unless runtime authorization is tightly enforced. The failure mode is not login compromise. It is downstream authority that exceeds business intent and becomes hard to prove after the fact.

Q: Why do multi-tenant SaaS apps need decision-centric authorization?

A: Because tenant safety depends on the action decision, not only on the identity proof. Decision-centric authorization forces every sensitive operation to evaluate tenant context, purpose, and policy before execution. That reduces the chance that a legitimate user or support workflow can act beyond its intended scope, which is exactly where multi-tenant incidents tend to escalate.

Q: How do security teams know if authorization is actually working?

A: They should be able to prove, quickly, why a privileged action was allowed, who requested it, which tenant it applied to, what policy version applied, and when the grant expired. If those answers require manual reconstruction across code, tickets, and logs, authorization is not operating as a reliable control. Evidence quality is the test.

Q: Who is accountable when support workflows expose customer data across tenants?

A: Accountability sits with the organisation that designed the workflow, the team that owns the policy, and the operator who executed the action. In regulated environments, auditors and customers will expect the business to show purpose, approval, and tenant separation for every privileged action. Without that chain, responsibility becomes disputed even when the access was technically authenticated.

Technical breakdown

How support workflows become authorization shortcuts

Multi-tenant SaaS often blends user-facing features with administrative and support operations. When a support path can reach tenant records, tokens, exports, or content edits, the application has effectively created a second trust channel that is not visible to the end user. The problem is not the login event itself. It is the decision surface that sits after authentication, where context such as tenant ownership, ticket state, and purpose should govern every high-risk action. If those checks are scattered across code, they become easy to miss and hard to prove.

Practical implication: centralise support-action authorization so every privileged read or write is evaluated before execution.

Policy-as-code versus scattered application logic

Authorization logic embedded across services usually reflects local implementation choices rather than enterprise governance intent. That means one workflow may enforce tenant boundaries, another may not, and a third may rely on an engineer remembering to add a check in the next deploy. Policy-as-code shifts the decision into a consistent runtime layer, where the same rules apply across APIs, support tools, and content actions. In this model, the policy engine evaluates the subject, resource, tenant context, and purpose before the action proceeds.

Practical implication: inventory where authorization decisions live now, then move the highest-risk decisions out of application code first.

Why auditability is part of authorization, not an afterthought

A strong authorization model does more than allow or deny. It records why a decision was made, what context was used, and which policy version was in force. In incidents like Canvas, that evidence matters because regulators, customers, and internal responders need to reconstruct the path from legitimate access to unauthorized impact. If the system cannot produce the ticket, tenant, purpose, expiry, and policy basis quickly, the organisation has a governance failure even before it has a technical one.

Practical implication: require decision logs that tie privileged actions to purpose, tenant, and policy state.

Threat narrative

Attacker objective: The objective was to turn valid authenticated access into tenant-scale exposure and platform disruption without needing to break the login system.

1. Entry occurred through a legitimate self-service signup path that created an authenticated subject without granting appropriate trust for enterprise tenant access.
2. Credential access was not the issue; the attacker abused support and platform workflows to exercise authority the business would never have approved in context.
3. Escalation came from repeated privileged actions across support, API, and content-management layers until logged-in students and teachers saw modified pages.
4. Impact included unauthorized access to account and course-related data, plus public disruption severe enough to trigger platform shutdown and regulatory attention.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Authentication is no longer the control that decides tenant safety. The Canvas incident shows that identity systems can authenticate a subject correctly and still fail at the point that matters most: what that subject can do. In multi-tenant SaaS, the real control surface is the runtime authorization decision, not the login ceremony. Practitioners should treat this as an identity governance problem, not only an application bug.

Scattered authorization logic creates an evidence problem before it creates a breach problem. When support reads, token issuance, exports, and content changes are governed in different places, no single team can prove which decisions were authorized, by what policy, and for which tenant. That is a governance breakdown, not just a code-quality issue. Organisations should assume that unreadable authorization is already a control deficiency.

Tenant blast radius is the measurable failure mode in multi-tenant SaaS. The central question is not whether an attacker logged in, but how far one authenticated subject could move through support and platform workflows before detection. That makes blast-radius reduction the correct design goal for customer-facing SaaS platforms. Security teams should evaluate whether every privileged action is constrained by tenant, purpose, and context.

Decision-centric authorization is the named concept this incident sharpens. The breach worked because the system trusted identity at login but failed to govern decisions at runtime. That assumption was designed for environments where authentication and authorisation are close enough to each other to be treated as one event. It fails when business workflows can elevate a subject across tenants, and the implication is that IAM programmes must separate identity proofing from action authority.

Multi-tenant SaaS security now depends on proving who can act, not only who can enter. The Canvas pattern aligns with OWASP-NHI thinking only insofar as the platform exposes machine and human workflows to the same downstream privilege problem. The more important lesson is that application governance and identity governance are converging at the policy layer. Practitioners should expect runtime authorization to become a board-level SaaS control, not an engineering convenience.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security & ESG.
• That pattern is why the 52 NHI breaches Report is useful when teams need to move from incident reaction to control design.

What this signals

Decision-centric authorization: The practical lesson from Canvas is that identity programmes need to govern actions, not just sessions. When a legitimate subject can trigger privileged support or content workflows, the control gap sits in runtime policy enforcement, tenant context, and evidence quality, not in authentication alone.

The next maturity step for SaaS owners is to build authorization inventories that are as explicit as their identity inventories. That means identifying where privilege lives in code, where support workflows can cross tenant boundaries, and where audit logs prove purpose and expiry. The NIST Cybersecurity Framework 2.0 is a useful framing tool for mapping those controls into govern, protect, and detect functions.

As these patterns repeat across SaaS, the market will increasingly treat authorization as a separate control plane. That shift matters for both human and non-human identities, because the same downstream action layer is where service accounts, support operators, and automated workflows can all exceed intent. The organisations that can show bounded authority will have a defensible story when the next tenant-impacting incident lands.

For practitioners

• Map every high-trust support path Inventory support reads, admin actions, export functions, token issuance, and content changes across your SaaS estate. For each one, document the tenant boundary, the purpose requirement, and the policy decision that should fire before execution. Use the result to identify where a subject can still do more than the business intended.
• Move privileged decisions into a central policy layer Pull the highest-risk authorization checks out of scattered application code and into a runtime policy decision point. Start with customer data access, support workflows, and bulk export functions, because those actions create the largest blast radius when controls are inconsistent.
• Require decision logs for every privileged action Make ticket reference, tenant identity, approved purpose, grant expiry, and policy version part of the audit record for each sensitive action. If responders cannot reconstruct those fields in minutes, the environment is not operationally governable.
• Test for cross-tenant action paths Run tabletop and technical testing that asks whether a free, trial, or self-service identity can reach enterprise data through support or background workflows. The point is to find where legitimate access turns into unauthorized authority before customers do.

Key takeaways

• Canvas showed that authenticated access can still become unauthorized impact when runtime authorization is weak.
• The scale of the problem is measured in tenant blast radius, evidence gaps, and privileged workflows that live outside a central policy layer.
• Teams should inventory high-trust support paths, centralise sensitive decisions, and require auditability for every privileged action.

Key terms

• Runtime Authorization: Runtime authorization is the act of deciding whether a specific action may proceed at the moment it is requested. It checks subject, resource, purpose, and context before execution, which makes it distinct from simple login authentication and more suitable for multi-tenant and support-heavy SaaS.
• Tenant Blast Radius: Tenant blast radius is the amount of customer data, functionality, or privilege one compromised or misused identity can reach inside a multi-tenant platform. The smaller the blast radius, the less a single access path can damage other tenants or create systemic exposure.
• Policy-as-Code: Policy-as-code is the practice of expressing authorization rules in a versioned, testable, machine-readable policy layer. It gives security and engineering teams a common control point for deciding, auditing, and changing access logic without scattering critical rules across application services.
• Decision Log: A decision log is the audit record that explains why a privileged action was allowed or denied. For identity governance, it should capture the subject, tenant, purpose, policy version, and expiry so responders can reconstruct accountability quickly after an incident.

Deepen your knowledge

Runtime authorization and tenant blast-radius control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for multi-tenant SaaS or support workflows, it is worth exploring.

This post draws on content published by EnforceAuth covering the Canvas incident and multi-tenant authorization risk: The Thesis, The Claim, The Ask. Read the original.