Canvas exposed the authorization gap in multi-tenant SaaS

At a glance

What this is: This is an analysis of the Canvas incident that says the core flaw was authorization, not authentication, in a multi-tenant SaaS workflow.

Why it matters: It matters because IAM teams and SaaS owners need to govern what authenticated subjects can do in-context, especially where support and administrative workflows can cross tenant boundaries.

Context

Canvas is a multi-tenant SaaS authorization problem disguised as an incident response story. The key issue is not whether login worked, but whether a legitimate subject could reach higher-trust actions and tenant data through support and content workflows that should have been isolated.

Instructure's incident shows why tenant boundaries must be enforced at the point of action, not inferred from authentication state alone. For identity and access teams, the governance question is whether business workflows have a provable authorization decision behind every sensitive action.

The article is explicitly framed around multi-tenant SaaS and authorization risk, which makes it a useful lens for both SaaS product security and enterprise buyer scrutiny. The starting position is typical for modern SaaS platforms, where authn is mature but action-level authz is still inconsistent.

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 support workflows create breach risk in SaaS environments?

A: Support workflows often need exceptional visibility or write access, which makes them tempting trust shortcuts. If the platform does not bind those actions to tenant, purpose, and evidence checks, a valid support path can expose or alter customer data far beyond what the operator should see. The risk comes from broad delegated authority, not from login failure.

Q: How do security teams know if authorization is actually limiting tenant blast radius?

A: Look for evidence that every sensitive action records the tenant, purpose, policy version, and grant expiry, and that denied attempts are visible in logs. If authorization rules are scattered in application code and cannot be consistently tested or audited, the control is not limiting blast radius in practice.

Q: What should SaaS teams do when a low-trust account can reach high-trust content or support actions?

A: Treat that path as a design flaw, not a corner case. Re-model the workflow so the action is denied unless the tenant, purpose, and request context are explicitly authorised at runtime. Then separate support authority from customer-facing identity state so one valid session cannot become tenant-wide reach.

Technical breakdown

How support workflows become tenant boundary failures

In a multi-tenant SaaS model, support staff and automated back-office workflows often need exceptional access to customer records, tickets, or content. The problem begins when that exception path is not anchored to tenant, purpose, and evidence checks at the moment of action. A user can be authenticated, but still be authorized too broadly because the application treats support context as trusted by default. That is the core SaaS control failure here: workflow privilege is easier to grant than to constrain, and once it exists, it tends to spread across features, services, and teams.

Practical implication: treat support and admin workflows as separate authorization domains with explicit policy checks at every sensitive action.

Why authentication can succeed while authorization fails

Authentication answers who the subject is, but multi-tenant authorization answers what that subject may do, to which object, in which tenant, for which purpose, and with what evidence. Those are different control problems. A platform can have strong SSO and MFA and still allow a subject with valid credentials to reach data or change content outside their intended scope. In this case, the attack path depended on legitimate access being transformed into overbroad authority through application logic, ticket workflows, and content-management permissions. That is why access control must be evaluated at the action layer, not just at login.

Practical implication: review every sensitive action for tenant, purpose, and object-level authorization rather than relying on authenticated session state.

Policy-as-code is the only scalable way to close scattered authorization logic

When authorization decisions are embedded across services, they become difficult to audit, test, and keep consistent. Policy-as-code centralises those decisions so that the same rule can govern support reads, exports, content changes, and token issuance. In practical terms, that turns authorization from scattered application behaviour into an observable control plane. For multi-tenant SaaS, the architectural question is not whether policy exists somewhere in the codebase, but whether the business can prove that every high-trust action is enforced before execution and logged for review.

Practical implication: centralise sensitive authorization decisions so they can be tested, logged, and changed without relying on ad hoc application code.

Threat narrative

Attacker objective: The objective was to turn legitimate platform access into broader tenant-level reach, enabling data exposure and content tampering at scale.

