Salesforce connected apps expose NHI governance gaps in access control

At a glance

What this is: This is an analysis of Salesforce connected apps as non-human identity pathways, showing how shared user context and broad permission layering can create access that exceeds business intent.

Why it matters: It matters because IAM and security teams need to govern connected apps, integration users and delegated access as NHI assets, not as a convenience layer hidden inside application ownership.

Context

Salesforce connected apps are external integrations that authenticate through OAuth, SAML or OpenID Connect and then operate inside Salesforce with the permissions of the authorizing identity. The governance problem is not connectivity itself, but the assumption that a single user identity can safely stand in for multiple apps, teams and business purposes.

In practice, Salesforce permissioning combines mandatory profiles with additive permission sets, which can quietly expand effective access when several integrations share one account. That creates a non-human identity governance problem in a human IAM system: ownership is blurred, entitlement scope grows over time, and the blast radius of compromise is defined by the shared identity rather than by any one app.

Key questions

Q: What breaks when Salesforce connected apps share one integration user?

A: The shared account becomes a privilege aggregation point, so each connected app inherits the full permission stack granted to that user. That creates privilege spillover, weakens ownership clarity, and makes compromise of one delegated identity far more damaging than the business intended.

Q: When should teams prioritise dedicated integration users over shared accounts?

A: They should prioritise dedicated integration users whenever multiple connected apps touch different data sets, business functions or export paths. Shared accounts are acceptable only when the access model is truly identical, the business purpose is narrow, and the offboarding process is fully owned and tested.

Q: How do security teams know if a connected app is overprivileged?

A: Look for apps that can reach more objects, environments, or actions than their business function requires, especially if they use admin users or broad OAuth scopes. If the integration cannot be cleanly described in one sentence of purpose and one sentence of reach, it is usually overprivileged.

Q: Who is accountable when a connected app exposes Salesforce data?

A: Accountability sits with the organisation that allowed the connection, because the business owns the risk created by granting access to sensitive systems. Security, IAM, and application owners should share responsibility for approval, monitoring, and revocation. Governance must cover inventory, permission review, and exception handling so third-party access does not become unmanaged.

Technical breakdown

How connected apps inherit user privileges in Salesforce

A Salesforce connected app does not automatically receive its own isolated service identity. When an OAuth flow is granted, the app acts in the context of the user who authorised it, and its effective permissions are the sum of that user’s profile plus any permission sets. That design makes delegation simple, but it also means the app can never exceed the user’s access boundary unless that boundary has already been widened through other grants. In NHI terms, the application becomes an identity proxy, not a separate least-privilege actor.

Practical implication: Treat every connected app as a delegated identity that must be scoped and reviewed like any other non-human account.

Why shared integration users create privilege spillover

A shared integration user centralises authentication, but it also centralises risk. If multiple connected apps reuse the same Salesforce user, each app inherits the full permission stack assigned to that account, including permissions added for other use cases. Over time, the sum of these grants usually exceeds what any single integration genuinely needs. That is why the convenience of one shared account can turn into privilege spillover, where a low-risk integration quietly gains access to reports, records or exports that were only intended for another app.

Practical implication: Separate integrations by identity so that one app’s access needs do not inflate another app’s permissions.

What permission sets can and cannot fix

Permission sets are additive, not corrective. They are useful for granting narrowly defined capabilities, but they do not remove excessive power already present in the base profile. If the underlying profile is too broad, permission sets merely decorate an already over-privileged identity. This is the same structural problem seen in many NHI estates: entitlement granularity does not help when the foundational account is mis-scoped. The control question is therefore not how many layers exist, but whether the baseline identity was created with truly minimal access.

Practical implication: Start from a minimal profile and only add permissions that are specific to one integration’s function.

Threat narrative

Attacker objective: The objective is to abuse delegated Salesforce access to reach more data and functionality than any single connected app should control.

1. Entry occurs when an external tool is authorised through OAuth, SAML or OpenID Connect and begins operating under a Salesforce user context.
2. Escalation occurs when several connected apps share one integration identity and the account accumulates permissions meant for different business functions.
3. Impact occurs when compromise of that shared identity exposes broad Salesforce data, reports or export capabilities well beyond the original integration purpose.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

