Accountability should sit with the business owner of the integration, the identity team that approved the scope, and the platform team that failed to constrain it. Shared responsibility does not mean shared ambiguity. Every high-risk integration needs a clear owner, an expiry or review trigger, and an auditable approval chain.
Why This Matters for Security Teams
An over-privileged Salesforce integration is not just an application misconfiguration. It is a non-human identity failure with business blast radius. When an integration can read, export, or modify more data than it needs, accountability has to follow the approval chain, not a vague shared-services model. NHI Management Group data shows 97% of NHIs carry excessive privileges, which helps explain why over-scoped integrations remain a common exposure path. See the Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP Non-Human Identity Top 10 for the underlying control patterns.
The practical issue is that Salesforce integrations often span business teams, admins, identity engineers, and platform owners, so each group assumes another one constrained the scope. That is how over-privilege survives code review, change approval, and go-live. A good ownership model must name the business sponsor, the technical approver, and the operational custodian, with a review trigger tied to scope change, token rotation, or unusual access growth. In practice, many security teams discover the real owner only after data has already been exported or a connected app has already been abused.
How It Works in Practice
Accountability should be mapped to the control point that could have prevented the exposure. For Salesforce integrations, that usually means the business owner defines why the connection exists, the identity or security team approves the requested scopes, and the platform team enforces the least-privilege configuration and monitoring. The connected app, OAuth grant, API user, and any service account should all be treated as NHI assets with explicit lifecycle ownership. The governance model should also require a clear expiry date or review event, because static approvals age badly in long-lived integrations.
Operationally, the safest pattern is to reduce standing access and make the integration prove what it needs at runtime. That means limiting OAuth scopes, segmenting access by function, using short-lived tokens where possible, and logging every privileged operation to an auditable approval chain. The incident record should show who requested the access, who approved it, what data it could touch, and when that decision must be revisited. This is consistent with the control logic described in the 52 NHI Breaches Analysis and with the OWASP guidance that over-permissioned machine identities are a recurring failure mode.
- Assign one business owner per integration, not a committee.
- Approve scopes explicitly, and reject broad read/write access by default.
- Track the connected app, API user, and token as separate accountable assets.
- Require expiry, renewal, or re-approval for high-risk access.
- Monitor for scope drift, anomalous exports, and privilege growth over time.
These controls tend to break down in heavily customised Salesforce environments where multiple middleware layers, partner connectors, and delegated admins can silently expand access behind a single integration label.
Common Variations and Edge Cases
Tighter integration governance often increases delivery overhead, so organisations have to balance speed against exposure. That tradeoff is especially visible when a revenue-critical Salesforce connector supports multiple business units or external partners. In those cases, current guidance suggests treating the integration as a high-risk NHI rather than as ordinary application plumbing, because ownership is easier to prove than intent after the fact. The Salesloft OAuth token breach is a useful reminder that token abuse often follows scope sprawl, not a failure of the business owner alone.
There is no universal standard for assigning blame in shared-cloud or outsourced admin models, but the accountability principle is consistent: whoever approved scope, whoever failed to constrain it, and whoever owned remediation all have defined obligations. In regulated or high-volume environments, review cadence should shorten when data sensitivity rises, third-party access is added, or the integration begins touching more objects than originally approved. For broader NHI governance context, see the Ultimate Guide to NHIs — Why NHI Security Matters Now.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Over-privileged integrations are a classic non-human identity scoping failure. |
| NIST CSF 2.0 | PR.AC-4 | Access approvals and least privilege directly address who may use the integration. |
| NIST AI RMF | Governance and accountability are central when autonomous or automated access is involved. |
Inventory the Salesforce integration as an NHI and cut any permissions not needed for the documented business task.
