Salesforce hosted MCP servers: who reads which data?

Through Salesforce hosted MCP servers, an AI client such as Claude or ChatGPT reads exactly what the user who authorised the connection may read. On the Salesforce side that is well designed: OAuth with PKCE, no service accounts, every call in the API log under a person’s name. The weak point sits after the call. Once the records reach the external model, in my assessment the Einstein Trust Layer no longer protects them, and your contract with the AI provider decides what happens. I would start with sobject-reads, one permission set per user group and a reviewed AI contract.

How do hosted MCP servers decide who sees what?

Salesforce made hosted MCP servers generally available on 29 April 20261 for every Enterprise Edition org and above. MCP (Model Context Protocol) is the open standard through which an AI client calls tools in another system; the basics are in MCP for IT leads. The servers stay off until an administrator enables them. The server reference2 lists four sObject servers (All, Reads, Mutations, Deletes) plus Data 360, Tableau Next and Headless 360 (beta).

The access model is set out in the security best practices3:

• Named user. Each tool call runs with the object permissions, field-level security and sharing of the user who authorised the connection, and appears under that name in the audit trail.
• No technical users. “There are no service accounts, no machine-to-machine flows.” A person always has to log in.
• OAuth with PKCE. Login runs through the authorisation code flow in the browser. PKCE (Proof Key for Code Exchange) is mandatory and stops an intercepted authorisation code from being redeemed by someone else.
• No self-registration. An admin creates an External Client App for each AI client and can restrict it to profiles and permission sets.

For admins

Which scopes does the AI client request?

The official Claude setup (opens in a new tab) requests the scopes refresh_token, offline_access, labelled "Perform requests at any time". After one login the client keeps working until the token is revoked or expires, so the refresh token policy matters.

On the positive side, the mcp_api scope gives access to MCP "but not our existing REST APIs", according to the GA post. A token stolen from an MCP client opens less than a classic API token.

Permissions apply per person, not per channel

The security guide states the rule: what a user cannot do in the Lightning UI or the REST API, they cannot do through MCP. The reverse holds too. Everything a key account manager can open in Lightning, the AI client can query, and one query returns hundreds of records that a person would click through one at a time.

Field-level security belongs to the user, not to the channel. If your sales users can read dealer purchase prices, margin fields or the personal data of service technicians, Claude can read them too, and they leave Salesforce.

If an external model should see less than the person, the standard sObject servers cannot help, because their tool sets cannot be changed. Three things can:

• Named Queries. An admin exposes a fixed SOQL query as an API, created in Setup or VS Code according to the REST API guide4. A query “open cases for serial number X” with five fields replaces free SOQL.
• Custom servers. Flows, invocable Apex, Apex REST and API Catalog endpoints can be bundled into a custom server5. Salesforce recommends focused, persona-specific servers, because “beyond a few dozen tools, an AI client struggles to select the right one”. A Flow that returns a dealer overview without price fields answers the question and hides the rest.
• Dedicated users. Salesforce’s own example ties a data hygiene server to “a dedicated user profile that only data stewards can authenticate as”.

Custom servers cost build effort, but they also cut calls per question, which counts once Salesforce bills them, see MCP calls as a budget risk.

Start with sobject-reads in a sandbox

The GA post recommends sobject-reads in a sandbox and calls it “read-only, risk-free, and immediately useful”. I agree with the starting point, not with “risk-free”. The security guide is more precise: the read-only server removes modification risk. It does nothing about data leaving through the client.

Simon Willison calls the dangerous combination the lethal trifecta6: access to private data, exposure to untrusted content and a way to communicate externally, and he notes that MCP encourages mixing tools from different sources. A Claude session with sobject-reads, web access and an email server has all three. At a manufacturer, untrusted text reaches the CRM through dealer portals, web-to-lead, email-to-case and warranty forms, see prompt injection in dealer portals.

My order: sobject-reads in a sandbox for a small group; Named Queries or a custom server per persona before production; sobject-mutations only for a defined process with approval in the client, which Salesforce in Claude asks for by default according to Anthropic’s setup guide7. sobject-deletes and sobject-all I would not give to business users at all.

Does the Einstein Trust Layer protect data that Claude reads?

Salesforce has not documented this case; what follows is my reading, not a Salesforce statement.

