Salesloft breach shows how NHI compromise can cascade across SaaS

At a glance

What this is: This is Permiso Security’s analysis of the Salesloft breach, showing how stolen OAuth tokens and downstream credential harvesting turned one compromised SaaS integration into a broader NHI incident.

Why it matters: It matters because IAM, PAM, and NHI programmes have to govern third-party tokens, token scope, and logging together, or a single integration can become an enterprise-wide access path.

👉 Read Permiso Security’s analysis of the Salesloft breach and NHI exposure

Context

Salesloft breach analysis is really about NHI governance, not just a SaaS incident. A compromised integration can behave like a privileged machine identity, especially when its tokens, downstream access, and logging controls are managed separately from the rest of the identity stack.

The article shows how a GitHub compromise, dormant access, token theft, and credential harvesting combined into a supply chain path across Salesforce, Google Workspace, Snowflake, and AWS. That is a familiar pattern for modern identity teams: the weakest control is rarely the first compromise, it is the lack of containment once non-human access starts moving across systems.

Key questions

Q: What breaks when a SaaS integration with per-user OAuth tokens is compromised?

A: A per-user OAuth model can turn one integration breach into hundreds of separate access paths, because each token carries the reach of the individual account behind it. That widens blast radius, complicates revocation, and can expose administrative privileges if a high-value user was connected through the integration.

Q: Why do exported SaaS datasets create extra identity risk?

A: Exported data often contains credentials, API keys, and tokens that are no longer protected by the source application’s controls. Attackers can mine those exports offline, which means a breach can continue even after the original access path is detected. That is why export control and secret scanning must be linked.

Q: What do security teams get wrong about SaaS breach containment?

A: They often focus on the compromised application and miss the downstream credential graph. If an attacker can pivot from one platform into cloud storage, identity services, or other SaaS tools, containment has to include those dependent systems, not just the first breached tenant.

Q: How should teams respond when OAuth tokens may have been abused?

A: Revoke suspicious tokens first, then reset any credentials that could have been exposed through exported data or linked systems. After that, trace unusual API activity, guest additions, and bulk export behaviour so you can identify which downstream environments also need review.

Technical breakdown

GitHub repository access as the first foothold

The initial access path began in development infrastructure, where the attacker gained access to GitHub repositories and likely cloned or downloaded code and related assets. That matters because repository content often contains secrets, workflow definitions, and deployment paths that are invisible to application owners but highly useful to an attacker. In this case, the repository foothold created a route toward cloud infrastructure and persisted long enough to support later token theft. The security lesson is that source control is not just code storage; it is often an identity boundary carrying machine credentials, CI/CD trust, and cloud-adjacent privileges.

Practical implication: protect repositories as identity-bearing assets and treat repository access, workflow changes, and secret exposure as a single control surface.

OAuth token theft and downstream access scope

The core compromise was not password theft, but abuse of OAuth tokens tied to individual users. Because the Drift integration used per-user tokens, the attacker inherited whatever each user could reach in Salesforce, and in some cases that included administrative privilege. This is a classic NHI problem: delegated access can look tightly scoped at issuance time while remaining dangerously broad at use time. The architecture also multiplied the number of compromise points, turning a single integration into hundreds of exploitable credential paths across the customer base.

Practical implication: inventory delegated OAuth grants by user, privilege level, and connected system so you can revoke at the token layer, not just at the application layer.

Exported data became a credential-mining channel

After accessing Salesforce instances, the attacker exported accessible data and then searched it externally for long-lived credentials such as AWS keys. That approach avoids triggering alerting tied to suspicious searches inside the SaaS platform because the attacker shifts the analysis step out of the defended environment. Bulk export, especially from non-service accounts, becomes both the exfiltration mechanism and the credential discovery mechanism. This is why data egress controls and secret scanning matter together, not as separate programmes.

Practical implication: monitor bulk export behaviour from SaaS systems and scan exported datasets for secrets before attackers can mine them offline.

Threat narrative

Attacker objective: The objective was to turn one compromised SaaS integration into broader access across connected environments, harvest more credentials, and exfiltrate sensitive data at scale.

1. Entry occurred through a GitHub compromise between March and June 2025, giving the attacker access to development assets and a pathway toward cloud-connected systems.
2. Credential access followed when OAuth tokens were stolen and used to enter Salesforce instances, export data, and mine that data for additional credentials such as AWS keys.
3. Impact expanded across connected services, including Google Workspace, Snowflake, and AWS, as the attacker used stolen material to widen access and increase exfiltration scope.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Salesloft breach analysis confirms that delegated NHI trust is a blast-radius problem, not an application feature. The issue was not only that tokens existed, but that a compromised integration could inherit broad user reach and move across multiple connected systems. When per-user OAuth grants are paired with weak environment segmentation, one compromise becomes many. Practitioners should treat every delegated integration as an access boundary that can enlarge incident scope.

