Look for evidence that the current token, the connected org, and the request destination still match the approved relationship. If the app cannot show who connected the org, why it is connected, and whether revocation is handled cleanly, the access boundary is already weak.
What “within the intended access boundary” means for a Salesforce integration
A Salesforce integration stays inside its intended boundary only when the credential, the connected org, and the target system still match the relationship that was approved at setup. That means the access path is not just technically working, but still tied to the right business purpose, the right tenant, and the right destination scope.
For practitioners, the boundary is usually defined by more than a token alone. It also depends on who connected the org, which integration account or app was authorised, what objects or APIs the app can reach, and whether the current call path still resembles the originally sanctioned use case.
One practical way to think about it is to treat the integration as a relationship that must keep proving itself. If the app can no longer explain its own origin, scope, or revocation path, the access boundary is no longer being actively governed even if the token still works.
Signals that the boundary is still intact
Teams should be able to answer three questions from logs, configuration, or admin records: what token is in use, which org or connected app granted it, and why that connection exists. When those three elements line up consistently, the integration is much more likely to be operating within its intended boundary.
Good evidence usually includes a named integration owner, a documented business justification, a scoped permission set or connected app policy, and a revocation process that actually removes the live access path. If any of those are missing, the boundary may still exist in theory, but it is not verifiable in practice.
This is where destination checking matters. The request should go only where the approved integration is meant to go, not to a broader set of Salesforce data, a new org, or an unexpected third-party endpoint. A clean boundary is visible when the auth context, the org context, and the request destination all agree.
What breaks the boundary in real integrations
Boundary drift often starts quietly. A token is reused after the original business need changed, a connected org survives after ownership moved, or a new downstream service is added without re-approving the access scope. Over time, the integration becomes harder to explain and easier to misuse.
Salesforce integrations are also vulnerable to third-party drift, where the original connected app is still trusted but the vendor, workflow, or routing path has changed. A token that was safe in one context can become overbroad when the integration is repurposed, cloned, or connected to a different data flow.
For a concrete example of how token-based Salesforce access can escape its intended boundary, see NHIMG’s Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, both of which show how an apparently ordinary integration can become a data-access path beyond the original intent.
Practical checks teams should run
Start by verifying the token lineage: who authorised the connection, when it was issued, whether it is still needed, and whether rotation or revocation actually invalidates the live session. Then compare the connected org and app metadata against the approved integration record, because stale ownership details are a common sign that the control boundary has drifted.
Next, inspect the request destination and scope. A healthy integration should not suddenly reach new objects, new APIs, new sandboxes, or new tenant relationships without a documented change. If the call pattern has widened but the approval record has not, the boundary has already weakened.
Finally, test the offboarding path. A revocation control that looks correct on paper but leaves active access behind is not a boundary control at all. The cleanest sign of control is that the team can prove exactly what is disconnected, by whom, and how quickly access disappears after deapproval.
Risk and Threat Considerations
When a Salesforce integration cannot show clear token ownership, org provenance, or revocation behaviour, the main risk is silent scope creep. That creates a durable access path that may still look legitimate to normal operations while exposing more CRM data or downstream systems than intended.
Failure mechanism: Attackers, vendors, or internal users can abuse stale tokens, overbroad scopes, or repurposed integrations to keep accessing Salesforce after the original trust decision has changed. If the integration also lacks clean revocation, compromise becomes harder to contain.
Impact: The organisation can lose the ability to prove where access began and where it should end, which raises the blast radius of credential theft, supply-chain abuse, and accidental overexposure of CRM records.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers token lifecycle and revocation for the integration credential. |
| AC-6 — Least Privilege | Applies to limiting Salesforce access to the approved boundary. | |
| AU-2 — Event Logging | Supports verifying who connected the org and what the integration did. | |
| Recommendation — Rotate and revoke integration tokens on a defined lifecycle. Restrict the integration to the minimum required Salesforce permissions. Log connection, token use, and destination changes for the integration. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly fits controlling and reviewing the integration's access boundary. |
| Recommendation — Define and review the integration’s access scope against the approved need. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports managing and removing access when the relationship changes. |
| Recommendation — Review and remove integration access that no longer matches the approved use case. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Relevant because stale Salesforce integrations can keep access after approval ends. |
| Recommendation — Ensure deprovisioning fully removes the integration’s active access path. | ||
Practitioner Guidance
What to verify: Before trusting the integration, verify that the current token, connected org, and target endpoints still match the approved use case. If any one of those no longer aligns, treat the integration as out of boundary even if it continues to authenticate.
What good looks like: The integration has a named owner, a current business justification, a bounded permission set, and a revocation test that actually kills access. You should be able to explain the relationship in one sentence without relying on institutional memory.
Decision rule: If the team cannot demonstrate who connected the org and how to revoke it cleanly, prioritise containment and re-approval over continued operation. In practice, an unprovable boundary is a control failure, not a documentation gap.
Practitioner takeaway: The key test is not whether the integration still works, but whether it still behaves like the same approved relationship that was originally authorised.
Related resources from NHI Mgmt Group
- How can teams tell whether a coding agent is operating outside its intended boundary?
- How can security teams tell whether MDM credentials are operating outside their intended boundary?
- How can teams tell whether protobuf decoding is operating outside its intended boundary?
- How can organisations tell whether an AI agent is operating outside its intended boundary?