The Trust Layer documentation8 lists protections “when interfacing with LLMs”: grounding, masking of sensitive data, toxicity detection, audit trail and zero data retention agreements with third-party LLM partners. Trailhead describes the path9: personal data is masked before the prompt leaves Salesforce, passes the Secure LLM Gateway, and “no customer data including the prompt text and generated responses are stored outside of Salesforce”. All Models API10 calls go through the Trust Layer, and when Agentforce is the MCP client, Trailhead promises11 the Trust Layer and zero data retention as well.

Hosted MCP reverses the direction. Claude, ChatGPT or Cursor is the client and brings its own model. Salesforce checks token and permissions, runs the query and returns records, which the client then puts into a prompt for its model. Salesforce makes no LLM call on this path, so no gateway step exists where masking could act, and its zero data retention agreements bind Salesforce’s LLM partners for Salesforce’s calls, not a model you license yourself. The documents fit this reading: the hosted MCP overview, the security guide, the GA post and the Claude setup post cover authentication, permissions and logging, and none mentions the Trust Layer.

Two statements need care. The Claudeforce release12 says that through Amazon Bedrock, Claude is available within the Salesforce Trust Boundary. That is Claude as a model inside Salesforce, not the Claude app on a sales rep’s laptop. The AIforce announcement13 says business data “is not retained by the model provider”, while Anthropic’s setup guide says nothing about retention.

Until then your AI contract governs the data. For Claude Code, Anthropic’s data usage page14 says commercial prompts are not used for training, standard retention is 30 days, and zero data retention is enabled per organisation for eligible Enterprise accounts. These terms go to your data protection officer, and to the works council where employee data is involved, see AI coding tools, works council and GDPR.

Example: three requests at a machine builder

Assume a machine builder with Sales Cloud, Service Cloud, SAP, a dealer network and Claude Enterprise. All numbers are assumptions. In one month IT receives three requests.

Dealer managers. Twelve users want Claude to prepare dealer visits. Their profile can read purchase prices on the dealer price agreements. Decision: a custom server “dealer visit” whose Flow returns the overview without price fields, restricted to a permission set for these twelve.

Service back office. Thirty users want to look up cases, installed base and warranty status by serial number. Decision: sobject-reads plus a Named Query by serial number. Some case descriptions come from the dealer portal, so web access in their Claude workspace stays off.

The implementation partner. A developer asks for sobject-all in production to merge duplicate assets with Claude. Decision: no. The calls would run under his production user, and a bulk change belongs in a reviewed data load. He gets sobject-reads in a sandbox to analyse the duplicates.

Two of three go ahead, both narrower than asked. In my judgement that is the normal outcome of an access review.

Decide who may connect before the first connection

1. Decide who may connect. Restrict each External Client App to a permission set with the OAuth policy “Admin approved users are pre-authorized”. Keep administrators out: an admin who authorises Claude hands it almost the whole org.
2. Review sharing and field-level security for cases, assets, warranty claims, price agreements and contacts.
3. Enable only sobject-reads, first in a sandbox.
4. Narrow with Named Queries or custom servers wherever the person sees more than the model should.
5. Set the refresh token policy and a revocation process for leavers and lost laptops. Why stolen OAuth tokens are a real attack path is covered in connected apps and OAuth lessons.
6. Settle the AI contract: training, retention, zero data retention, hosting region.
7. Watch the API logs for who reads which objects in which volume.

This is part of my work on Salesforce integration: an MCP server is an interface and needs an owner. Hosted MCP enforces the permissions reliably; what you decide is which people, fields and AI contract you trust with the data.

Sources14

1. 1generally available on 29 April 2026 (opens in a new tab)developer.salesforce.com
2. 2server reference (opens in a new tab)developer.salesforce.com
3. 3security best practices (opens in a new tab)developer.salesforce.com
4. 4REST API guide (opens in a new tab)developer.salesforce.com
5. 5custom server (opens in a new tab)developer.salesforce.com
6. 6lethal trifecta (opens in a new tab)simonwillison.net
7. 7Anthropic’s setup guide (opens in a new tab)support.claude.com
8. 8Trust Layer documentation (opens in a new tab)developer.salesforce.com
9. 9the path (opens in a new tab)trailhead.salesforce.com
10. 10Models API (opens in a new tab)developer.salesforce.com
11. 11Trailhead promises (opens in a new tab)trailhead.salesforce.com
12. 12Claudeforce release (opens in a new tab)salesforce.com
13. 13AIforce announcement (opens in a new tab)salesforce.com
14. 14data usage page (opens in a new tab)code.claude.com