Gainsight Salesforce token abuse shows the risk of integration connectors

At a glance

What this is: This is a Permiso Security analysis of a Salesforce and Gainsight access incident that points to third-party connector token abuse as the likely risk pattern.

Why it matters: It matters because integration connectors are non-human identities with broad downstream reach, so one compromised token can create enterprise-scale exposure across IAM, NHI, and lifecycle governance.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read Permiso Security's analysis of the Gainsight Salesforce connector incident

Context

Gainsight Salesforce connector abuse is a non-human identity problem because the trust boundary sits in an org-level integration, not in a human login flow. When that connector is compromised or disabled, the downstream blast radius can extend across the connected Salesforce environment before defenders even know which identity was acting.

Permiso Security's analysis is useful because it shows how third-party connectors can behave like concentrated machine identities: predictable, persistent, and hard to inventory well. The immediate governance question is not only how the token was stolen, but how much authority the connector held, how it was monitored, and whether its lifecycle was ever treated as a first-class identity asset.

Key questions

Q: What breaks when an org-level integration connector is compromised?

A: A single compromised connector can expose many Salesforce objects and records because the identity is trusted at the organisation level, not per user. That means the blast radius is set by the connector's permissions, not by the individual who last touched it. Teams should inventory connector authority before an incident makes that scope visible.

Q: Why do third-party connectors increase NHI risk in Salesforce environments?

A: They concentrate access into a small number of persistent credentials that can outlive the immediate business need. If one integration token is stolen, attackers can reuse the authorised path exactly as the application would. That makes ownership, monitoring, and revocation central to governance, not optional administrative work.

Q: How can security teams know if connector activity is outside normal bounds?

A: They should compare source infrastructure, API event mix, query breadth, and bulk job behaviour against a known-good baseline. If legitimate traffic normally comes from AWS and uses a narrow set of query events, anything from non-AWS sources or with unusual bulk extraction patterns deserves immediate investigation.

Q: Who is accountable when a third-party integration credential is abused?

A: Accountability sits with both the system owner who approved the connector and the organisation that retained the access after the business need changed. If the credential was never reviewed, revoked, or re-scoped, the governance failure is lifecycle related, not just technical. That is why connector offboarding needs named ownership and audit evidence.

Technical breakdown

Org-level OAuth connectors create concentrated access paths

In this pattern, a single connector identity is authorised at the organisation level instead of being issued per user. That changes the risk profile materially: compromise of one token can expose many objects, records, and API paths, while revocation can sever a critical business integration instantly. The difference is not just scale, but control shape. Org-level connectors are harder to reason about because they look like one account, yet behave like a shared service account with broad reach across the tenant.

Practical implication: inventory every org-level connector as a privileged NHI and map its exact permissions before an incident forces the issue.

Behavioural baselining is the fastest way to spot connector abuse

Connector traffic is often highly regular. In the article's analysis, legitimate activity came from AWS infrastructure, used predictable query patterns, and generated repeatable API event types. That makes anomalies easier to spot than with human users, but only if defenders know what normal looks like. The important point is that detection depends on identity behaviour, source infrastructure, and event mix together, not on a single IOC or user-agent string.

Practical implication: build connector baselines for source IPs, API verbs, job creation patterns, and user agents before you need to hunt suspicious access.

Bulk API extraction turns connector access into rapid data loss

Bulk API 2.0 is where a compromised integration can move from reconnaissance to mass extraction quickly. Once attackers identify a connector with broad query authority, they can pull large volumes of records, target high-value objects such as case data, and remove evidence by deleting jobs before natural timeout. The failure mode is not just token theft. It is over-scoped machine access combined with API pathways designed for efficient data movement.

Practical implication: restrict bulk API permissions to the narrowest possible connector role and alert on new job creation, early deletion, and unusual query breadth.

Threat narrative

Attacker objective: The objective is to turn one compromised integration credential into repeatable access to many Salesforce environments and extract high-value business data at scale.

1. Entry occurred through compromise of a third-party integration provider, where OAuth credentials associated with the connector were obtained and then used against downstream Salesforce instances.
2. Escalation followed when the stolen connector identity was able to exercise the permissions already attached to the org-level integration, allowing broad API activity and data discovery.
3. Impact came from large-scale record access and extraction across connected Salesforce tenants, with attackers also attempting to reduce detection by deleting jobs and blending into normal integration traffic.

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

Org-level connector authority is a concentrated NHI governance risk, not a convenience feature. When one integration identity is trusted across an entire Salesforce organisation, its compromise becomes a single point of enterprise-wide exposure. That is why connector inventory, scoped authority, and lifecycle control must be treated as identity governance, not as an admin afterthought. Practitioners should treat org-level connectors as privileged non-human identities with explicit owners and revocation paths.

