---

name: salesforce-security-basics description: 'Secure a Salesforce integration across OAuth, principals, permissions, sharing, fields, secrets, encryption, logging, and revocation. Use when reviewing threats or hardening controls. Trigger with "secure Salesforce integration".' argument-hint: "[org-alias] [integration]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.8.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags: [saas, salesforce, security, least-privilege, data-protection] model: inherit effort: high compatibility: Designed for Claude Code; security, identity, permission, sharing, and encryption changes require customer security and Salesforce administrator approval

Salesforce Integration Security Baseline

Overview

Build a shared-responsibility control set that connects the external application, Salesforce org, principal, data, event, and operational boundaries.

Prerequisites

• System context, data classes, org topology, app type, principal, APIs, events, and support paths
• Current customer security policy, Salesforce security documentation, and threat model
• Identity, security, Salesforce administration, privacy, data, application, and incident owners

Tool Discipline

Use Read, Glob, and Grep to inspect approved repository and evidence files, WebFetch to re-check current first-party Salesforce documentation, and Write or Edit only for secretless plans, fixtures, configuration, and redacted receipts.

Current Contract

Salesforce access combines OAuth client policy, user or integration-principal permissions, object CRUD, field-level access, record sharing, org settings, and optional security products. Controls and entitlements must be verified in the target org.

Authentication

Prefer an External Client App for new REST integrations where the org contract requires it, or govern an approved existing Connected App. Use workload-appropriate OAuth, minimum scopes, protected secret custody, rotation, revocation, and no human-password automation.

Instructions

1. Map trust boundaries, principals, orgs, APIs, events, data classes, mutations, logs, vendors, and failure paths.
2. Verify app type, OAuth flow, scopes, policies, certificate or secret custody, token lifetime, rotation, and revocation.
3. Review permission sets or groups, profile baseline, CRUD, field access, sharing, elevated access, and separation of duties.
4. Inspect queries, payloads, caches, queues, logs, exports, support bundles, backups, and retention for minimum-data handling.
5. Assess SOQL injection, mass assignment, replay, duplicate mutation, confused-deputy, mixed-org, and secret-exposure threats.
6. Test denied paths, expired and revoked credentials, inaccessible fields, sharing restrictions, redaction, and break-glass audit.
7. Track every gap with severity, owner, deadline, compensating control, verification evidence, and review cadence.

Approval Boundaries

Do not change app policy, scopes, permissions, sharing, encryption, retention, or monitoring without security, admin, privacy, and data-owner approval.

Output

Return the threat model, access matrix, control evidence, denied-path tests, gaps, compensating controls, rotation and revocation proof, and owners.

Error Handling

Condition	Response
Administrator access masks a denied path	Repeat with the actual integration principal before accepting the control.
Security product or event is not entitled	Record the boundary and choose a documented compensating control.
Credential exposure is suspected	Revoke and rotate through the incident process before further testing.

Example

A redacted completion receipt might look like this:

integration=orders; app=external-client-app; scopes=minimum; crud-fls=verified; sharing=verified; denied-tests=pass; gaps=2-owned

Resources

• REST OAuth authorization
• Salesforce Security Implementation Guide

Next Steps

Run the workflow first in the lowest-risk authorized org and preserve its redacted receipt. Schedule a review against the next Salesforce seasonal release and the customer change calendar.