Originally published on Thomas’s Substack. Reproduced from the supplied publication export. Statements and patent-status references reflect the original publication date.
Editorial introduction · added September 17, 2026
Before you read
A vendor can acquire practical control over an institution's actions without receiving an explicit mandate for every consequence. This essay examines that gap in connected services and AI tools. SSOAR's proposed contribution is to keep institutional authority attached to the live interaction, so a valid credential or available capability does not silently become permission to act.
SSOAR means Session-Scoped Orthogonal Authority and Routing.
Why read it?
- CIOs and procurement teams
- Ask where vendor capability ends and institutional decision-making begins.
- Security architects
- Trace whether permissions remain valid as work moves between services.
This introduction is separate from the original essay.
Go to the original essay ↓The reported ShinyHunters/Instructure incident makes Canvas visible right now, but Canvas is not first, and it is not unique. It is simply the current surface where a broader category becomes legible. The Instructure platform that runs assignments, grades, deadlines, accommodations, and institutional records for much of American higher education is not merely a learning management tool. In practice, it is operationally authoritative. When the Canvas page renders, the institution treats what appears on it as the truth of the course, the enrollment, the deadline, and the submission. The institution still owns

the policy. The institution still owns the record. The institution still owns the duty. But the live action surface has moved.
That is the category. Canvas did not create it. Canvas merely makes it timely.
The same architecture exists wherever a vendor platform has become embedded in institutional operation. A CRM is no longer just a database when sales records, account permissions, customer workflows, and revenue operations depend on it. A support platform is no longer just a ticketing system when employees use it to reset access, verify identity, or escalate privileged requests. A CI/CD provider is no longer just an automation tool when secrets, build artifacts, and production change authority flow through it. An identity provider is no longer just a login service when access to every downstream system depends on its assertions. A learning management system is no longer just a classroom tool when it governs deadlines, submissions, accommodations, and grades.
At that point, the SaaS platform is not merely useful. It is the live action surface of the institution.
Most institutional governance still operates as if the important work happens before the integration goes live. The vendor is approved. The integration is approved. The OAuth grant is approved. The SAML configuration is approved. The API scope is approved. The policy is documented. The access is reviewed.
All of those steps matter. None of them is the moment that matters.
The moment that matters is the next page rendered, the next redirect issued, the next authentication flow invoked, the next token exchanged, the next configuration pushed, the next session state changed, the next record made visible, the next workflow advanced. That is where
The collapse happens at runtime
capability turns into authority. That is where the vendor was able to do something, and the institution treated the result as admissible.
Those are not the same thing. Modern systems blur them because they were built to compose functionality rather than to preserve institutional authority across mutating sessions. They assume that if an action arrives via a trusted integration path, it belongs in the environment.
That assumption is no longer safe. It may never have been safe. It was tolerable while the number of integrations was smaller, the rate of state change was lower, and the consequences were more contained. That era is ending.
The serious objection to all of this is that institutions cannot run without vendors. Cloud providers, identity platforms, collaboration tools, CRMs, learning platforms, payment processors, analytics systems, AI services, security tools, file-transfer platforms, support systems. None of these is optional. The mitigation is not to pretend they can be removed.
The mitigation is to stop treating vendor action as automatically admissible inside the institution.
A vendor may be able to render a page. That is capability. A vendor may be able to issue a redirect, invoke an authentication flow, push configuration, alter session state, or expose data through an integration. All capability. None of it is authority.
Authority is something else. Authority answers a different question: Is this action admissible inside this institution, in this interaction, under this policy, for this identity, at this moment? That question cannot be answered by the vendor alone, by the integration alone, or by the token's existence alone. It has to be answered at the institutional boundary, and more precisely, at the session boundary where the action becomes operationally meaningful.
The mitigation is not vendor distrust
The pattern is not conceptually complicated. The vendor proposes the action. Institutional policy evaluates the scope. A session authority checks admissibility. The system applies, degrades, blocks, or revokes. Evidence is preserved at runtime, while the decision is being made, not after.
That pattern does not require distrust. It requires separation.
A compromised vendor can still fail. A malicious actor can still exploit a weakness. A token can still be stolen. A redirect can still be abused. The difference is what the failure is allowed to become. Without a separate authority boundary, the failure becomes institutional reality. With one, the failure becomes a proposed state transition that the institution may accept, limit, degrade, block, or revoke.
That distinction is everything. It is the difference between a breach as event and a breach as governance collapse.
The architectural problem has a compliance shadow that is just starting to become visible.
Traditional compliance assumes proof can be reconstructed later. Logs, attestations, reports, screenshots, policy documents, vendor certifications, and incident narratives. These artifacts are useful, but they are after-the-fact evidence. They explain what happened after the system already allowed it to happen. That is no longer sufficient when the obligation attaches to behavior during execution.
Accessibility obligations attach to the user’s experience during the interaction. Zero Trust obligations attach to the access decision while the session is active. Data residency obligations attach to the routing and processing decision at the moment data moves. Institutional record obligations attach to the state transition when the record changes. AI
Compliance is shifting from documentation to behavior
governance obligations attach to the moment an output influences action.
You cannot satisfy those obligations by reconstructing them later. The system has to preserve evidence while the decision is being made. The burden is shifting from documenting controls to proving behavior, and that shift directly exposes the architectural weakness. If the institution cannot distinguish vendor capability from institutional authority at runtime, it cannot prove that its own policy governed the action. It can only prove that a trusted path existed.
That is not the same proof.
The pattern recurs because modern SaaS architecture was optimized for integration. Connect the platform. Authorize the scope. Sync the records. Automate the workflow. Reduce friction. Increase velocity. The model works until integration paths become authority paths.
Once they do, every vendor surface becomes a potential institutional state machine. The dashboard is no longer just a dashboard. The API is no longer just an API. The OAuth grant is no longer just a convenience. The support tool is no longer just an operational aid. The LMS is no longer just a classroom platform. Each is a place where institutional reality can change.
That is why the same failure appears under different names. Data exposure. Account takeover. Workflow manipulation. Configuration drift. Supply-chain compromise. Authentication bypass. Records integrity. Different incidents, same topology. Capability entered through a trusted path. Authority was assumed downstream. The system had no separate session-scoped boundary to decide whether the action should become authoritative.
Why this keeps happening
The same pattern, in a faster register
The institutional version of this failure has been gathering for a decade. The agentic version is arriving in seconds.
When a Cursor agent running Claude Opus 4.6 deleted a production database and every backup in nine seconds because it found a Railway CLI token in an unrelated configuration file, the architecture of the failure was the same architecture this essay has been describing. The token’s intended scope existed only in human institutional context. The agent presented the token. The API authenticated it. The endpoint accepted it. Every layer behaved correctly according to its own rules. What was missing was the layer that distinguishes between an authenticated call and an authorized one.
That is the SaaS pattern compressed. Vendor capability became institutional authority because nothing at runtime distinguished them. In this analogy, the agent is just another vendor whose action arrived via a trusted path. The institution that lost its database lost it for the same reason institutions lose accreditation, records integrity, or accessibility obligations: not because the vendor was malicious, but because the architecture had no place to evaluate admissibility before the state transition occurred.
The agentic case is the same problem with the human-speed buffer removed. The institutional case has historically permitted weeks or months between integration and consequence. The agentic case permits seconds. Both versions point to the same missing layer.
The question is not whether a vendor can fail. Vendors will fail. Every platform fails eventually. Every integration carries risk. Every credential can be mishandled. Every dashboard can become a control surface. Every token can become a weapon if the downstream environment treats possession as authority.
The real question is narrower.
The question institutions should ask
If the vendor fails, does the architecture let that failure become the institution’s operational reality?
If the answer is yes, the institution has not bounded authority. It has outsourced it by accident.
That is the category. Canvas is the visible example. It is not the boundary. The boundary is the moment vendor capability becomes institutional authority, and that is where modern SaaS architecture is weakest, where Zero Trust has to move next, where compliance will increasingly be tested, and where the architecture has to change.
Not to eliminate vendors. Not to eliminate integration. Not to eliminate SaaS. To prevent capability from silently becoming authority.
Because once that distinction collapses, the institution is no longer merely using the vendor. It is inheriting the vendor’s state as its own.
That is not resilience. That is dependency without a boundary.