Salesloft and Gainsight breaches expose integration NHI trust gaps

At a glance

What this is: This analysis argues that the Salesloft and Gainsight breaches were driven by compromised integration identities, not Salesforce platform weakness, and that those NHIs exposed downstream secrets after legitimate access was obtained.

Why it matters: It matters because IAM and NHI programmes must treat third-party integrations as first-class identities with scope, lifecycle, and downstream blast-radius controls, not as invisible plumbing.

Context

The security gap here is trust in privileged integrations that can enter critical SaaS environments with authenticated access and then move beyond the original application boundary. In NHI terms, the problem is not whether the platform accepts the login, but whether the integration identity should have been trusted to carry that level of privilege in the first place.

Salesloft and Gainsight are being used as examples of a wider governance failure: organisations can harden MFA and still leave integration tokens, refresh tokens, and OAuth scopes with more authority than the business can safely observe or revoke. Once those identities are compromised, the blast radius reaches connected systems, not just the primary SaaS tenant.

Key questions

Q: What breaks when a stolen OAuth token is used against a trusted integration?

A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy. In practice, stolen delegated access can bypass interactive authentication and continue until revocation or expiry, which is why connected app tokens need ownership, monitoring, and fast containment.

Q: Why do service accounts and integrations increase breach impact?

A: Service accounts and integrations often hold broad permissions, long-lived credentials, and weak human oversight. If one is compromised, the attacker may be able to reach multiple systems, move laterally, and exfiltrate data without triggering the same friction that would apply to a human user. That makes non-human identities a high-value route to blast-radius expansion.

Q: How do security teams know whether integration scope is too broad?

A: Scope is too broad when the integration can reach systems, secrets, or functions that are not essential to its business purpose. A practical test is whether revoking a single integration would disrupt only the intended workflow or whether it would also cut off unrelated access paths and hidden downstream dependencies.

Q: Who should own NHI offboarding when development teams change?

A: NHI offboarding should be owned by a named control function, not left to whichever team used the credential last. Shared use without accountable ownership is how access survives project changes, team moves, and vendor transitions. A clear owner is the only practical way to prove revocation happened.

Technical breakdown

How compromised OAuth tokens become trusted entry points

OAuth access and refresh tokens can function as durable non-human identities when they are granted broad scopes and reused across connected systems. If a token is stolen, the attacker does not need to break primary authentication again. The token itself becomes the authentication proof, and the platform treats the request as legitimate. That is why these incidents bypassed MFA. The security boundary moved from human sign-in to token possession, which is a different control problem entirely. In SaaS integrations, the real issue is not whether OAuth is weak, but whether the issued scope is wider than the task requires.

Practical implication: govern OAuth scopes and refresh token lifetime as identity controls, not just application settings.

Why downstream secrets become the real payload

A compromised integration rarely stops at the first system. Once inside, attackers often reach stored secrets, API keys, support data, and cloud access credentials embedded in the connected workflow. That makes the initial token a bridge into other identities and control planes, especially where services trust each other by default. The article’s pattern is classic supply-chain style identity abuse: one trusted NHI opens several downstream trust relationships. The key technical failure is that the integration identity is allowed to reach places where sensitive credentials are exposed or retrievable through ordinary business processes.

Practical implication: map every integration to the downstream secrets and systems it can reach, then reduce that reach to the minimum necessary.

How scope and persistence create hidden identity blast radius

A privileged integration can persist long after the original business need changes. If scopes are broad and revocation is slow, the token becomes a standing access path that is hard to distinguish from legitimate automation. This is why the blast radius is not limited to the application where compromise begins. Connected services inherit trust through delegation chains, and the organisation often lacks a clean ownership model for those machine identities. The operational problem is not just theft. It is the combination of excessive scope, weak offboarding, and poor visibility into which systems still trust the compromised identity.

Practical implication: treat integration offboarding and token revocation as part of the same lifecycle process.

Threat narrative

Attacker objective: The attacker’s objective was to use trusted integration credentials to reach Salesforce data and harvest downstream secrets that could extend access into cloud infrastructure and related systems.

