Klue OAuth abuse shows how stale integrations expand SaaS blast radius

At a glance

What this is: A compromised third-party Salesforce integration became an exfiltration path, and the key finding is that stale OAuth access with broad privileges can move data at large scale before teams notice.

Why it matters: For IAM, IGA, PAM, and SaaS security teams, this matters because integration governance now sits inside identity governance, not beside it, and unmanaged OAuth access can expose crown-jewel SaaS data.

By the numbers:

• One impacted organization experienced the highest-record-count theft across the incident, with approximately 13.9 million records exfiltrated.
• Across the impacted organizations, activity was spread over more than 24 hours and varied by source IP, timing, and scope.

👉 Read Obsidian Security's analysis of the Klue OAuth breach and Salesforce exfiltration

Context

OAuth-connected integrations are a governance problem as much as a security problem because they inherit standing access to SaaS data without the same review cadence applied to human users. In this case, the primary issue was not a novel exploit chain so much as stale third-party access with enough privilege to change code and extract records from Salesforce.

The primary security question for identity teams is how to govern third-party applications whose access outlives the business need that created it. Klue’s compromised integration is an example of why NHI lifecycle controls, scope review, and behavioural baselines must cover SaaS-to-SaaS connections as part of identity governance, not only internal service accounts. This is an increasingly typical pattern, not an edge case.

For teams mapping this to identity standards, the relevant control family is vendor and integration identity lifecycle management, especially where OAuth grants act like long-lived machine identities. The operational gap is visibility into which apps have access, what scopes they hold, and whether their runtime behaviour still matches the approved baseline.

Key questions

Q: What breaks when a third-party OAuth integration has stale access?

A: Stale OAuth access turns a trusted connector into a standing exfiltration path. If scopes are broader than the current business need, an attacker who compromises the token can read, write, or export data without further user interaction. The failure is not just technical exposure, but the lack of a lifecycle event that forces revocation before the grant becomes reusable attack infrastructure.

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 can security teams tell when a trusted integration is being abused?

A: Look for drift from the approved behavioural baseline. Unexpected source infrastructure, new user agents, API version changes, schema discovery, and unusually large QueryMore pagination bursts are all strong signals that a trusted integration is no longer acting normally. Those signals should be monitored as identity events, not just application logs.

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

A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.

Technical breakdown

How compromised OAuth grants become an exfiltration channel

OAuth gives an application delegated access without repeated user re-authentication, which is why integrations are useful and also why they are dangerous when not tightly governed. If the token is long-lived, over-scoped, or exposed, an attacker can reuse that delegated trust exactly as the application would. In SaaS environments, that means access to APIs, objects, and records can persist even after the original trust decision is no longer valid. The problem is not OAuth itself, but the combination of delegation, privilege, and weak lifecycle controls.

Practical implication: inventory every OAuth app, review scopes against actual business need, and revoke stale grants before they become reusable access paths.

Why runtime baselines matter for third-party integrations

Trusted integrations usually have a narrow behavioural fingerprint: stable source infrastructure, consistent user agents, and predictable API versioning. When an attacker hijacks that identity, the behaviour often changes before the data loss becomes obvious. In this incident, the deviations in source IP, user agent, API version, and query patterns were the clearest indicators that the integration was no longer acting normally. Behavioural telemetry is therefore part of identity governance for NHI, because delegated access can be abused while still appearing authenticated.

Practical implication: build detection around source, client, and API baselines for every high-value integration, then alert on drift rather than waiting for impossible manual review.

Why schema discovery is a signal of privilege, not just curiosity

Querying a full schema or metadata object such as Salesforce Global Describe is a classic reconnaissance move because it reveals what data is reachable, how objects relate, and where high-value records live. Legitimate integrations rarely need to enumerate the full shape of a CRM tenant at this depth. Once the attacker has that map, targeted SOQL queries and pagination can turn broad access into efficient bulk export. That makes schema discovery a privilege test as much as a threat indicator: the more a token can see, the more it can later exfiltrate.

Practical implication: restrict schema-level permissions for non-developer integrations and treat broad metadata queries as a high-fidelity alert.

Threat narrative

Attacker objective: The attacker sought to turn trusted third-party access into large-scale Salesforce data exfiltration across multiple victim organisations.

1. Entry occurred through a compromised legacy credential tied to a third-party integration, giving the attacker authenticated access into the SaaS environment.
2. Escalation followed when the attacker inserted backdoor code and used the compromised integration to steal customer OAuth tokens with highly privileged access.
3. Impact came through reconnaissance and bulk export of Salesforce objects, including millions of CRM records, using automated QueryMore pagination and repeated API queries.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stale OAuth grants are now a primary NHI risk surface, not a secondary SaaS hygiene issue. This incident shows that delegated access can survive long after the business relationship or operational need has changed. When the token still has code-changing or data-export privileges, the integration becomes a standing path into crown-jewel SaaS systems. Practitioners should treat OAuth lifecycle governance as part of NHI control, not app administration.