Standing connector access creates identity blast radius. The control gap is not simply that a token existed, but that one connector credential could reach multiple objects, run bulk queries, and operate with broad persistence until someone noticed unusual behaviour. That is the same failure mode seen in many NHI incidents: authority outlives the immediate business need, so compromise turns into scale. The implication is that teams must understand blast radius before they certify the connector, not after.

Predictable machine behaviour is both a detection advantage and a governance warning. The article shows that normal connector activity is highly regular, which means deviations can be detected faster than with human users. But that predictability also reveals how much trust the programme places in a small number of repetitive actions. Governance should assume that if the connector can query broadly and consistently, an attacker can do the same with minimal noise. Practitioners should align monitoring to behaviour, not just authentication events.

Third-party integration trust is a lifecycle problem as much as an access problem. The relevant question is whether the connector was owned, reviewed, and offboarded with the same discipline as any other privileged identity. If the business relationship changes but the connector remains active, accountability lags behind access. Practitioners should make connector lifecycle, ownership change, and revocation triggers part of standard NHI governance.

Gainsight-style incidents validate a broader assumption: downstream access is only as safe as the least visible upstream identity. Security teams often focus on the customer tenant and miss the integration provider that actually holds the usable credential. That shifts the governance boundary outward, where inventory is weaker and review cadence is slower. The practical conclusion is to extend identity governance to every third-party connector that can act inside core business systems.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The 2024 ESG Report on non-human identities found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
• That speed of exploitation is why The 52 NHI breaches Report is a useful companion resource for understanding repeatable credential-abuse patterns.

What this signals

Connector blast radius: A single org-level integration can behave like a privileged machine identity, which means the programme's real control point is not the app itself but the connector's authority scope and revocation discipline. If you do not know exactly which records a connector can touch, your review cycle is already behind the threat.

With 72% of organisations already experiencing or suspecting an NHI breach, the Gainsight pattern should be read as a lifecycle warning: third-party connectors need ownership, recertification, and offboarding like any other privileged identity. Teams that wait for a confirmed incident before inventorying connectors are treating a governance problem as an investigation problem.

For readers building out monitoring, the next step is to align connector telemetry with the discipline used in the 52 NHI Breaches Report. The lesson is not merely detection fidelity, but identity visibility across the entire trust chain from vendor token to downstream business system.

For practitioners

• Inventory every Salesforce connector identity Identify which service accounts, tokens, and OAuth grants connect Gainsight or similar tools to Salesforce, then document owner, purpose, permissions, and revocation path. Use the inventory to confirm whether any connector is operating with broader access than its business function requires.
• Baseline connector behaviour before an incident Record normal source IP ranges, API verbs, object queries, job creation patterns, and user-agent strings for each integration. For this pattern, treat AWS-originated traffic as the expected baseline and investigate any non-AWS source immediately.
• Constrain bulk extraction pathways Review which connectors can use Bulk API 2.0, then narrow that permission set to only the identities that genuinely need high-volume access. Alert on new bulk jobs, early deletions, and unusually broad query patterns against case or customer records.
• Tie connector revocation to lifecycle events Define trigger points for disabling third-party access when a vendor relationship changes, when unusual activity is detected, or when the connector owner changes. Connector access should not outlive the business justification that created it.

Key takeaways

• Org-level Salesforce connectors create a concentrated non-human identity risk because one credential can unlock broad downstream access.
• The evidence pattern points to stolen OAuth credentials, bulk API abuse, and rapid removal of jobs to reduce detection and maximize extraction.
• The control that matters most is lifecycle governance for third-party connectors, including inventory, ownership, baseline monitoring, and fast revocation.

Key terms

• Org-level Connector Identity: A single machine identity used by an integration to act across an entire tenant or organisation. Unlike a per-user token, it can carry broad permissions and persist as long as the integration remains enabled, which makes ownership, scoping, and revocation central governance tasks.
• Connector Blast Radius: The amount of data, systems, or workflows exposed if an integration credential is misused. In NHI governance, blast radius is determined by the connector's permission scope, the business systems it can reach, and how quickly defenders can revoke or constrain it after anomalous activity appears.
• Behavioural Baseline: A normal pattern of machine identity activity established from source IPs, API calls, timing, and event types. For non-human identities, baseline behaviour is often more stable than human activity, which makes deviations useful for detection but only if the baseline is defined before an incident occurs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 Permiso Security: Gainsight Breach Investigation: Another SalesLoft-Style Attack Unfolds. Read the original.