Salesloft and Gainsight breaches expose integration NHI trust gaps

At a glance

What this is: This analysis shows how compromised integration tokens and OAuth scopes let attackers move through Salesforce as trusted non-human identities and harvest downstream secrets.

Why it matters: It matters because IAM, PAM, and NHI programmes must treat integrations as first-class identities, or they will keep missing the privileges that attackers can abuse without ever breaking MFA.

👉 Read Hush Security's analysis of the Salesloft and Gainsight NHI breaches

Context

The governance gap is straightforward: organisations often secure the human login path while leaving integrations, tokens, and delegated app access with broad, durable trust. In this case, the primary keyword is NHI risk, and the article argues that the real exposure sits inside trusted non-human identities rather than at the perimeter.

That matters for IAM teams because integration identities now behave like privileged access paths into SaaS and cloud environments. If token scope, revocation, and downstream secret handling are not governed as identity controls, attackers can move from one compromised integration into multiple connected systems without triggering the usual human-authentication defences.

Key questions

Q: What breaks when an integration token is treated as low risk?

A: The access model breaks first. A delegated token can carry broad scopes, bypass MFA, and remain valid long enough for an attacker to harvest downstream secrets and pivot into connected systems. Once teams classify integrations as low risk, they stop governing scope, lifecycle, and revocation with the same discipline they apply to privileged accounts.

Q: Why do third-party SaaS integrations increase blast radius?

A: They increase blast radius because one trusted app can reach multiple systems, data stores, and secret locations at once. If that app is compromised, the attacker inherits every downstream entitlement attached to its scopes. The risk is not the number of integrations alone, but how far each one can travel through the identity chain.

Q: How should teams govern OAuth apps with elevated scopes?

A: Treat them as first-class identities with owners, approved scopes, review dates, and revocation paths. Teams should log every entitlement the app can reach, review whether the scope still matches the use case, and remove any secret exposure that the integration does not operationally need.

Q: Who is accountable when a compromised integration exposes customer data?

A: Accountability sits with the teams that approved, owned, and monitored the delegated access, not only with the vendor platform. Security, IAM, and application owners all share responsibility for scope design, token lifecycle, and downstream secret hygiene, because those controls determine whether the integration can be abused at scale.

Technical breakdown

How compromised OAuth and refresh tokens become trusted access

OAuth access tokens and refresh tokens are delegated credentials, not passwords. When an integration is granted broad scopes, those tokens inherit the ability to act inside target systems as a trusted NHI, even when the original user never returns to the session. That is why a compromised integration can bypass MFA entirely. The failure is not authentication at the front door, but delegated authority that remains valid after the initial trust decision. In SaaS ecosystems, this creates a durable path into customer data, metadata, and adjacent services.

Practical implication: inventory every integration token by scope and revoke any delegated access that is broader than the business task requires.

Why downstream secrets become the real prize

Once attackers land inside a trusted integration context, the objective usually shifts from the first system to the secrets it can reach. Integrations often have access to support cases, environment metadata, cloud credentials, or API keys embedded in workflows and logs. That turns one compromised NHI into a bridge across multiple identity domains. The technical weakness is not just token theft. It is secret propagation through connected services where one identity can expose credentials for many more. This is why cloud access keys and Snowflake tokens often appear after the initial SaaS compromise.

Practical implication: trace which downstream credentials each integration can read, and remove secret exposure from systems that do not need it.

How broad third-party scopes create supply-chain blast radius

Third-party integrations with elevated OAuth scopes behave like supply-chain identities. They are trusted by default, often monitored less closely than human admins, and can retain access long after the original business need has changed. If revocation, logging, and app governance are weak, attackers can reuse one foothold across multiple customer tenants or connected applications. This is not a platform exploit. It is a governance failure in delegated access management, where the blast radius is defined by scope, not by perimeter strength.

Practical implication: apply first-class governance to third-party apps, including scope review, continuous logging, and fast token revocation.

Threat narrative

Attacker objective: The attacker wants to turn one trusted integration into a scalable path for harvesting secrets and moving laterally into connected cloud and SaaS environments.

