Salesloft and Gainsight breaches expose the NHI trust gap

At a glance

What this is: This analysis shows how the Salesloft and Gainsight breaches turned trusted integrations into entry points for authenticated access and downstream secret theft.

Why it matters: IAM and NHI teams need to treat integrations as first-class identities because token abuse can bypass MFA and expose connected cloud systems.

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

Context

Non-human identities are the access layer behind service accounts, integrations, bots, and tokens, and they become a governance problem when their privileges exceed what teams can observe or revoke quickly. The Salesloft and Gainsight incidents show that the primary risk is not platform compromise in the traditional sense, but trusted access chains that security teams often fail to inventory end to end.

For IAM and NHI practitioners, this is a familiar but often under-managed pattern: a legitimate integration becomes the entry point, then downstream secrets and connected systems become the real objective. The source article frames 2025 as a point where the attacker no longer needs to break the gate, which is consistent with the broader NHI exposure problem documented in the Ultimate Guide to NHIs.

Key questions

Q: How should security teams handle trusted integrations that can access production systems?

A: Security teams should classify trusted integrations as privileged non-human identities, not as low-risk plumbing. That means assigning owners, limiting scopes, enforcing short token lifetimes, and reviewing access on a schedule. If an integration can reach production data or cloud control planes, it needs the same governance discipline as any elevated account.

Q: When does an integration token become a major security risk?

A: An integration token becomes a major risk when it has broad scopes, long-lived refresh capability, or access to systems that store additional credentials. At that point, one compromise can expose several adjacent identities and services. The risk is highest when the token can read operational data or trigger downstream automation.

Q: What is the difference between revoking an integration and rotating downstream secrets?

A: Revoking an integration cuts off the initial access path, but it does not automatically invalidate every credential the attacker may have already seen. Rotating downstream secrets removes the attacker’s ability to reuse exposed keys, tokens, or certificates. Mature incident response does both, because token revocation alone is rarely enough.

Q: Why do non-human identities complicate zero trust architecture?

A: Non-human identities complicate zero trust because many are trusted by default, use machine-to-machine authentication, and operate continuously without interactive challenge. Zero trust expects continual verification, but integrations often retain standing access unless teams deliberately constrain them. The result is a mismatch between policy intent and actual machine access.

Technical breakdown

How compromised OAuth tokens become trusted NHI access

OAuth access and refresh tokens are delegated credentials, which means they inherit authority from the application registration and the granted scopes. When an attacker steals those tokens, the platform often sees legitimate authenticated activity rather than an obvious intrusion. That makes token compromise especially dangerous in SaaS environments because the initial access path blends into normal integration traffic. Once the token is accepted, the attacker can query data, request connected objects, and sometimes access adjacent services that trust the same integration. The failure mode is not encryption or password weakness. It is over-broad delegated trust combined with long-lived credentials and weak revocation discipline.

Practical implication: Treat OAuth tokens as privileged NHI credentials and constrain scope, lifetime, and revocation speed.

Why downstream secret harvesting is the real blast-radius problem

The immediate value of a compromised integration is often not the first system itself, but the secrets it can expose once authenticated. In practice, a trusted integration can surface cloud API keys, storage credentials, support-case content, and operational metadata that should never have been reachable through a single identity path. This creates a chained compromise model where one NHI breach fans out into several others. The architectural issue is that many enterprises manage secrets and integrations in separate workflows, so revocation stops at the initial token while the downstream credentials remain valid. That leaves attackers free to continue moving with legitimate artifacts.

Practical implication: Build revocation and secret-rotation playbooks that assume downstream credential exposure after any NHI compromise.

Why third-party integrations need the same scrutiny as internal accounts

Third-party integrations are effectively externalized identities with standing access to internal systems. They often bypass the governance controls applied to human users because teams classify them as operational dependencies instead of access subjects. That creates a blind spot in reviews, logging, and offboarding. When an integration is granted elevated OAuth scopes, the organisation is not just connecting a tool, it is extending the trust boundary. The result is a supply-chain style identity risk where the attacker can inherit legitimacy through a vendor-controlled application, then pivot inside the customer environment without exploiting the platform itself.

Practical implication: Inventory vendor apps, map their scopes, and review them like any other privileged identity path.

Threat narrative

Attacker objective: The attacker objective is to turn one trusted integration into repeated authenticated access across connected enterprise systems and secret stores.

1. Entry via stolen OAuth and refresh tokens tied to a trusted integration, which allowed authenticated access without defeating MFA.
2. Escalation through legitimate API access that exposed downstream secrets, including cloud access keys and other reusable credentials.
3. Impact through lateral movement into connected SaaS and cloud environments, using harvested secrets to widen access and persistence.

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

