The Salesloft incident involved three parties. Salesforce operated the platform holding the data. Salesloft operated the integration and held the tokens. Several hundred customers had granted those tokens and owned the records.
Each secured what it controlled. The failure occurred in the relationship between them, which none of them owned.
The Customer Cannot See The Risk They Carry
From the customer’s side, granting an integration is a one-time administrative action. Afterwards there is no ongoing signal: no login events, no visible activity, no notification if the vendor’s security posture changes or their token store is compromised.
The customer holds the consequence and has no instrumentation. That is the same asymmetry this desk filed for outsourced service desks at 26-0413 — the contract moves the work and leaves the risk.
The Platform Sees The Queries And Not The Intent
Salesforce could observe an integration querying tenants. That is what integrations do. Distinguishing authorised bulk export from unauthorised bulk export requires knowing what the customer expected, which the platform does not.
The one signal available across the boundary is volume, and it is the one this desk has repeatedly noted nobody alerts on.
What A Shared Model Would Need
Researchers analysing this incident converged on the same components: expiry on delegated grants by default, per-tenant visibility of integration activity, platform-side anomaly detection on export volume, and a defined notification path from vendor to downstream customer.
None is technically difficult. Each requires two commercial parties to agree who is accountable for something they currently both assume the other handles — which is why this remains, as at 26-0307, an unassigned responsibility rather than an unsolved problem.
This is an analysis file built on published incident research, listed below. The framing is ours and labelled as such. Corrections: corrections@forensicpost.com.