TL;DR: The Salesloft and Gainsight breaches show how compromised OAuth and refresh tokens can let attackers enter SaaS environments as trusted non-human identities, then harvest downstream secrets and pivot into cloud systems, according to Hush Security. The pattern confirms that identity governance now has to cover integrations, token scope, and downstream credential exposure, not just human access.
At a glance
What this is: Hush Security analyses the Salesloft and Gainsight breaches as examples of integration trust abuse, where compromised OAuth and refresh tokens became the entry point for broader NHI-driven access.
Why it matters: This matters because identity programmes that stop at human MFA and perimeter controls miss the delegated access paths where SaaS integrations, tokens, and downstream secrets now create the real blast radius.
Context
The governance gap here is straightforward: organisations often trust integrations as if they were bounded extensions of a SaaS platform, when in practice they are identities with delegated privilege. Once an OAuth or refresh token is compromised, the attacker inherits that trust boundary and can act as the integration itself.
In this case, the article centres on non-human identity risk, not a platform flaw. That distinction matters because the control failure sits in token scope, third-party access governance, and downstream secret exposure, all of which are lifecycle problems rather than simple login failures.
Salesloft and Gainsight are presented as a shared pattern of integration abuse, where attackers enter through an NHI and move into adjacent systems. That is a typical failure mode for modern SaaS-heavy estates, not an edge case.
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 SaaS integrations with standing privilege increase breach impact?
A: They expand the blast radius because one compromised token can reach multiple systems, data stores, and business processes. The attacker does not need a password or an interactive session. Once the token is trusted, the integration user can perform normal API actions at scale, which makes exfiltration quieter and faster than many account takeovers.
Q: How do security teams tell whether integration governance is actually working?
A: Look for evidence that every integration is inventoried, scoped, owned, and reviewed on a regular lifecycle. If teams cannot quickly say which tokens exist, what they can touch, and who revokes them, governance is only partial. Effective control shows up as fast revocation, narrow scope, and clear downstream dependency mapping.
Q: When should organisations treat third-party integrations like privileged accounts?
A: Always, when the integration can read data, call APIs, or unlock downstream secrets in production systems. At that point it is not a passive connector but an external privilege holder with a lifecycle, scope, and offboarding requirement. The governance standard should be the same discipline used for other high-risk identities.
Technical breakdown
Why OAuth tokens become trusted identities
OAuth access and refresh tokens are not just session artefacts. In SaaS ecosystems they often represent delegated authority with scopes broad enough to read data, call APIs, and access linked services. When those tokens are tied to integrations, the integration itself becomes the identity being trusted. If scope is broad and revocation is slow, the attacker does not need to defeat MFA or break the application perimeter. The compromise begins with legitimate authorization material and ends with legitimate actions performed in the wrong hands.
Practical implication: treat integration tokens as first-class identities with explicit scope, ownership, and revocation controls.
How downstream secrets expand the blast radius
The article’s key technical point is that compromise did not stop at SaaS access. Once inside, attackers reportedly harvested downstream secrets such as Snowflake tokens, cloud access keys, support-case content, and operational metadata. That creates a chained trust problem: one privileged integration can expose credentials that open unrelated environments. This is why the blast radius of NHI compromise is often larger than the original app footprint. The integration becomes an access relay rather than a point control.
Practical implication: inventory which downstream secrets each integration can reach and remove unnecessary credential exposure paths.
Why third-party integrations behave like supply-chain dependencies
Salesloft and Gainsight illustrate that vendor-connected apps can function as supply-chain components inside an identity architecture. The organisation may trust the SaaS platform, but the real exposure sits in the app-to-app delegation layer: tokens, API scopes, and inherited permissions. When that layer is not governed as part of the attack surface, defenders lose visibility into who can act, what they can access, and how far a token compromise can travel. That is an NHI governance failure, not a perimeter failure.
Practical implication: include third-party integrations in identity reviews, access inventories, and incident response runbooks.
Threat narrative
Attacker objective: The attacker’s objective was to use trusted integration access to reach adjacent secrets and cloud resources that would otherwise be harder to obtain.
- Entry occurred through compromised OAuth and refresh tokens tied to trusted integrations, giving the attacker legitimate access into customer Salesforce environments.
- Credential access expanded when the attacker used that authorised foothold to collect downstream secrets, including tokens and cloud credentials linked to other systems.
- Impact followed as the attacker pivoted into connected cloud and operational environments, broadening exposure beyond the original SaaS application.
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
Compromised integrations are now identity failures, not application anomalies. The Salesloft and Gainsight cases show that OAuth and refresh tokens can function as durable delegated identities with broad authority. Once that delegation is abused, the issue is no longer who logged in, but which non-human identity was trusted to act. Practitioners should treat integration governance as core identity governance, not an adjacent SaaS concern.
Blast radius now depends on downstream credential exposure, not just the first compromised token. The article shows attackers moving from SaaS access into Snowflake tokens, cloud keys, and operational metadata. That pattern turns one trusted NHI into a relay for multiple security domains. The implication is that identity governance has to map what each integration can unlock after initial access, not only what it can read at entry.
Third-party integrations must be governed like external privilege holders. Salesloft and Gainsight both illustrate the same structural weakness: default trust in an app relationship with elevated scopes. The real governance problem is not vendor branding or platform quality, but the assumption that integrated access is inherently bounded. Practitioners should evaluate every external integration as an independently governed identity with lifecycle, scope, and revocation requirements.
OAuth scope hygiene is now a blast-radius control. Broad scopes make token theft more valuable because they convert one credential into many paths of access. Narrower scopes, explicit ownership, and routine offboarding are not cosmetic controls here; they directly determine how far a compromise can spread. Identity teams should measure the authority granted to integrations as carefully as they measure human privileged access.
Integration trust debt is accumulating faster than most IAM programmes can absorb. The article captures a market-wide reality: modern SaaS estates rely on more delegated access than most organisations can inventory or explain. That is why NHIs now sit in the centre of incident response, not at the edge of it. The programme implication is clear: if you cannot account for the identity behaviour of integrations, you cannot account for the security posture of the SaaS estate.
From our research library:
- 68% of organisations do not know how to fully address NHI risks, according to the Ultimate Guide to NHIs.
- 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 now a measurable identity problem: when 97% of NHIs carry excessive privileges, the practical question is no longer whether integrations are risky but whether the organisation can see and constrain their delegated reach. That is why integration inventories and scope reviews belong in the same programme as privileged access governance.
The Salesloft and Gainsight pattern shows that attack paths increasingly begin with legitimate delegated access and end with secrets exposure in adjacent systems. For practitioners, that means incident response has to start with token revocation, downstream secret rotation, and dependency tracing rather than with the SaaS app alone.
For practitioners
- Inventory every premium-scope integration Build a complete register of service accounts, bots, OAuth apps, and connected integrations that can touch critical systems. Include owner, scope, last review date, and the downstream systems each token can reach.
- Tighten token scopes and offboarding Review whether each integration still needs the privileges it currently holds, then remove unused scopes and revoke access when the business relationship changes or the app is no longer required.
- Map downstream secret pathways Identify which integrations can access cloud keys, Snowflake tokens, support data, or other sensitive secrets, then reduce those paths to the minimum required for operation.
- Formalise NHI incident triage If a token is suspected compromised, revoke it, rotate any downstream secrets it may have exposed, and trace every connected identity that could reuse the same delegation chain.
Key takeaways
- The core risk is not a Salesforce weakness but the abuse of trusted non-human identities that hold delegated access into SaaS and cloud estates.
- The article describes compromise through OAuth and refresh tokens, followed by downstream secret theft and pivoting into connected systems.
- Teams limit the blast radius by inventorying integrations, tightening scopes, and revoking or rotating credentials as part of NHI lifecycle governance.
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 SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on third-party integrations compromised through delegated trust. |
| NHI-05 — Overprivileged NHI | The breaches relied on integrations with broad OAuth scopes and excessive authority. | |
| NHI-07 — Long-Lived Secrets | Refresh tokens and downstream secrets extended attacker access beyond the first compromise. | |
| Recommendation — Inventory third-party NHIs and revoke external access paths that cannot be continuously governed. Reduce integration scope to the minimum required and review NHI privilege boundaries regularly. Shorten secret lifetime and rotate tokens immediately when delegation is no longer needed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and secret lifecycle management is central to this breach pattern. |
| Recommendation — Apply authenticator management to revoke, rotate, and track integration credentials across their lifecycle. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack moved from token compromise into downstream credential abuse and pivoting. |
| Recommendation — Map the token theft path to credential access and lateral movement, then hunt for chained access. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- Downstream Secrets: Downstream secrets are credentials or sensitive tokens that become reachable after an initial identity compromise, such as cloud keys, database tokens, or service credentials. They matter because one trusted integration can become a gateway into multiple other systems if those secrets are exposed.
- Privilege Scope: Privilege scope is the set of actions, data, and tools an identity is allowed to use. For AI agents, scope must be defined around the task and the acceptable blast radius, because broad or persistent privileges can turn a small mistake into a production-level incident.
Deepen your knowledge
NHI governance, secrets management, and workload identity security 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.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org