1. Entry occurred through a legitimate self-service signup path that created an authenticated subject within the platform.
2. Credentialed access was then used against support and content workflows that carried more authority than the subject should have had.
3. The escalation step was the use of that overbroad authority to reach enterprise tenant data and modify content shown to logged-in users.
4. The impact was exposure of usernames, email addresses, course names, enrollment information, and messages across a multi-tenant environment.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-tenant SaaS authorization drift is the central failure mode here: the platform allowed an authenticated subject to exercise authority that was not explicitly granted in context. That is a governance problem, not an identity proofing problem. The article shows that the weak point sits at the action layer, where tenant, purpose, and evidence should have been checked before execution. Practitioners should treat that as the primary SaaS control boundary.

Support workflows are effectively privileged identity paths: when support or background processes can read, mutate, or export tenant data, they become non-human authority channels that need lifecycle control. The Canvas case demonstrates that these paths are often trusted more than they are verified. The implication is straightforward for SaaS governance: if support access is not policy-bound, tenant separation is only partial.

Authorization must move from scattered code to enforceable decision points: the article's policy-as-code framing reflects a broader market shift from static access models to runtime control. That direction aligns with NIST-CSF access permissions thinking and, in cloud settings, with identity and access control discipline. For practitioners, the key lesson is that action-level decisions must be observable, testable, and centrally governable.

Identity trust boundaries in SaaS now depend on business context, not just session state: who a subject is matters less than what workflow they entered and what tenant data the workflow can touch. That creates a named concept worth tracking: authorization blast radius. It is the distance between a valid session and the amount of tenant damage that session can still cause. Teams need to reduce that radius, because authentication alone no longer tells them where trust ends.

Tenant-scale exposure is the outcome of permission reuse, not just compromise: the article reinforces a pattern we see across SaaS incidents, where a normal account path plus overbroad workflow privilege can produce breach-level impact without exotic exploitation. That should push security and product teams to re-evaluate how much authority any one workflow carries. The practical conclusion is that least privilege has to be enforced at the transaction level, not only at account creation.

What this signals

Authorization blast radius: the amount of tenant damage a valid session can still cause when action-level controls are weak. For SaaS owners, the problem is not identity verification at login, but the distance between a permitted session and the data or content it can still reach. That distance has to shrink to the transaction layer.

Enterprises buying multi-tenant SaaS should now ask where support access, background jobs, and content-management workflows are authorized, not merely authenticated. If those decisions are not centralised and reviewable, the platform is carrying hidden delegated privilege that can cross tenant boundaries without a clear audit trail.

For practitioners

• Map every high-trust workflow Inventory support reads, exports, content changes, ticket-driven exceptions, and token issuance paths that can touch tenant data.
• Separate tenant and support authority Require explicit policy checks for tenant ID, purpose, verified request state, and approved operator role before any sensitive action executes.
• Move authorization decisions into a central policy layer Replace scattered in-code checks with enforceable runtime policy so the same rule governs support access, exports, and content updates.
• Log the evidence behind each privileged decision Capture the ticket, tenant, grant reason, policy version, and expiry so every elevated action is attributable and reviewable.
• Simulate the attack path against production workflows Trace whether a self-service account can reach enterprise tenant data through support or content tooling before attackers do.

Key takeaways

• Canvas shows that multi-tenant SaaS can fail at authorization even when authentication works as designed.
• The breach pattern is about legitimate access being turned into tenant-scale reach through support and content workflows.
• The limiting control is runtime, action-level authorization with tenant and purpose checks, not login hardening alone.

Key terms

• Access Blast Radius: Access blast radius is the amount of damage possible if an identity, credential, or permission set is misused or compromised. It is shaped by privilege scope, resource reach, lateral movement paths, and data sensitivity, and it is reduced by tight authorization and segmentation.
• Tenant boundary: The administrative and technical separation that defines where customer data, logs, and controls live in a cloud environment. In identity governance, it matters because auditors and security teams often need to prove that access decisions and identity records are isolated from other tenants.
• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Support Workflow Privilege: Elevated access granted to customer support or back-office processes so they can resolve issues or administer tenant data. It becomes risky when the workflow is broader than the verified purpose or lacks tenant-specific evidence checks.

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.