NHI Mgmt Group analysis

Salesforce connected apps are non-human identities in human clothing: The article shows that OAuth-connected apps act under the authorising user’s privileges, which means the real security object is the delegated identity, not the application branding. That matters because ownership models built only around business applications miss the access and audit consequences of delegation. Practitioners should govern connected apps as NHI assets with explicit scope, ownership and review.

Shared integration users create identity blast radius, not just convenience: When multiple apps reuse one Salesforce user, the account becomes an aggregation point for permissions that were never meant to coexist. That makes compromise or misuse of the account far more consequential than compromise of a single app. The governance lesson is that consolidation without isolation is a structural control failure, not an efficiency gain.

Permission layering does not compensate for a broad base identity: Profiles set the ceiling in practice, and permission sets only add more access on top. If the base profile is over-permissive, the organisation has already lost control before any integration is attached. The implication is that entitlement design must begin with the baseline identity, because additive controls cannot undo an unsafe foundation.

Identity ownership breaks down when Salesforce access is split across IT, security and business operations: The article highlights a familiar governance gap where no single team feels accountable for permission management. That split responsibility is dangerous because delegated access needs a defined owner, an approved business purpose and a review cadence. Practitioners should assign lifecycle accountability before integration sprawl turns into permanent access sprawl.

Least privilege for connected apps is really lifecycle governance for delegated access: The practical issue is not whether an app can connect, but whether its access can be created, bounded, reviewed and removed without dragging other integrations with it. That makes connected app governance closer to NHI lifecycle management than to ordinary application configuration. Teams should treat each integration as a distinct identity with its own offboarding path and audit trail.

What this signals

Delegated access needs identity-level governance: Salesforce connected apps demonstrate why application inventories are not enough. Once an integration acts inside a user context, the security model shifts to who can grant, combine and revoke that delegated access across the lifecycle.

Identity blast radius becomes the practical unit of control: In shared-user environments, one over-broad profile can silently expand the reach of every connected app attached to it. The control question is no longer just whether an app is trusted, but how far one compromised identity can travel across business functions.

Integration ownership must be explicit: When IT, security and business operations all assume someone else owns connected app permissions, access reviews become ceremonial. Teams should force a named owner, a clear business purpose and a removal path for every NHI pathway embedded in Salesforce.

For practitioners

• Define a dedicated identity for each integration Create one Salesforce integration user per connected app so that access, logging and offboarding stay attached to a single business purpose.
• Reset the baseline profile to minimum access Review each integration user’s profile first, then remove any baseline permission that is not required by that one app’s function.
• Audit additive permissions for spillover Compare the permissions on each shared or reused account against the actual tasks of every connected app to identify cross-app privilege leakage.
• Inventory and owner-tag every connected app Maintain a current list of connected apps, business purpose, and accountable owner so that access reviews can be completed without ambiguity.
• Monitor OAuth and API activity for anomalous use Review connected app logs for unusual data access, exports or scope drift that suggests the delegated identity is being used beyond its intended role.

Key takeaways

• Salesforce connected apps can turn ordinary delegation into NHI sprawl when one user context is reused across multiple integrations.
• The core risk is permission aggregation, where profiles and permission sets combine into broader access than any single app needs.
• Teams need per-integration ownership, minimal baseline access and lifecycle offboarding so delegated access does not outlive its purpose.

Key terms

• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• Integration User: An integration user is a dedicated Salesforce identity used by systems rather than people. It should represent one business purpose and one access pattern. When multiple applications share the same user, privilege tends to accumulate and the blast radius of compromise expands quickly.
• Permission Set: A permission set is an additive access package in Salesforce that grants extra privileges without changing the base profile. It is the preferred way to extend access because it keeps the underlying role definition small and makes review and reuse easier across different users and functions.
• Privilege Spillover: Privilege spillover occurs when one identity accumulates permissions intended for multiple tools or workflows, allowing each attached integration to inherit more access than it needs. For NHI governance, it is a common outcome of shared accounts and additive permission models.

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.