Connect Claude to Salesforce: Audit the Access First

A Salesforce connection can work exactly the way you configured it and still hand Claude more access than you meant to give.

Say you want help preparing for account reviews. The person who authorizes that connection probably has access to sensitive fields and records that have nothing to do with account reviews. So before you connect Claude to Salesforce, look at what that person can actually reach and which tools the connection opens up.

For Salesforce Hosted MCP Servers, every call runs under the authorizing user's identity and that user's existing Salesforce permissions. Your access model becomes part of the connection design, whether you planned it that way or not. Salesforce's general guidance explains how that inheritance works.

Quick take: Start with one limited business task and a read-only server. Review each participant's real access, including permissions granted somewhere you forgot to look. Test the requests that should fail before you approve production use. A successful sign-in only proves the connection works. It says nothing about whether the access is appropriate.

Choose the connection you plan to audit

This guide covers Claude's custom connector talking to Salesforce Hosted MCP Servers. Other integrations have their own setup steps and security requirements.

As of October 2026, Salesforce has announced Hosted MCP Servers as generally available for Enterprise Edition and above. The April 2026 GA announcement replaces older beta-era assumptions.

Check your org's eligibility and usage terms before you start. The current overview says Hosted MCP Servers are intended for customers with Flex Credits, and usage may be billed. Our separate Salesforce MCP and Claude cost guide covers budget planning. This page is about the access decision.

Write down the first task in ordinary language. Something like: prepare an account review using the opportunities the salesperson can already see, without changing anything in Salesforce. That gives your admin something concrete to test, and it gives the business owner a clear limit to approve.

Review the person who will authorize Claude

Each participant uses their own Salesforce identity on this path. Salesforce supports browser-based authorization here, not one shared integration user sitting behind everybody's MCP sessions. The admin who configures the app and the person who uses it carry different responsibilities, and Salesforce's security article walks through that difference.

Look at the user's profile, permission sets, and permission set groups together. Adding a narrow permission set does not subtract broader access granted somewhere else. A permission set called "AI Read Only" cannot take away Edit access that another assignment already handed out. Salesforce's object-access guidance explains how grants combine and how to pull up a user's access summary.

Write down what your pilot users can do at each level:

• Objects: Can they read, create, edit, or delete the kinds of records the task involves?
• Fields: Which values can they read or change, including sensitive custom fields?
• Records: Which individual records can they reach through sharing and the role hierarchy?
• Broad permissions: Do permissions like View All Data or Modify All Data blow past the sharing boundaries you expected to hold?

Pulling a field off a page layout does not secure it. Use field-level security to control access to the value itself, which is what Trailhead's field-security guidance covers. Our guide to roles, profiles, permission sets, and page layouts helps business owners follow along with the review.

Some of that broad access may be exactly right for the person's day job. When that happens, decide whether those same records belong in the Claude workflow you have in mind. Do not assume that an extra permission set gives the assistant its own narrower identity, because it doesn't.

Start with tools that match the task

For the account-review example, start in a sandbox with Salesforce's platform/sobject-reads server. As documented in October 2026, it can query standard and custom objects, and it cannot create, update, or delete records through that server. Salesforce's SObject Reads reference lists the tools and endpoints.

Read-only access still needs a data review. It stops changes through those tools, but a query can return anything the user is allowed to read. Decide which information belongs in the assistant's workflow before you turn the access on.

Review the other active servers while you are in there. Salesforce's External Client App configuration does not limit a user to a single MCP server, so app authorization, available tools, and data permissions each need their own attention. Salesforce documents that limitation.

When a general query tool reaches further than the task needs, consider a custom tool that returns a defined set of fields. Salesforce supports custom servers backed by Apex or Flows. Review the execution context of that code or Flow before you rely on it for access control. In Apex, sharing settings by themselves do not enforce object and field permissions, as the secure Apex guide explains.

Configure the connection after the access review

The steps below follow the vendor documentation as checked in October 2026. Keep the full configuration record with your audit so another admin can maintain it later.

1. Activate the intended server in Salesforce Setup. Hosted MCP servers have to be enabled explicitly. Begin with the read-only server for this pilot.
2. Create an External Client App. This Hosted MCP path does not support Connected Apps. Use https://claude.ai/api/mcp/auth_callback as the Claude callback and include mcp_api and refresh_token. Configure JWT-based user access tokens following the External Client App instructions.
3. Limit who can authorize the app. Configure pre-authorized access for the approved profiles or permission sets, and confirm the PKCE requirement in the security documentation. App eligibility controls who can connect, and it does not replace the user's data permissions.
4. Add Claude's custom connector. For this sandbox pilot, use https://api.salesforce.com/platform/mcp/v1/sandbox/platform/sobject-reads. Select "Use your own OAuth client" and enter the External Client App's consumer key, then connect with the intended user's Salesforce account, following Salesforce's Claude configuration guide.

On Claude Team or Enterprise, an authorized workspace administrator has to make the custom connector available first. Each participant then connects individually. See Anthropic's custom-connector instructions for the current role requirements.

Our Salesforce MCP setup overview gives you broader context. Keep the vendor instructions open for the current settings instead of copying a configuration from last quarter.

Require evidence that the blocks hold

Our approval rule is simple. Approve a specific group of users and a specific task only after both the allowed requests and the prohibited ones behave the way you expected.

Use controlled test records in the sandbox. Keep the request, the expected result, the actual tool response, and the reviewer together in one place. What follows is a proposed test plan, not a claim about results from a customer deployment.

• Retrieve an opportunity the user may access: The correct record and permitted fields return.
• Request a field the user must not read: The tool response does not disclose the restricted value.
• Request a record outside the user's sharing access: The tool response does not disclose that record.
• Ask the read-only connection to change a record: No Salesforce record changes through the connection.
• Revoke the test connection's access: A fresh tool request fails until access is properly restored.

Read the tool response, not only the answer Claude writes back to you. A polite refusal from the model does not tell you that Salesforce blocked anything. Salesforce recommends testing tools directly with Postman when you need to separate authentication and tool behavior from the model's interpretation.

A quiet week with no complaints is not an approval. Resolve any unexpected access first, then run the affected checks again. Expand to another group of users when you can explain that group's access and show the evidence behind it.

Check the logs and plan for what changes next

Setup Audit Trail tracks configuration changes, and it is not a complete record of what Claude read. Salesforce's auditing overview draws the line between setup changes and data-usage monitoring.

For MCP activity, Salesforce documents API logs with API_CLIENT_CATEGORY set to SALESFORCE_HOSTED_MCP. Confirm your org's log access and retention, then check that a test request shows up with the expected user attached to it. The MCP security guidance describes what attribution you get.

Write down who reviews unexpected activity each week and who can turn the connection off. Before you add write tools, test the proposed changes in a sandbox and review Claude's tool-approval settings. Anthropic advises reviewing approval requests carefully before you let a tool run without asking again.

Treat every added data source as another access review. As of October 2026, Salesforce also documents a Data 360 MCP server with its own prerequisites. SOLVD's data practice covers data strategy and architecture across Databricks and Salesforce Data 360. An approved CRM pilot should never quietly turn into approval for your whole data estate.

SOLVD's Salesforce integration services can help you define the workflow and review the connection design, and our AI consulting practice can help you work out who owns this after launch.

If you want a second set of eyes on the connection you are planning, book a fit conversation. Bring the task you want Claude to handle and the access questions you still need to answer.