1. Entry occurs through a compromised integration token or OAuth scope rather than a direct platform exploit, giving the attacker legitimate access through a trusted non-human identity.
2. Credential access follows as the integration reveals downstream secrets such as cloud keys, Snowflake tokens, support content, and operational metadata.
3. Escalation happens when those harvested secrets are used to pivot into adjacent systems and expand access across connected environments.
4. Impact is the theft of customer data and the widening of organisational blast radius across SaaS and cloud services.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 has become the new perimeter failure. The breach pattern here is not that attackers defeated Salesforce, MFA, or the user login path. It is that organisations granted broad delegated authority to integrations and treated those tokens as safe by default. That is a governance model problem, not a platform problem. The implication is that every premium-scope integration now sits in the same risk class as privileged access.

Delegated access without lifecycle offboarding is a standing-privilege problem. These incidents show what happens when third-party app access is created but not continuously re-validated against business need, scope, and revocation status. Access can persist after the original purpose changes, which turns legitimate delegation into long-lived exposure. The practitioner conclusion is that lifecycle control for integrations must be as rigorous as it is for human privileged accounts.

Identity blast radius is now defined by connected systems, not single accounts. Once one NHI is compromised, the attacker’s reach is determined by what that identity can read, export, or trigger downstream. That makes secret storage, token scope, and app-to-app trust more important than the front-end login controls many teams still prioritise. Security teams should measure how far one integration can travel before they assume the breach is contained.

Third-party integrations must be governed as first-class identities, not as convenience features. The article exposes a common assumption that vendor apps are merely connectors. In practice, they are identity-bearing access paths with their own entitlements, logs, and compromise potential. Teams that keep treating them as tooling rather than identities will keep underestimating the attack surface. The implication is a formal NHI governance model for every external integration.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which leaves most integration governance blind to where trust is actually concentrated.
• For a broader control lens, 52 NHI Breaches Analysis shows how compromised machine identities repeatedly become the entry point for wider incidents.

What this signals

Identity programmes that still separate SaaS integrations from privileged access are carrying hidden risk debt. The next wave of exposure is not the human login path, it is the delegated identity that can see more than its operators realise. Organisations that do not model integration scope, owner, and downstream reach will keep discovering compromise only after secrets have already been harvested.

92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That figure explains why integration governance is now a board-level identity issue rather than a niche SaaS control. Teams should expect more incidents where the initial foothold looks like ordinary app connectivity.

Integration trust debt: the longer a third-party app keeps elevated scopes, the more it behaves like a standing privilege path rather than a temporary connection. Programme owners should prepare for token review, app offboarding, and secret minimisation to become part of standard IAM operating rhythm.

For practitioners

• Map every integration by scope and downstream reach Build an inventory of all OAuth apps, service accounts, and connected bots that touch Salesforce or similar SaaS platforms. Record which downstream systems each one can read, write, or trigger, including cloud keys, support content, and operational metadata.
• Revoke third-party tokens on a shorter lifecycle Set explicit ownership and expiration for every integration token, then remove anything that still has broad access after the business use case changes. Token revocation should be a routine lifecycle event, not a post-breach exception.
• Separate secrets from integration-readable data Remove API keys, cloud access credentials, and other reusable secrets from systems that integrations can inspect unless there is a documented operational need. Where exposure is unavoidable, isolate the secret and reduce the scope of the reading identity.
• Treat vendor apps as privileged identities Apply approval, logging, and periodic access review to third-party SaaS apps with elevated scopes. If an app can access customer data or internal metadata, it belongs in the same governance process as any privileged account.

Key takeaways

• The core failure is not a platform exploit but over-trusted delegated access that lets attackers use integrations as legitimate entry points.
• The impact is broad because one compromised integration can expose multiple downstream secrets and open paths into cloud and SaaS environments.
• The control that matters most is first-class lifecycle governance for third-party apps, including scope review, revocation, and secret minimisation.

Key terms

• Non-Human Identity: A non-human identity is any machine, service, or application credential used to access systems on behalf of a process rather than a person. It includes service accounts, API keys, OAuth tokens, certificates, and workload identities that can carry privilege across tools and environments.
• Delegated Access: Delegated access is permission granted to one identity to act within another system or service under a defined trust relationship. In NHI risk, the concern is that the delegated path often outlives the original use case and can be abused if token scope, ownership, or revocation is weak.
• Identity Blast Radius: Identity blast radius is the amount of damage one compromised identity can create across connected systems. It depends on scope, downstream entitlements, and secret exposure, not just on whether the first credential was stolen.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. For non-human identities, it becomes especially risky when tokens, scopes, or app permissions stay active after the business need has changed.

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 Hush Security covering the Salesloft and Gainsight breaches: What the Salesloft and Gainsight breaches really tell us about NHI risk. Read the original.