Klue breach shows why SaaS integrations need NHI governance

At a glance

What this is: Akeyless describes how an abandoned Klue integration credential led to OAuth token theft and exposure across many customer Salesforce environments.

Why it matters: It matters because SaaS integrations behave like non-human identities, so IAM and IGA teams need lifecycle control, scope control, and offboarding for delegated access paths as well as for users.

👉 Read Akeyless's analysis of the Klue breach and SaaS integration NHI risk

Context

A SaaS integration is not just a connector. It is a non-human identity with delegated authority, and when that authority outlives its purpose it becomes a security control in name only.

The Klue breach shows what happens when an abandoned test credential remains valid and can still mint OAuth tokens into customer environments. In identity governance terms, the failure is not only exposure but lifecycle neglect across third-party access, token scope, and offboarding.

The case is typical of a broader SaaS supply chain pattern rather than an isolated misstep. Once an integration inherits standing privilege, the downstream customer environment can be reached without touching the customer’s own primary authentication path.

Key questions

Q: What breaks when a SaaS integration credential is left active after a project ends?

A: The credential becomes standing privileged access that no longer has a legitimate business owner. Attackers do not need to break the application itself if they can replay a valid token or secret through a trusted integration path. That is why lifecycle offboarding, expiry, and revocation are as important as initial provisioning.

Q: Why do stolen OAuth tokens create disproportionate risk in cloud-connected business systems?

A: Stolen OAuth tokens are dangerous because they inherit the permissions already granted to the connected app, so the attacker often does not need to authenticate again. That makes the token a reusable access bearer for SaaS APIs, and it can blend into normal traffic. The risk rises when tokens span multiple customer environments or sensitive CRM data.

Q: How do security teams know if integration credentials are operating outside their intended scope?

A: Look for access to systems the credential has never touched before, unusual authentication times, protocol mismatches, and data requests that do not match the integration's normal business function. Those are strong indicators that a token or service account has been reused or repurposed. Baseline both network paths and application behaviour.

Q: What should organisations do when a SaaS vendor is part of their CRM access chain?

A: Assign the integration an owner, an expiry, and a documented offboarding path, then review its scopes and revoke anything that no longer matches the use case. Treat the vendor connection as a governed identity, not as a one-time technical setup.

Technical breakdown

Abandoned integration credentials become standing non-human identities

The entry point was a test credential created for a prototype integration and then left active after the project was abandoned. In practical terms, that credential remained an authenticating object even though the business reason for it had ended. This is the core NHI lifecycle problem: credentials do not self-retire when a pilot, vendor relationship, or proof of concept ends. The risk is not only that the secret exists, but that it still maps to a live delegated authority chain long after anyone remembers why it was created.

Practical implication: treat abandoned integration credentials as offboarding events, not housekeeping tasks.

OAuth tokens turn trusted integrations into reusable access paths

Once the attackers had the compromised integration path, they were able to obtain OAuth tokens and use them against customer Salesforce environments. OAuth is designed to delegate access, so a valid token can act exactly like the integration itself until it expires or is revoked. The security issue is scope and lifetime. If the token is broad, persistent, and replayable, it becomes a portable authorization artifact rather than a temporary delegation. That is why token theft in SaaS supply chains scales so well.

Practical implication: reduce token lifetime and scope so delegated access cannot be replayed at enterprise scale.

Bulk API abuse is what downstream compromise looks like

The reported impact was automated bulk querying for roughly 24 hours, with contacts, sales communications, pricing data, and opportunity records extracted from customer CRM environments. This is not a frontend compromise or a password spray. It is downstream API abuse through valid delegated identity. Salesforce did not need to be broken for the data to leave. The attacker used an authenticated path that customers already trusted, which means logging, anomaly detection, and integration governance become the real control plane.

Practical implication: monitor integration-driven API volume and revoke abnormal delegated access before large exports complete.

Threat narrative

Attacker objective: The objective was to use trusted SaaS integration access to harvest customer CRM data at scale without defeating primary user authentication.

1. Entry occurred through a legacy test credential for an abandoned integration that was still valid when attackers found it.
2. Credential abuse followed when the attackers used the compromised integration path to obtain OAuth tokens for connected customer environments.
3. Impact came through automated bulk API queries against Salesforce environments, with contacts, communications, pricing data, and opportunity records exfiltrated.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Abandoned integration credentials are lifecycle failures, not configuration oversights. This breach worked because a credential created for a prototype outlived the project that justified it. That means the governance gap is offboarding, not merely secret storage. When integration credentials are not tied to a decommissioning process, they become latent standing privilege that attackers can discover later. Practitioners should treat every dormant integration secret as evidence of unresolved ownership.

