The Thesis, The Claim, The Ask
For: CISOs, CIOs, and security architects responsible for multi-tenant SaaS and authorization risk. From: EnforceAuth, Inc. · San Diego, CA. Date: May 12, 2026.
The thesis. Canvas was not breached by a missing patch, a stolen password, or a sophisticated zero-day. It was breached because a low-trust workflow could perform high-trust actions. Authentication worked. Authorization did not. Every multi-tenant SaaS in your portfolio has the same gap.
The claim. EnforceAuth would have blocked the Canvas attack pattern at the point of action — not after exfiltration, not after defacement, not after extortion. We can prove it with policy-as-code you can read in five minutes.
The ask. Thirty minutes. We will run our discovery scanner (Zift) against one of your apps and show you, in writing, how many authorization decisions are scattered across your codebase and how many of them are wrong.
What Actually Happened
Strip away the press cycle and the threat-actor branding. The technical story is short.
On April 29, 2026, Instructure detected unauthorized activity inside Canvas. By May 7, attackers had modified pages shown to logged-in students and teachers. By May 12, the U.S. Department of Education had issued a global alert and Instructure had taken down the Free-For-Teacher platform. Threat actors claimed access to 9,000 institutions and 275 million individuals. Instructure confirmed the involved data: usernames, email addresses, course names, enrollment information, and messages.
The exploited path, in Instructure's own words, related to Free-For-Teacher accounts and the support ticket system. Translation: a public, free, self-service signup tier and an internal support workflow combined into a path that could reach enterprise-tenant customer data and the platform's content-management layer.
Read this twice. The attacker did not break authentication. The attacker became an authenticated subject — through a legitimate self-service signup — and then exercised authority the business would never have granted if asked in context. That is not an identity problem. That is an authorization problem.
Why This Should Concern You
If you run a multi-tenant SaaS — or you buy one — ask three questions. Honest answers reveal the same gap Instructure had.
Question one. Can any free, trial, or self-service account in your platform reach enterprise-tenant data through a support, admin, or background workflow? Most CISOs say no. Most product-security teams discover the answer is yes within 90 minutes of looking.
Question two. When a support engineer reads a customer record, can you produce — in under five minutes — the ticket, the verified tenant, the approved purpose, the grant expiry, and the policy version that authorized it? If you cannot, you have the same evidence gap Instructure is now living through with regulators and customers.
Question three. How many of your authorization decisions live in application code — scattered across services, written by different engineers, tested inconsistently, and changeable only by another deploy? Industry baseline: 80 to 95 percent. That is your blast-radius surface.
Authentication has been solved. Okta, Microsoft Entra, Ping, and a dozen others compete on it. Authorization — the decision about what an authenticated subject can do, to which object, for which purpose, in which context, with what evidence — has not. It is the gap left over after every IAM, SSO, MFA, and API-gateway investment you have made.
How EnforceAuth Would Have Stopped This
EnforceAuth is a runtime authorization fabric. Every meaningful action — a support read, an API call, a token issuance, a bulk export, a content change — becomes a policy decision before it executes. The decision is made by a central Policy Decision Point (PDP) against context the application alone cannot see: tenant graph, ticket state, purpose, token lineage, risk score, change window.
Against the Canvas pattern, that produces six concrete interdictions. Each one is a place where EnforceAuth's deny would have ended the attack.
This is not a theory. Each row maps to roughly twenty lines of policy-as-code we have already written and tested. The technical paper accompanying this brief shows every policy in production-ready form.
Why This Claim Holds Up Under Scrutiny
Vendors make breach-prevention claims after every major incident. Most of them collapse under technical review. Here is the precise scope of ours.
We claim. Where the Canvas attack path required unauthorized support, token, API, data, export, or content-management actions, EnforceAuth would have forced each action through a contextual runtime authorization decision. For workflows covered by a Policy Enforcement Point (PEP), those actions would have been denied, constrained, stepped up, or quarantined before tenant-scale exposure occurred.
We do not claim. We did not and would not patch the underlying support-ticket defect. We do not replace your SDLC, your WAF, your DLP, or your incident response capability. If an attacker bypassed the application stack entirely and read raw database storage, EnforceAuth alone would not be sufficient — though our decision logs would have detected the bypass within minutes.
The math. The Canvas attack required six sequential privileged actions to produce the public outcome. Each one is a place EnforceAuth makes a deny decision. Probability of all six policies failing simultaneously, given the testing rigor we ship with: vanishingly low. Probability of one policy failing safely: high, by design.
The architecture in one sentence. Authentication tells you who. EnforceAuth tells you what they can do, to which resource, for what purpose, under what conditions, with what evidence — and produces an immutable audit log of every decision your CISO, your counsel, your auditor, and your customers can read.
The Cost of the Status Quo
Canvas is not an outlier. It is a preview. Multi-tenant SaaS authorization failures follow a predictable cost curve once they go public.
Most CISOs underestimate one cost: the cost of waiting until your own incident makes this case for you. By then, the conversation is no longer about prevention. It is about explanation.
What We Are Asking For
One conversation. Thirty minutes. We bring three things.
Zift discovery output. We run our open-source code scanner against a representative application of your choosing and produce a written inventory of where authorization logic lives in your codebase, how scattered it is, and which decisions are inconsistent. This output is yours regardless of whether you proceed with us.
Canvas-pattern simulation. We map the six-step Canvas attack path against your platform's actual workflows and identify which of the six EnforceAuth policies would require the least effort to deploy first. You leave with a prioritized PEP deployment roadmap.
A working POC scope. If the discovery surfaces meaningful risk, we propose a 30-day proof of value: one PEP, one decision domain (we recommend support access), measurable before-and-after evidence. No procurement commitment until the POC succeeds.
Closing thought. Every major SaaS breach of the last 24 months — Snowflake, MOVEit, Okta support, Microsoft Midnight Blizzard, and now Canvas — has the same shape. An authenticated subject performed an action the business would never have explicitly approved. The technology to prevent that pattern exists. It just needs to sit inline with the workflows that matter. We built it. We would like to show it to you.
Mark Rogge, CEO & Founder, EnforceAuth, Inc. · San Diego, California · enforceauth.com
About EnforceAuth
EnforceAuth is the AI Security Fabric for the agentic era. We provide decision-centric authorization across applications, infrastructure, data, and AI workloads. Write policy once. Enforce everywhere.