Third-party integration trust needs behavioural validation, not just authorization records. The most valuable detections in this case were not based on identity alone, but on deviations in infrastructure, user agent, API version, and query patterns. That is the practical difference between knowing an app is authorized and knowing it is behaving as authorized. Identity programmes that stop at consent and scope review leave a blind spot at runtime.

Credential exposure plus overprivilege creates an identity blast radius that grows faster than manual response can contain. Once the attacker had a compromised legacy credential and a high-scope integration, exfiltration could scale across multiple customers with little friction. The named concept here is identity blast radius: the amount of SaaS data and downstream trust that can be reached through one compromised integration. Security teams should use that concept to prioritise which third-party identities need the tightest governance.

The governance failure was not just compromised access, but access that outlived accountability. The article points to a stale integration token with highly privileged access, including the ability to change code. That is a classic lifecycle breakdown where the access grant persisted beyond the point at which human owners were still watching it. The implication is that identity reviews for machine access must be continuous, not event-driven.

OAuth-based SaaS supply chain attacks are becoming a repeatable identity pattern. Attackers are increasingly targeting the identities and integrations that connect vendors to customer data rather than forcing direct compromise of every tenant. That shifts the security problem from endpoint-centric containment to trust-relationship governance across the SaaS estate. Practitioners should assume integration abuse is a durable threat model, not an isolated incident.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Another finding from the same research shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and breach-investigation blind spot.
• That same blind spot is why 52 NHI Breaches Analysis remains relevant when teams assess integration abuse, lifecycle gaps, and downstream blast radius.

What this signals

Identity blast radius: the practical goal is no longer only to stop compromise, but to reduce how far a compromised integration can move before detection. In SaaS-heavy environments, that means treating OAuth apps as governed identities with owners, scopes, baselines, and revocation paths, not as invisible plumbing.

The programme signal is clear: integration telemetry has to sit alongside access reviews and secret hygiene. If you cannot answer which apps can reach Salesforce, which users authorised them, and what normal behaviour looks like, you do not have control of the identity layer that now protects the data layer.

For teams formalising this work, the control model should align with the NIST AI Risk Management Framework only where autonomous behaviour is present, but the immediate need here is stronger governance of delegated SaaS access. That same governance mindset is what makes the 52 NHI breaches Report useful for prioritising the identities most likely to create cross-environment spread.

For practitioners

• Inventory every high-value OAuth integration Build a current register of which apps can reach Salesforce and other crown-jewel SaaS platforms, who authorized them, what scopes they hold, and when they were last validated. Prioritise integrations that can read, write, or change code in business-critical systems.
• Reduce delegated privilege to the minimum operational scope Review whether each integration truly needs metadata discovery, bulk export, admin-like write access, or code-change capability. Remove permissions that are convenient but not operationally necessary, and separate read-only connectors from privileged automation.
• Detect behavioural drift in trusted integrations Baseline source IP ranges, user agents, API versions, query volume, and query type for every approved integration. Alert on deviations such as new infrastructure, unexpected schema queries, or sudden QueryMore pagination bursts.
• Rotate and revoke stale integration credentials aggressively Treat old OAuth grants and legacy credentials as live attack paths until proven otherwise. Revoke tokens tied to abandoned vendors, dormant workflows, or integrations that no longer match the business process they were created for.
• Map blast radius before an incident forces the question Identify which tenants, objects, and downstream workflows each integration can touch so you can rank exposure by business impact. That mapping should sit alongside service account governance in the wider NHI programme.

Key takeaways

• A compromised third-party integration can turn delegated OAuth access into a fast, high-volume exfiltration path.
• The clearest warning signs were lifecycle failure, overprivilege, and runtime behaviour that diverged from the approved baseline.
• Teams need continuous integration governance, not just periodic review, if they want to keep SaaS blast radius under control.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Configuration Baseline: The approved reference state for a system, policy, or controlled asset. A baseline defines what the environment should look like after a legitimate change. Security teams use it to compare current state against intended state and to spot drift, tampering, or incomplete implementation.
• 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.

What's in the full report

Obsidian Security's full post covers the operational detail this post intentionally leaves for the source:

• The incident timeline and the specific customer-by-customer deviations in source IP, user agent, and API version.
• The Salesforce query patterns, including Global Describe, SOQL extraction, and QueryMore pagination details.
• Obsidian's detection examples and how the telemetry mapped to the compromised integration behaviour.
• The remediation priorities for vendors and customers, including token rotation, scope reduction, and revocation workflows.

👉 Obsidian Security's full post covers the incident timeline, detection signals, and remediation priorities in more operational detail.

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 identity security capability across human and non-human systems, it is worth exploring.