TL;DR: Two 2025 campaigns abused Salesforce-connected trust rather than exploiting Salesforce itself: one used a Salesloft compromise to steal OAuth tokens and access data across more than 700 organizations, while another relied on vishing and malicious app authorization to exfiltrate Salesforce records, according to Valence Security. The lesson is that SaaS integration governance, not perimeter defense, now determines blast radius and response speed.
At a glance
What this is: Two 2025 campaigns showed that attackers can abuse Salesforce-connected trust paths, token scopes, and authorised SaaS integrations to steal data at scale without breaching Salesforce itself.
Why it matters: This matters because IAM, PAM, and NHI teams now have to govern OAuth tokens, app trust, and third-party integrations as part of the access perimeter, not as adjacent admin concerns.
By the numbers:
- The Salesloft-linked campaign impacted more than 700 organizations.
Context
Salesforce trust abuse is a SaaS identity problem, not a Salesforce-only product problem. When third-party apps, OAuth tokens, and delegated integrations can move data across customer environments, the real perimeter becomes the trust relationship between platforms rather than the application boundary itself.
This article focuses on two 2025 campaigns that used that trust layer differently: one through a compromised integration chain and one through social engineering that induced users to grant access. The common failure mode is governance over SaaS-to-SaaS access, token scope, and app provenance.
For IAM and NHI practitioners, the lesson is that access decisions made outside the main identity plane can still create enterprise-scale exposure. That makes integration inventory, token lifecycle, and emergency revocation part of identity governance, not separate SaaS hygiene.
Key questions
Q: What breaks when SaaS integrations are created without security oversight?
A: When integrations are created without security oversight, teams lose context on which vendors can access which applications and how much data they can reach. That breaks third-party risk management, because security and compliance teams cannot reliably assess exposure, enforce least privilege, or remove unnecessary access. The result is sprawl, hidden trust relationships, and a wider attack surface than the organisation believes it has.
Q: Why do OAuth tokens increase lateral movement risk in SaaS environments?
A: OAuth tokens increase lateral movement risk because they can remain valid after the initial user session, bypass MFA, and preserve scoped access until revoked. In SaaS environments, that makes a single consented app a durable bridge into email, files, logs, and admin-adjacent data. Identity governance must treat token scope and revocation as first-class controls.
Q: What are the signs that third-party SaaS integrations are becoming a security problem?
A: Warning signs include large numbers of unused integrations, apps requesting broad read and write scopes, unclear ownership of approved apps, and employees routinely consenting to prompts without review. Another signal is the presence of integrations that can access shared documents, inboxes, or tenant-wide data when the business only needs a narrow function.
Q: How should security teams respond when a trusted SaaS integration is compromised?
A: Start by revoking the compromised token, then inventory every related credential, service principal, API key, and downstream system that the app could reach. After that, review scopes, reissue credentials from trusted environments, and monitor for unusual API activity. The goal is to close the trust chain, not just the first entry point.
Technical breakdown
How OAuth token abuse turns SaaS trust into data access
OAuth gives an app delegated access without sharing a user password, which is why it scales so easily across SaaS ecosystems. In these campaigns, that delegation was the attack surface: once tokens were obtained or granted, attackers could query Salesforce data, export records through Bulk API, and move through connected systems without needing direct Salesforce compromise. The trust chain matters more than the login event because the attacker inherits whatever scopes the integration already has. Practical implication: treat token scope, expiry, and provenance as enforcement points, not afterthoughts.
Practical implication: inventory delegated SaaS access and constrain every token to the minimum scope it actually needs.
Why SaaS-to-SaaS integrations create hidden blast radius
A SaaS integration is effectively a machine-to-machine trust relationship with business data privileges attached. If one connected service is compromised, the attacker may inherit access to multiple tenant environments through the same integration path. That is why the breach footprint in the Drift case extended beyond one vendor relationship and why the Data Loader campaign could succeed with legitimate-looking app authorization. The architecture assumes trusted intermediaries will behave, but the security model often lacks continuous verification of who issued the token, what it can reach, and whether that scope still fits the business use case. Practical implication: govern integrations as privileged access paths, not just application plug-ins.
Practical implication: place SaaS integrations under the same governance and review discipline you apply to privileged access paths.
How social engineering bypasses technical controls in OAuth flows
The Data Loader campaign shows a different failure pattern: users were persuaded to authorize a malicious or spoofed app, so the access grant itself became the compromise event. No malware delivery or password theft was required. MFA and login alerts did not help because the attacker operated through a permitted OAuth flow that looked like legitimate administration. This is the core weakness of trust-based delegation: when a human is tricked into granting the token, the platform cannot distinguish consent from coercion without stronger app provenance and approval controls. Practical implication: add app verification and high-risk authorization review before tokens are issued.
Practical implication: require stronger approval for new or high-risk OAuth grants before access is issued.
Threat narrative
Attacker objective: The attacker objective was to exfiltrate Salesforce-linked customer, case, and credential data at scale by abusing trusted SaaS integrations.
- Entry occurred through compromised or manipulated trust relationships rather than direct exploitation of Salesforce, including access to a vendor GitHub account and vishing-led app authorization.
- Credential access followed when attackers obtained OAuth tokens or induced users to grant them, giving delegated access to Salesforce-connected data flows.
- Escalation happened as those tokens were used to query records, export data, and discover embedded secrets across connected services.
- Impact was large-scale data exposure across many organisations, with some logs deleted after exfiltration and recovery dependent on retained telemetry.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SaaS integration trust is now an identity perimeter. The old model treats SaaS apps as adjacent systems and identity as something that happens before the app connection. These campaigns show that the connection itself is where control fails, because the token becomes the durable access path. Practitioners should stop treating third-party app governance as a procurement issue and start treating it as a core identity control surface.
OAuth tokens behave like privileged credentials, not convenience artefacts. Once a token can query records, export data, or reach downstream services, it carries the same governance burden as a high-risk account. The lesson is not just that tokens can be stolen, but that their scope often outlives the risk assumptions made at issuance. Teams need to review token scope as an entitlement decision, not a technical setting.
Integration provenance is the missing control in many SaaS programmes. The Data Loader campaign worked because a legitimate-looking app name and a trusted workflow were enough to persuade users to grant access. That reveals a governance gap around which apps are allowed, who approved them, and how their legitimacy is revalidated over time. The practical takeaway is that provenance must be part of access governance, not separate from it.
Blast-radius control is becoming the decisive SaaS security variable. These incidents did not depend on a Salesforce platform breach, so perimeter thinking fails to explain the damage. The important question is which integration paths, token scopes, and revocation processes can contain a compromise once trust is abused. For identity programmes, that shifts the centre of gravity from login protection to delegated-access containment.
Service account and human governance are converging inside SaaS ecosystems. The same oversight gaps that affect NHI lifecycle management now apply to user-authorised app grants and SaaS-to-SaaS connections. That means lifecycle review, inventory, and offboarding logic must cover both machine-mediated access and human-approved delegation. Practitioners should govern both through one access model rather than separate admin and security exceptions.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Security Platform Buyer's Guide
What this signals
Integration governance is becoming the control plane for SaaS identity. Identity programmes that stop at user login will miss the real exposure path, because delegated app access can move data without another authentication event. The practical shift is to treat SaaS connections as governed entitlements with ownership, expiry, and revocation criteria, not as passive connectors.
OAuth authorisation now needs the same scrutiny as privileged access approval. The hard lesson from these campaigns is that consent can be the compromise point. If a user can grant a high-risk app access without meaningful verification, the organisation has outsourced control of a privileged path to a moment of trust rather than an auditable decision.
Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That visibility gap is no longer confined to backend workloads, because SaaS integrations, user-authorised apps, and machine-mediated access all now participate in the same blast radius problem.
For practitioners
- Inventory every SaaS integration and OAuth grant Build a real-time list of user-installed apps, SaaS-to-SaaS connections, token scopes, and ownership so you can see which paths can move data outside the primary platform.
- Treat OAuth tokens as privileged credentials Apply expiry, rotation, least-privilege scoping, and revocation workflows to tokens the same way you would to other high-risk credentials.
- Require approval for high-risk app authorisation Place new or unusual integrations, especially those requesting data export or admin-like scopes, into a review step before consent is granted.
- Harden integration source systems Secure the GitHub, automation, and app-delivery accounts that can be used to publish or modify integration code, because compromise there can cascade into token theft or rogue app consent.
Key takeaways
- SaaS breaches are increasingly happening through trusted integrations and delegated access rather than direct platform compromise.
- The article cites a campaign that affected more than 700 organisations, showing how quickly token abuse can scale when integration governance is weak.
- The key control lesson is to govern OAuth scopes, app provenance, and token revocation as part of identity security, not as separate SaaS administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on token theft and exposed credentials used through SaaS integrations. |
| NHI-03 — Vulnerable Third-Party NHI | The incidents depended on third-party integrations whose trust relationships were abused. | |
| NHI-05 — Overprivileged NHI | Broad token scopes enabled data export and downstream access beyond minimum need. | |
| Recommendation — Scan SaaS integration paths for exposed tokens and revoke any credential that has left controlled scope. Assess third-party integrations as NHI trust boundaries and offboard any app that cannot be governed. Reduce integration scopes to the minimum data and function set each token actually needs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle management maps directly to authenticator issuance, rotation, and revocation. |
| Recommendation — Apply authenticator management controls to token lifecycle, scope, and revocation processes. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The campaign used token theft and trusted integration paths to move through connected environments. |
| Recommendation — Map token theft and integration abuse to credential access and lateral movement detections. | ||
Key terms
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- SaaS Blast Radius: SaaS blast radius is the scope of systems, data, and accounts that an attacker can reach through one compromised identity. It is defined by active permissions, shared apps, connected tools, and lingering sessions, not by network boundaries. The larger the blast radius, the harder containment becomes during an incident.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org