The moment someone proposes connecting Claude or ChatGPT to your Salesforce org, a specific person in your company gets a knot in their stomach. Sometimes it's the security lead, sometimes the compliance officer, sometimes the admin who knows exactly how much sensitive data lives in that org. This post is for that person — and for the people trying to get a yes from them.
The anxiety is rational
Your CRM is not a low-stakes system. It holds customer PII, pipeline and pricing data, support histories, and — in healthcare orgs — protected health information. The industry has also produced enough stories of overshared AI connectors and over-permissioned integrations that skepticism is earned, not paranoid. "An LLM can now read our org" is a sentence that deserves scrutiny.
But the scrutiny should land on the right question. The question is not "is AI touching our CRM safe?" — it's "what can this specific connection see and do, under whose identity, and how do we watch it?" Those are questions Salesforce administrators have been answering about integrations for two decades. MCP does not change the questions. It changes how fast someone can ask them.
Salesforce security remains a control—but verify the connector path
Many Salesforce MCP implementations use OAuth and Salesforce APIs, so profiles, permission sets, sharing, and field-level security can remain central controls. That is not an automatic property of the protocol. A server may use per-user or shared credentials, invoke custom Apex, call another service, or expose a tool whose implementation changes the effective execution context. Trace and test the complete path.
Concretely, inspect these existing controls and how each tool uses them:
- Object and field-level security (CRUD/FLS). Confirm that every query, record operation, custom action, and metadata path enforces the intended object and field boundary.
- Sharing rules and role hierarchy. Test record-level visibility with representative users, including records they must be denied, rather than inferring it from the OAuth flow alone.
- Permission sets and muting. Use them to define the Salesforce user boundary, then review whether custom code or a shared integration identity expands it.
- Connected app policies. OAuth scopes, admin pre-authorization, IP relaxation settings, and session policies all govern the connection.
A full system administrator or broadly privileged integration identity creates a large blast radius. User scoping is therefore necessary, but it is only one part of the review: tool allowlists, model-context data, approvals, connector retention, logs, and downstream services matter too.
What to configure before connecting anything
Choose the identity model deliberately
There are two sane patterns, and they serve different purposes. User-context connections — each person authorizes the MCP client as themselves — preserve per-user sharing, keep audit attribution clean (actions log as the human who asked), and are the right default for assistant use. A dedicated integration user — one purpose-built account with least-privilege access — gives you predictable, centrally managed scope and a single kill switch, and is the right pattern for automated or shared workloads. The wrong pattern is the lazy hybrid: everyone piggybacking on one admin's credentials. That destroys attribution and inflates blast radius simultaneously.
Design the permission set before the demo
Build a dedicated permission set (or permission set group) named for what it is — something like AI_Assistant_Access — and grant into it deliberately. Start read-only on the objects the use case actually needs. Add write access per object, per reason, with a record of why. Never grant Modify All Data to anything with "AI" in the name. And use FLS to strip fields the assistant has no business reading: government IDs, compensation, bank details, health fields. Field-level security is quiet, boring, and the single most effective control on this list.
Restrict the network path and rehearse in sandbox
Apply IP restrictions and login policies to the integration user the way you would for any middleware account. Configure the connected app so OAuth scopes are minimal and admin-approved. Then do the rollout in a sandbox first — a full or partial copy with realistic data — and run the actual intended workload for a week or two. Read the debug logs. Watch what the assistant queries. You will learn more about your real exposure from ten days of sandbox usage than from any architecture review, and you'll promote to production with evidence instead of vibes.
PHI and HIPAA: what healthcare teams should think about
If your org touches protected health information, everything above still applies — plus a layer that is less about Salesforce configuration and more about program design. To be clear up front: this section is informational, not legal advice. Bring your compliance and privacy teams in before any AI connection touches a production healthcare org. It's the same posture we take across our HIPAA-conscious healthcare Salesforce work.
Minimum necessary is a design input, not a policy document. HIPAA's minimum-necessary principle maps directly onto FLS and object permissions: the AI-facing user should see the smallest data surface that makes the use case work. In practice that often means operational fields — statuses, dates, queue assignments, record IDs — while clinical narrative and diagnosis fields stay out of scope entirely.
Audit trails need to answer who, what, when. Event Monitoring and API logs should let you reconstruct which identity accessed which records through the connection. User-context connections make this dramatically easier, because access attribution stays with the human who asked.
BAAs are a vendor-by-vendor question. Your Salesforce agreement is one leg. The AI vendor is a separate one — whether your Claude or ChatGPT plan tier offers a business associate agreement is a question for that vendor and your counsel. And the MCP server itself is a third leg: understand whether it stores data, proxies it, or passes it through, and review it like any other subprocessor.
De-identification patterns buy you room. Many high-value workflows — triage summaries, ops reporting, data-quality checks — work fine on structural data with identifiers minimized. Where the assistant can operate on record IDs and de-identified fields, let it. Reserve identified-data access for the narrow cases that truly require it, and document each one with your compliance team.
The pre-connection ops checklist
- Create a dedicated permission set for AI access — never reuse an admin profile or an existing integration's grants.
- Start read-only. Log every write permission you add later, with the reason and the requester.
- Strip sensitive fields via FLS before the first connection, not after the first incident.
- Decide user-context vs. integration user per use case, and write the decision down where the next admin will find it.
- Lock down the connected app: minimal OAuth scopes, admin pre-authorization, IP restrictions where the pattern allows.
- Run the real workload in a sandbox for at least a week and read the logs before promoting.
- Enable Event Monitoring or equivalent API logging before go-live, so day one is baselined.
- Review access logs weekly for the first month, then monthly once the pattern is stable.
- Write a revocation runbook — who pulls the plug, and the exact clicks — and rehearse it once.
- Re-review quarterly: new fields, new objects, and new use cases all silently expand the surface.
Monitoring and revocation
Ongoing operation is unglamorous and short: know what normal looks like, and know how to stop everything fast. For the first, watch login history and API usage for the connected identities, and skim event logs for query patterns that don't match the intended use case — an assistant scoped for case triage has no reason to be reading compensation objects.
For the second, define the available controls—revoke OAuth tokens, freeze or deactivate an integration user, disable the connected app, and remove connector access—then rehearse them and verify that new calls fail. Token caching and architecture choices can change the effective shutdown window, so measure it instead of promising it.
Where to go from here
The honest summary: connecting AI to Salesforce through MCP is a systems-security exercise wearing a futuristic costume. Salesforce permissions are one layer; connector behavior, model context, action scope, approvals, downstream systems, monitoring, and revocation complete the boundary.
If you're in healthcare, our healthcare practice works through these architecture constraints with compliance stakeholders at the table. If you're ready to see what a properly scoped assistant can do, start with Claude + Salesforce, or have us stand up the whole thing safely with AI setup & enablement.