1. Entry occurred through compromise of OAuth and refresh tokens tied to a trusted integration, allowing the attacker to authenticate as a legitimate non-human identity.
2. Privilege was not escalated through classic exploitation because the token already carried the scopes needed to reach Salesforce and related systems.
3. The attacker then pivoted through connected environments and extracted downstream secrets including Snowflake tokens, cloud access keys, support-case content, and operational metadata.
4. Impact was achieved by turning a trusted integration into a cross-system access path that exposed broader customer and cloud credentials.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

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 trust debt is now the core governance problem: The Salesloft and Gainsight incidents show that organisations have allowed third-party integrations to accumulate authority that is never revalidated against current business need. OAuth scopes, refresh tokens, and app permissions are treated as plumbing, but they behave like durable identities with real blast radius. The practitioner conclusion is that integration trust has to be governed as a lifecycle, not accepted as a one-time onboarding decision.

Privileged integration scope is a hidden identity control plane: These incidents did not require a platform vulnerability because the token already represented an authorised path into the environment. That means the real attack surface is the trust relationship between the SaaS tenant and the connected NHI, especially where broad scopes permit downstream discovery and secret access. The practitioner conclusion is that scope review must be tied to the connected systems that can be reached, not just the app that issued the token.

Downstream secret exposure is the actual breach multiplier: Once an integration lands inside Salesforce, the damage is no longer limited to CRM records. The article’s own evidence shows cloud access keys, Snowflake tokens, and support-case content becoming part of the compromise path, which turns one token theft into multi-system exposure. The practitioner conclusion is that secret placement inside business workflows must be treated as a breach-amplifier, not an implementation detail.

Vendor app governance belongs in NHI governance, not procurement: The Gainsight follow-on activity reinforces that third-party integrations can be reused, chained, or repurposed by attackers after the first compromise. That creates a governance gap between commercial onboarding and identity security operations. The practitioner conclusion is that every vendor app with OAuth access should be managed as a first-class NHI with inventory, owner, scope, and revocation accountability.

Identity blast radius is the right named concept for this pattern: A compromised integration can move from one trusted login to many connected secrets without needing to defeat each control separately. That is not simple account compromise, but expansion through delegated trust across systems. The practitioner conclusion is that practitioners should measure where one NHI can fan out into multiple credential domains and reduce that blast radius before incident response has to.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Integration trust debt is a useful way to describe this pattern: every additional OAuth grant, refresh token, and vendor app permission accumulates future exposure that is rarely re-evaluated until after compromise. IAM teams should treat these connections as governed identity assets, not static configuration.

The practical shift is from human login protection to delegated access control over NHIs. When a trusted integration can inherit broad scopes, the security model must account for how far that identity can move, what secrets it can reach, and how quickly it can be revoked when business need changes.

For practitioners

• Inventory all premium-scope integrations Build a complete register of service accounts, bots, and third-party apps that touch Salesforce and adjacent cloud systems. Include owner, purpose, issued scopes, refresh token status, and downstream systems reachable through the integration.
• Reduce OAuth scope to task minimums Review every integration for scopes that exceed the business workflow it supports, then narrow access so a single token cannot traverse unrelated data sets or administrative functions.
• Treat token revocation as incident containment When an integration is suspected compromised, revoke active and refresh tokens first, then rotate downstream secrets and invalidate any credentials exposed through the connected workflow.
• Map downstream credential exposure paths Trace where integrations can reach stored secrets, API keys, support data, and cloud access credentials so you can remove hidden trust chains before they are abused.
• Assign lifecycle owners to third-party NHIs Make a named business owner accountable for each vendor app and integration identity, including onboarding approval, periodic scope review, and formal offboarding when the relationship changes.

Key takeaways

• The breach pattern shows that trusted integrations can become the primary entry point even when MFA and SaaS hardening are in place.
• The article says attackers used legitimate token-based access to reach Salesforce and then harvested downstream secrets such as Snowflake tokens and cloud access keys.
• The control failure was excessive integration trust, which would have been reduced by narrower scopes, faster revocation, and explicit ownership of third-party NHIs.

Key terms

• Integration NHI: An integration NHI is a non-human identity used by a vendor app, service account, bot, or connected workflow to authenticate into another system. In practice it can carry durable authority across SaaS and cloud services, so its scope, ownership, and revocation need the same governance discipline as any privileged identity.
• OAuth Scope: An OAuth scope is a permission string that defines what an application can do on behalf of a user. In practice, scopes set the blast radius of delegated access, because the token carries the right to read, write, or administer resources until it is revoked or expires.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 or maturing an IAM programme, it is worth exploring.