OAuth delegation is a non-human identity control surface, not just an application feature. Once a third-party integration can mint tokens into customer systems, it is exercising identity authority on behalf of the enterprise. The implied trust boundary is therefore the token itself, not the vendor brand or the SaaS platform. In NHI terms, delegated access needs the same inventory, scoping, review, and revocation discipline as any other machine identity. The implication is that integration governance belongs in identity operations, not only in application security.

Standing privilege in SaaS supply chains creates asymmetric blast radius. One compromised vendor integration can inherit access to dozens of downstream environments at once, which makes blast radius control more important than perimeter trust. That is why short-lived, tightly scoped delegation changes the risk model more than another layer of approval around the original integration request. Security teams need to recognise that the smallest unit of control is the delegated credential, not the upstream vendor relationship.

Secretless and ephemeral access models are now a governance requirement for third-party connections. The article’s lesson is not that integrations should be rare, but that persistent credentials should be. When a connection must exist, its authority should decay with the use case. That shifts the programme from perpetual trust to controlled issuance and revocation. For identity leaders, the practical conclusion is to govern SaaS integrations as living NHIs with expiry, scope, and ownership, not as static connectors.

Vendor risk and identity risk are now the same conversation in SaaS ecosystems. A trusted provider can become the path into customer data when its own integration credentials are weakly governed. That collapses the old separation between third-party risk management and identity governance. The right operating model is joint ownership across procurement, IAM, and SaaS admins, because the failure mode is shared accountability around delegated access.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius is now a SaaS governance metric. When a single integration can reach multiple customer environments, the real question is not whether the vendor is trusted, but how far its delegated access can travel before it is stopped. That changes security reviews from vendor assurance to permission containment.

Third-party SaaS connections should be treated as NHIs with offboarding dates. The article’s core failure was not just a stolen secret, but a secret that should never have remained alive. Teams that do not track expiry, ownership, and revocation for integrations will keep inheriting the same exposure pattern from one vendor to the next.

For practitioners

• Inventory every third-party SaaS integration Map OAuth grants, API keys, service accounts, certificates, and other delegated credentials tied to Salesforce, CRM, and adjacent business platforms. Flag any integration without a named owner, purpose, or expiry.
• Revoke dormant and ownerless credentials Remove test credentials, deprecated integrations, and abandoned pilot secrets before they become replayable access paths. Tie decommissioning to project closeout and vendor offboarding rather than periodic cleanup.
• Constrain token scope and lifetime Reduce OAuth scopes to the smallest workable set and enforce short-lived tokens where the platform allows it. Long-lived tokens should be treated as standing privilege, not convenience.
• Add integration-specific detection Monitor bulk exports, abnormal API query volume, and automation patterns that do not match normal integration behaviour. Alert on delegated access that suddenly touches many records or many tenants.
• Require vendor lifecycle accountability Ask providers how they scope, rotate, expire, revoke, and audit customer tokens, especially for abandoned projects and third-party connections. Make token decommissioning part of the contract and the operating model.

Key takeaways

• The breach demonstrates that SaaS integrations become security liabilities when their credentials outlive the project or vendor relationship that created them.
• The impact was not theoretical, with more than two dozen companies affected through customer Salesforce environments reached by delegated access.
• The limiting control is lifecycle governance for integrations, including ownership, expiry, scope reduction, and decommissioning of dormant credentials.

Key terms

• SaaS Integration NHI: A SaaS integration NHI is a non-human identity created when one platform delegates access to another through a token, key, certificate, or service account. It must be inventoried, scoped, rotated, and retired like any other identity because it can authenticate and act independently of a person.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• OAuth Token Delegation: OAuth token delegation is the process of granting an application or integration limited access to another system without sharing primary user credentials. In practice, the token becomes the authority artifact, so its scope, lifetime, and revocation controls determine how far a compromise can spread.
• Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step Klue attack chain from abandoned credential to OAuth token theft and downstream Salesforce access
• The full list of named affected companies and the reported scope of the compromise
• The vendor-side control model proposed for dynamic secrets, zero standing privilege, and secretless authentication
• The specific checklist items for auditing SaaS integrations, token scope, and decommissioning workflows

👉 Akeyless's full article covers the attack chain, affected environments, and control changes for SaaS integrations.

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.