Credential harvesting from exported SaaS data is a standing NHI failure mode, not an edge case. The attacker did not need to stay inside Salesforce to find value, because exported records can contain long-lived keys, tokens, and other secrets that outlive the original compromise. That pattern aligns with the broader NHI problem space documented in the Ultimate Guide to NHIs, where visibility and rotation remain chronic weak points. Practitioners should assume that data export may become secret discovery.

GitHub access was the real identity control plane in this breach. Development repositories, workflow definitions, and repository-scoped secrets created the route into cloud-connected systems before the SaaS tokens were even abused. That makes source control governance part of NHI governance, not a separate DevOps concern. The practical conclusion is simple: if repositories can expose credentials or deployment paths, they are already part of your identity attack surface.

Bulk export detection is the missing control that often decides whether a supply chain breach stays narrow or becomes ecosystem-wide. The attacker relied on behaviour that looked legitimate in small tests, then scaled into high-volume extraction. That pattern is directly addressed by 52 NHI Breaches Analysis, which shows how secret exposure and standing access repeatedly compound each other. Practitioners should build detections around behaviour, not just known bad indicators.

Salesloft shows why incident response for NHIs must include the downstream credential graph, not just the breached application. Once a token or export path is abused, every connected system that consumed those credentials becomes part of the response scope. That means customer tokens, admin grants, storage secrets, and third-party access paths all need coordinated review. Practitioners should map the credential graph before they need it in an incident.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• The broader lesson is covered in 52 NHI Breaches Analysis, which tracks how exposure, persistence, and slow revocation compound into repeated incidents.

What this signals

Salesloft is a warning that NHI governance has to extend into every delegated SaaS integration. When an application can act on behalf of many users, the access model is already part of your identity perimeter. Teams that still separate SaaS administration, secret management, and identity review will continue to miss the path from token theft to ecosystem compromise. The control question is no longer whether integrations are convenient, but whether they can be contained when trust fails.

Credential exposure debt is the named concept this breach reinforces. Exports, logs, and repository artefacts can hold usable secrets long after the primary compromise is contained, which means remediation time matters as much as detection time. With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per Ultimate Guide to NHIs , Key Challenges and Risks, the next breach may begin where the last one ended. Practitioners should focus on reducing the number of places where usable secrets can survive an incident.

Repository governance is now part of identity governance. If source control can reveal deployment paths, service credentials, or integration logic, then your IAM programme needs to include development systems in its review scope. That is especially true for platforms that bridge SaaS and cloud services, where one leaked workflow can become a privileged access route. The practical signal is simple: development metadata is often the shortest path from code to compromise.

For practitioners

• Audit delegated OAuth grants by user and scope Review every SaaS integration that issues per-user OAuth tokens, then classify grants by user, admin reach, and connected systems. Prioritise revocation paths that can be executed at the token layer without waiting for application owners to act.
• Correlate repository access with secret exposure Treat repository clones, workflow edits, and guest-user additions as identity events, then correlate them with any repository-stored credentials or deployment paths. This helps surface the route from source control into cloud and SaaS environments.
• Detect bulk export behaviour from non-service accounts Baseline normal API volume for human and machine identities, then alert on sudden bulk exports, unusual query patterns, and rapid job deletion after export completion. This is the control that turns SaaS logs into useful breach signals.
• Scan exported SaaS data for dormant secrets Assume exfiltrated records may contain AWS keys, tokens, and other usable secrets, then run automated scanning over exported datasets and response artefacts. The goal is to stop offline credential mining from becoming the next phase of the incident.

Key takeaways

• The Salesloft breach was a full NHI supply chain compromise, not just a SaaS security incident.
• Its impact scaled because delegated OAuth access, exported data, and stored secrets all reinforced one another.
• Teams need token revocation, export monitoring, and downstream credential tracing before a breach reaches connected systems.

Key terms

• Delegated OAuth token: A delegated OAuth token is an access credential issued to an application or user on behalf of another system. In practice it can inherit broad permissions, which makes scope, revocation, and monitoring critical once the token is used across connected SaaS or cloud services.
• Credential exposure debt: Credential exposure debt is the accumulation of usable secrets in exports, logs, repositories, and other places that survive the original compromise. The longer those artefacts remain valid, the more likely an attacker can mine them offline and extend the breach into new systems.
• Bulk export behaviour: Bulk export behaviour is large-scale data extraction from a SaaS or cloud platform, usually through API-driven queries or report downloads. It becomes a security signal when non-service accounts or unusual identities suddenly move more data than their normal role requires.
• Downstream credential graph: A downstream credential graph is the set of systems, tokens, and secrets that become reachable after one identity is compromised. It helps investigators trace how one breach spreads across connected services instead of stopping at the first application that was accessed.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Permiso Security covering the Salesloft breach: Anatomy of the Salesloft Breach - Detection, Response, and Lessons Learned. Read the original.