Salesforce Access Graph

Expanded Definition

A Salesforce access graph is not a single permission setting; it is the effective access picture created when Salesforce identity controls are combined. Profiles, permission sets, permission set groups, roles, sharing rules, delegated administration, connected apps, and automation can all contribute to what a user or non-human identity can actually reach. For NHI Management Group, the key distinction is between assigned access and effective access, because the latter is what determines whether a record, object, or integration path is exposed.

Definitions vary across vendors and implementation guides, but the operational meaning is consistent: an access graph helps security teams reason about transitive privilege and hidden inheritance. That matters in Salesforce because access can expand through layered grants rather than a single entitlement change. A useful external reference point is the OWASP Non-Human Identity Top 10, which frames how non-human access should be governed when credentials and permissions are distributed across systems.

The most common misapplication is treating profiles as the full control boundary, which occurs when permission sets, role hierarchy, and connected app scopes are not included in review.

Examples and Use Cases

Implementing Salesforce access graph analysis rigorously often introduces operational overhead, requiring organisations to weigh visibility into hidden access paths against the effort of continuous entitlement mapping.

• A security team traces how a service account reaches case data through a permission set, a role assignment, and a connected app scope that was approved separately.
• An administrator reviews why a contractor can see more accounts than expected and discovers access inherited through sharing rules rather than the base profile.
• A governance team validates a third-party integration by comparing its OAuth scope to the effective record-level access it can trigger through automation.
• An incident responder uses the access graph to determine whether a compromised API client can traverse into sensitive Salesforce objects or only a narrow dataset.

These patterns align closely with the risks described in the Ultimate Guide to NHIs, especially where non-human identities accumulate privileges over time. For breach-oriented context, the Salesloft OAuth token breach shows why understanding token-backed access paths matters when applications are the real identity boundary.

Why It Matters in NHI Security

Salesforce access graphs matter because they expose the gap between intended and effective control. In complex tenant environments, that gap often becomes the place where NHIs, partner integrations, and automation inherit excessive privilege without a single obvious misconfiguration. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which makes inherited access paths especially dangerous when Salesforce is tied to customer records, support systems, or revenue operations.

When access is not modelled as a graph, teams miss the way permissions combine across roles, sharing, delegated administration, and connected apps. That can leave sensitive objects exposed long after an integration was deployed, a role changed, or a vendor token was issued. The broader control objective is consistent with Ultimate Guide to NHIs — Key Challenges and Risks and the NIST SP 800-53 Rev 5 Security and Privacy Controls, which both support least-privilege governance and access review discipline.

Organisations typically encounter the real cost only after a token is abused, at which point Salesforce access graph analysis becomes operationally unavoidable to contain the blast radius.

Related resources from NHI Mgmt Group

• How should security teams control privileged access in Salesforce environments?
• Why do Salesforce integrations create privileged access risk?
• When should organisations apply PAM to Salesforce access?
• Who should own elevated access decisions in Salesforce?