Organizations spend weeks evaluating new SaaS integrations before approving them. Security reviews are completed, vendor questionnaires are answered, permissions are scrutinized, and OAuth access is established.
Then everyone moves on.
Reporting surrounding the Klue compromise has highlighted a growing challenge for enterprise security teams. According to available reporting, attackers were able to leverage a compromise involving Klue's Salesforce integration to access customer Salesforce data through existing OAuth relationships. No Salesforce platform vulnerability was required. The trust relationship already existed.
For affected organizations, the incident raises uncomfortable questions. How many third-party integrations currently have access to Salesforce? What permissions have they been granted? Who approved those permissions? When were they last reviewed?
While the details of the compromise continue to be analyzed, the broader lesson extends beyond a single vendor. The risk is not always in granting trust. Sometimes the risk is forgetting that trust was granted in the first place.
A pattern in the Salesforce ecosystem
The Klue incident is unlikely to be the last example of attackers exploiting trusted SaaS relationships.
Similar concerns emerged during the Salesloft Drift incident in 2025, where attackers reportedly leveraged OAuth-connected trust relationships to access downstream Salesforce environments. While the circumstances differed, both incidents demonstrated how compromise can propagate through existing trust relationships rather than through vulnerabilities in the underlying platform.
Different vendors. Different compromises. Similar outcomes.
Nearly a year apart, both incidents appear to have leveraged the same trust model: compromise the trusted integration and inherit the access.
The common denominator was not Salesforce. It was trust.
Security teams focus on granting trust
Before an integration is approved, security teams commonly conduct vendor risk assessments, review compliance documentation, evaluate requested permissions, and verify business justification. Most organizations know how to ask the right questions before granting access.
Most organizations also have a formal process for granting trust. Far fewer have an equally mature process for continuously reevaluating it.
Security teams often treat SaaS approval as a project with a finish line: questionnaire complete, vendor approved, integration deployed.
The assumption that SaaS providers are responsible for securing the entire environment compounds the problem. SaaS security requires a shared responsibility model: Providers secure the platform, but organizations are responsible for how it is configured, accessed, and used.
In reality, approval should mark the beginning of the trust relationship, not the end of the review process.
The blind spot: Standing trust
Modern SaaS ecosystems are built on delegated trust.
OAuth tokens, refresh tokens, service accounts, and third-party integrations allow applications to access business systems without requiring users to repeatedly authenticate. This convenience is one of the reasons SaaS platforms have become so powerful. It is also one of the reasons they have become attractive targets.
The challenge is that trust relationships often persist far longer than the reviews that created them. An integration approved during a CRM migration may still have access years later. The business owner who requested it may have changed roles or left the company entirely. A vendor may have added new functionality that requires broader permissions than originally granted. Once-critical integrations may sit largely dormant while retaining access to sensitive data.
None of these conditions necessarily indicate compromise. However, they create an environment where nobody is actively asking whether the original trust decision still makes sense. Access that survives longer than the review that justified it becomes a liability.
That raises questions many organizations struggle to answer:
- Is the integration still necessary?
- Does it still require the same permissions?
- Who owns it?
- When was it last reviewed?
When those questions cannot be answered, standing trust becomes standing risk.
Everything worked exactly as designed
When incidents involving OAuth relationships occur, the instinct is to look for something that broke. In the Klue and Drift incidents, that search may be frustrating; OAuth is an authorization framework, and in these cases, it appears to have functioned as intended. The tokens were valid. The applications were authorized. MFA, where it existed, may have been beside the point.
Nothing failed. The trust relationship was simply abused.
That distinction matters because it shifts the conversation away from what broke and toward what was never constrained in the first place.
Trust requires verification after approval
Trust should not be a one-time decision. Approval should not imply unlimited future confidence.
Software changes. Vendors change. Business requirements change.
Threat actors adapt.
The challenge is not simply understanding what an integration is allowed to do but recognizing when a trusted integration begins behaving in ways that were never intended.
An application approved to synchronize CRM data should not suddenly begin accessing significantly more information than expected. A dormant integration that becomes active after months of inactivity should attract scrutiny. Behavior that no longer aligns with an application's intended purpose should prompt reevaluation.
Trust should be continuously validated, not indefinitely inherited.
This is where controls focused on reducing standing access and continuously evaluating behavior become important. Organizations should regularly review OAuth grants, apply least privilege principles to integrations and service accounts, and reassess whether permissions remain aligned with business requirements.
Additional controls can further reduce risk. Zero Trust Cloud Access (ZTCA) can help organizations control which applications are permitted to access cloud resources, ensuring that access remains explicitly authorized rather than implicitly inherited. Ringfencing can help constrain application behavior and reduce the blast radius if trusted software is abused.
The goal is not to eliminate trust relationships but to ensure they remain constrained, observable, and subject to reevaluation.
Organizations routinely ask: "Should we trust this application?"
Increasingly, the more important question is: "Should we still trust it?"
The most dangerous permissions are usually not the ones granted yesterday. They're the permissions nobody remembers granting.
ABOUT THE AUTHOR
Andrea Pomaranski is a Special Projects IT Engineer at ThreatLocker, working on R&D‑focused technical initiatives across enterprise systems, identity infrastructure, and platform integrations. She studied Computer Science at the University of Florida and began her career in IT before moving into software development, supporting mission‑critical systems in highly regulated production environments. A longtime CTF competitor, Andrea honed her security skills through university, independent study, and past workplaces, including as an active member of UF’s Security and Information Technology (SIT) organization. Outside of work, she maintains a hands‑on homelab where she experiments with hardware and operating systems. She brings a builder’s mindset and a deep interest in how vulnerabilities emerge in real‑world systems to product research and technical investigation.
