TL;DR: Cross-tenant analysis of the Salesloft-Drift supply chain breach identified every impacted organization in its customer base within 30 minutes and surfaced Google Workspace scope before others reported it, showing how SaaS integrations can hide cross-service compromise across 700+ victims, according to Obsidian Security. The lesson is that integration-layer visibility, not isolated log search, now determines whether SaaS identity risk can be investigated at all.
At a glance
What this is: This is a SaaS supply chain breach analysis showing that compromised OAuth tokens in a third-party integration can create a far wider blast radius than single-tenant log searches reveal.
Why it matters: It matters because SaaS integrations, OAuth grants, and non-human identities are now part of identity governance, and teams need cross-service correlation to see abuse before impact spreads.
By the numbers:
- Obsidian Security found the blast radius of this supply chain attack was 10x greater than previous incidents, where attackers infiltrated Salesforce directly.
👉 Read Obsidian Security's analysis of the Salesloft-Drift SaaS supply chain breach
Context
SaaS supply chain risk emerges when a trusted integration becomes the path into multiple environments instead of a single tenant. In this article, Obsidian Security argues that the real problem was not one compromised app alone, but the visibility gap created when OAuth tokens and connected applications are treated as ordinary access rather than governed identities.
For identity teams, this is an NHI governance problem as much as it is a SaaS security problem. Connected apps, service tokens, and cross-platform identities need lifecycle control, correlation, and offboarding logic that extends beyond one application log or one admin console.
The article's starting position is typical of modern SaaS estates: organisations can search their own environment and still miss the wider pattern because the evidence is distributed across tenants and services.
Key questions
Q: What breaks when SaaS integrations are not governed as non-human identities?
A: Teams lose visibility into who or what can reach connected systems, and attackers can use trusted credentials to move through those integrations without triggering normal human-account controls. The practical failure is blast radius, not just access. One over-scoped token or service account can expose multiple downstream platforms, especially when ownership, rotation, and review are missing.
Q: Why do SaaS supply chain breaches often outpace single-tenant investigations?
A: Because the same malicious activity can look normal in one environment and only become obvious when compared across many. Without cross-tenant correlation, teams cannot distinguish unique compromise from shared attacker infrastructure, so scope, timing, and victim count remain incomplete.
Q: What do security teams get wrong about OAuth and connected apps?
A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust. OAuth grants can outlive the original need, inherit too much scope, or become a bridge into multiple SaaS tenants. Security teams should treat each grant as a revocable access path, not a permanent integration.
Q: Who is accountable when a compromised SaaS integration is used to move across multiple clouds?
A: Accountability sits with the teams that own connected-app governance, SaaS administration, and cloud identity controls, because the failure crosses system boundaries. A single platform team cannot see the whole path. Organisations should map responsibility for consent, revocation, logging, and secret response before the next integration is authorised.
Technical breakdown
Why OAuth tokens become a cross-tenant access path
OAuth tokens grant delegated access without re-authenticating on every action, which makes them efficient and dangerous when the integration itself is compromised. In the Salesloft-Drift case, the compromised third-party app became a bridge into Salesforce and Google Workspace across downstream customers. That changes the security question from who clicked a malicious link to which integration can act on behalf of whom, across which services, and for how long. The technical issue is not just token theft. It is delegated trust with insufficient visibility into the resulting access path.
Practical implication: Map every OAuth grant to the systems it can reach and treat those grants as governed identities, not harmless plumbing.
Why single-tenant log search misses SaaS supply chain abuse
Traditional investigations look for indicators inside one environment, but SaaS supply chain attacks are often distributed across many tenants and platforms. Obsidian's point is that local logs do not tell you whether an integration event is unique or part of a multi-customer pattern. That matters because attacker activity can resemble normal integration behaviour in any one organisation. Cross-tenant intelligence works by normalising events, comparing patterns, and resolving identities across services so the same malicious infrastructure is visible as one story rather than many fragments.
Practical implication: Build detection and investigation workflows that compare integration behaviour across tenants, not just inside one customer boundary.
Cross-service identity correlation is the control that changes the hunt
Identity correlation across SaaS means normalising fields such as UPN, email, display name, IP, and user-agent so events from different applications can be joined reliably. Without that step, a Salesforce audit log and a Google Workspace admin log look unrelated even when they are part of the same attack path. Obsidian shows that identity becomes the join key for investigation when the enterprise runs on many SaaS controls. This is especially important where human users, service accounts, and application identities all produce similar telemetry but different risk.
Practical implication: Standardise identity fields across SaaS telemetry before you depend on them for threat hunting or breach validation.
Threat narrative
Attacker objective: The attackers aimed to harvest and pivot through trusted SaaS access to maximise downstream exposure across many customer environments at once.
- Entry occurred through a compromised OAuth integration, where attackers abused the access granted to the Drift app rather than attacking each organisation directly.
- Escalation happened when the same delegated access was used to pivot from Salesforce into Google Workspace and other downstream environments.
- Impact was a one-to-many SaaS supply chain breach that expanded the victim set across hundreds of organisations and obscured the full blast radius from local investigation alone.
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
Integration-layer identity is now the real SaaS perimeter. Obsidian's research reinforces that the attack surface in SaaS is not just the human user or the application itself, but the delegated identity sitting between them. OAuth grants, connected apps, and service tokens create standing access relationships that can be abused at scale when trust is inherited from the integration rather than continuously verified. Practitioners should treat every connected app as a governed identity with scope, ownership, and expiry.
Cross-tenant correlation is becoming a core identity investigation capability. The difference between finding one suspicious log entry and understanding a supply chain breach is the ability to compare behaviour across customers, tenants, and services. That makes identity normalisation a detection requirement, not a reporting convenience. The implication for security architecture is clear: if telemetry cannot be correlated across SaaS boundaries, the team cannot reliably measure blast radius or confirm containment.
Standing SaaS trust creates an identity blind spot analogous to unrotated NHI credentials. The same governance failure appears in different forms across machine identities, integrations, and agentic access: access is granted once and then assumed safe until something breaks. That assumption fails when a third-party app can act across many environments without fresh accountability. Practitioners should recognise this as lifecycle failure, not just incident response failure.
Cross-service identity correlation: this is the named control concept this breach makes unavoidable. Normalising identity fields across applications and tenants is what turns fragmented telemetry into a usable investigation graph. Without it, security teams are left with isolated evidence that cannot prove scope, sequence, or ownership, which leaves blast-radius decisions late and incomplete.
SaaS supply chain governance now belongs inside identity programmes. The article shows why connected applications cannot remain a separate cloud or vendor-management issue. OAuth scope, integration ownership, and offboarding need the same discipline applied to other non-human identities. Teams that keep treating integrations as peripheral assets will continue to underestimate how quickly one compromise can become many.
From our research:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- That same report says 80% of organisations report AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
- For a deeper lens on the control gap, see OWASP NHI Top 10 for the agentic access patterns that make identity correlation harder.
What this signals
The immediate programme implication is that SaaS security and NHI governance can no longer be separated cleanly. If an organisation cannot correlate integration behaviour across services, it will struggle to prove containment, validate offboarding, or explain why one compromised app became a multi-platform incident.
Integration identity drift: teams should expect the boundary between application, service account, and delegated SaaS access to keep blurring. That makes lifecycle ownership, scope review, and telemetry normalisation the controls that determine whether investigations stay local or become enterprise-wide.
This is also where agentic and NHI programmes converge. As more AI systems and automations consume SaaS APIs, the same cross-service visibility problem will apply to machine identities that can act faster than human review cycles can keep up.
For practitioners
- Inventory every SaaS integration as a governed identity Build a complete register of OAuth grants, connected applications, and service tokens, including owner, scope, expiry, and the business service each one can reach. Prioritise integrations with broad delegated access across Salesforce, Google Workspace, and other core platforms.
- Correlate SaaS telemetry across tenants and services Normalise user-agent, IP, email, UPN, and display name fields so an indicator in one platform can be compared against activity in another. Use cross-tenant comparison to separate routine integration noise from shared attacker infrastructure.
- Tie integration offboarding to access revocation When a vendor relationship changes or an app is no longer required, revoke the token, disable the grant, and verify the removal across all connected SaaS systems. Do not rely on a single console to confirm that access has truly ended.
- Baseline legitimate integration behaviour Capture normal timing, infrastructure, and user-agent patterns for each approved integration so deviation becomes measurable. Treat unusual user-agent strings or new source networks as investigation triggers, especially when they appear across multiple tenants.
Key takeaways
- The breach shows that SaaS integrations can function as high-blast-radius identities when their delegated access is not governed like any other credentialed actor.
- Cross-tenant intelligence and cross-service identity correlation are what exposed the full scope, not isolated log review.
- Teams need integration lifecycle controls, telemetry normalisation, and ownership discipline before another compromised app turns into many victims.
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 CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | OAuth grants and connected apps are the central identity asset in this breach. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0008 , Lateral Movement | The breach relied on credentialed access and pivoting across SaaS services. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance applies directly to delegated SaaS access and offboarding. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator lifecycle control fits compromised OAuth tokens and related secrets. |
| NIST Zero Trust (SP 800-207) | The breach exposes assumptions about implicit trust across connected SaaS services. |
Use zero trust principles to revalidate access between applications rather than inheriting trust.
Key terms
- OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
- Cross-tenant Intelligence: Cross-tenant intelligence is the practice of comparing security telemetry across multiple customer environments to identify shared attacker behaviour, not just local anomalies. It matters in SaaS supply chain incidents because the same compromise can look ordinary inside one tenant but reveal its true scale when seen across many.
- Integration identity: An integration identity is the non-human credential or trust relationship used to connect one system to another. In practice, it often includes API keys, OAuth grants, service accounts, certificates, and the permissions that let automation read, transform, or publish identity data.
What's in the full report
Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The cross-tenant query logic used to identify impacted organisations across more than 200 connected SaaS platforms
- The specific detection patterns for user-agent baselining, IP prevalence scoring, and identity field normalisation
- The sequence of investigation steps that surfaced Google Workspace scope before wider public reporting
- The practical examples of how expanded IOC lists were used to stabilise the victim set
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity security capability across human, non-human, and autonomous systems, it is worth exploring.
Published by the NHIMG editorial team on August 14, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org