The core issue is not OAuth itself, but delegated trust without NHI governance. OAuth is a normal part of SaaS integration, but organisations frequently grant scopes that outlive the business need and are rarely reviewed with the same discipline as human entitlements. Once an integration becomes a trusted conduit, an attacker no longer needs platform exploitation. The practical conclusion is that delegated access must be governed as privileged identity, not treated as a convenience layer.

Integration tokens now represent identity blast radius, not just access tokens. A single compromised NHI can expose multiple downstream systems because integrations often sit at the intersection of CRM, cloud, support, and automation workflows. That means breach response has to trace every connected credential and every system that trusted the same token. Practitioners should think in terms of blast-radius reduction, not just containment of the initial credential.

Third-party app sprawl is a governance failure before it is an incident response problem. Organisations that cannot inventory vendor integrations, their scopes, and their revocation paths are already behind the attacker. The issue is structural because app approvals often happen faster than lifecycle controls. Teams should move integrations into the same governance model used for privileged human access, with formal ownership and periodic review.

Downstream secrets make NHI compromise cumulative. The first compromised token is often only the start, because authenticated access reveals other credentials, metadata, and operational dependencies. That is why one integration incident can become several identity incidents in sequence. The field needs to stop treating NHI compromise as a single-asset event and start treating it as an exposure chain that demands coordinated remediation.

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 5.7% of organisations have full visibility into their service accounts, which helps explain why integration compromise so often outpaces detection.
• For lifecycle controls and revocation discipline, see Ultimate Guide to NHIs , Key Challenges and Risks and the 52 NHI Breaches Analysis.

What this signals

Identity blast radius: enterprises should now measure how far a single integration token can move, not just whether the token can be revoked. That shift changes incident response priorities because downstream credential exposure is often the actual recovery burden, and it aligns directly with the NIST Cybersecurity Framework 2.0 focus on recovery and containment.

With 79% of organisations having experienced secrets leaks according to our research on the Ultimate Guide to NHIs, the problem is no longer whether secrets leak but how quickly the exposed path is discovered and collapsed. Security programmes should assume that any trusted integration can become a pivot point and should design monitoring around that assumption.

The governance signal is clear: vendor-integrated workflows need ownership, scope review, and offboarding controls equal to human privileged access. Teams that continue to treat integrations as operational convenience will keep underestimating the blast radius of delegated trust, especially in environments with large SaaS and cloud footprints.

For practitioners

• Inventory every high-scope integration Map service accounts, OAuth apps, bots, and vendor integrations that touch sensitive systems. Include granted scopes, token lifetimes, owners, and revocation authority so you can identify where standing trust exceeds business need.
• Shorten token lifetime and scope Restrict OAuth grants to the smallest workable permission set and replace long-lived refresh paths where possible. Revalidate whether each integration still needs access to production data, cloud metadata, or support-case content.
• Add downstream secret rotation to incident playbooks When an integration token is compromised, assume credential spillover. Revoke the token, rotate any exposed secrets, invalidate prior versions, and verify that dependent systems no longer trust the old identity chain.
• Treat vendor apps as privileged identities Require the same approvals, logging, and periodic access review for third-party integrations that you apply to elevated human accounts. Do not allow business ownership to substitute for identity governance.

Key takeaways

• Compromised integrations are now a primary NHI risk because attackers can inherit trust instead of breaking in.
• Downstream secrets, not just the initial token, determine the real blast radius of an NHI incident.
• Practitioners need inventory, scope control, and fast secret rotation to keep delegated access from becoming standing privilege.

Key terms

• Delegated NHI Trust: Delegated NHI trust is the permission an application, integration, or automated process receives to act on behalf of an organisation. It is legitimate by design, but it becomes risky when scope, lifetime, and downstream reach are not tightly governed. In practice, this is where machine access turns into persistent exposure.
• Identity Blast Radius: Identity blast radius is the amount of damage one compromised identity can cause across connected systems and data. For non-human identities, the blast radius often expands through reused tokens, linked secrets, and automation chains. Good governance aims to shrink that radius before an incident does it for you.
• Downstream Secret Exposure: Downstream secret exposure occurs when a compromised identity reveals additional credentials or sensitive operational data that can be reused to widen access. It is a common escalation pattern in NHI incidents because one authenticated session often has visibility into other machine secrets. Response planning should assume this exposure can happen quickly.

Deepen your knowledge

NHI governance, token scope control, and lifecycle revocation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing SaaS integrations or machine-to-machine access, 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.