Salesforce Hosted MCP Servers Inherit Your Permission Debt
Salesforce hosted MCP servers went generally available in April 2026 for every Enterprise Edition org and above. The pitch is short: enable a server in Setup, register an External Client App, and any MCP client, whether Claude, ChatGPT, or Cursor, can read and act on your org as the signed-in user. The security line Salesforce leads with is that your existing permissions automatically apply: CRUD, field-level security, sharing rules, every control you already run. That is true, and it is the right design. It is also the point where a security review of the feature should begin, not where it ends, because the permission model most orgs actually operate was built for people clicking through screens, not for an assistant that can enumerate every object a user can see in a single conversation.
What a hosted server actually hands to the client
A hosted MCP server is a Salesforce-managed endpoint. The standard servers are pre-configured, disabled by default, and their tool sets cannot be modified by an admin. The SObject family is the one most teams will enable first. SObject Reads gives read-only access to standard and custom objects, with tools that list every queryable object, return field-level schema, run SOQL, run a text search across multiple objects at once, and walk from a record to its related children. SObject Mutations adds create and update, SObject Deletes adds delete, and SObject All exposes every standard and custom object in the org through the full set. Beyond that family there are servers for Data 360 queries, Tableau Next, CMS content, Archive Connect, Backup and Recover, and a Headless 360 server in beta that reaches into Setup itself.
Authentication is per-user OAuth 2.0 with PKCE through an External Client App carrying the mcp_api and refresh_token scopes. The GA post is explicit that the new scope grants access to MCP but not to the existing REST APIs, and that servers have to be specifically enabled. Those are good defaults. They govern whether a client can connect. They do not govern what a user’s assistant does once it has.
“Your permissions apply” describes access, not egress
Read the GA post and the server docs carefully and the security argument is entirely about access: every transaction runs as the authenticated user, an agent cannot update a field the user cannot edit in Lightning, and if the user’s permissions do not allow an operation the agent cannot do it either. What the argument leaves out is where the data goes afterward. Once a query result leaves the hosted server it sits in the context window of whatever client the user connected, on that vendor’s infrastructure, under that vendor’s retention terms, and possibly in that user’s personal chat history. Salesforce enforces what the user may read. It has no say over where the client sends what it read.
The GA post half-acknowledges this. It notes that Salesforce has always had strong access controls but that this is not true of every enterprise system, and points to MCP gateways such as MuleSoft AI Gateway for centralized governance across vendors. For an organization that handles patient data, the sharper version of that point is that each client your users are allowed to connect becomes a system that receives regulated data. It needs the same vendor review, agreements, and offboarding as any other system that does. Salesforce’s own setup guide says that by default any user in the org can authenticate through the External Client App, and that refresh tokens remain valid indefinitely unless an admin shortens them. Both defaults are reasonable for a sales team. Neither is acceptable for a care coordination org without changes.
Permission models drift, and MCP collects the drift
Every mature org carries permission debt: org-wide defaults left at public read because a report needed it years ago, View All granted to a profile so a dashboard would work, permission sets that accumulated as projects came and went. A human user rarely notices the drift, because discovering what you can see in Salesforce takes effort. You open a tab, build a report, click through related lists. The friction is not a control anyone designed, but it has been doing a control’s job.
An MCP client removes the friction. The schema tool in SObject Reads is built to return a compact index of all queryable objects so the model can decide where to look, and the search tool queries across objects in one call. The SObject All reference puts the ceiling at 50,000 total records per transaction across all queries. A user who asks “find everything we have on this patient” will get exactly that, across every object their sharing settings expose, in seconds, with no report to build and no record of intent. The permission debt did not get worse. It became reachable.
This is also why the “human at the wheel” framing in the GA post deserves a closer look. It is accurate for writes: if the agent updates a record, that person’s name appears in the audit trail. Reads are covered more specifically than the GA post spells out, and less fully than a compliance team might assume. Salesforce’s security guidance says every MCP call lands in the standard API logs with user attribution, filterable on an API client category of SALESFORCE_HOSTED_MCP, and that those logs record which operations ran, which objects were accessed, and when. What the documented log does not claim to capture is which records or which fields came back. For an object that holds protected health information, settle that gap in a sandbox before enabling a read server: pull the log for a test session and check whether it meets your access-log requirement, or whether you need a narrower tool that records what it returns.
What we would do
We treat a hosted MCP server as an integration with a reviewed design, the same discipline we apply on the platform behind Ariv Health, where every AI-facing path crosses a masking layer that strips PHI before any model sees it.
Gate the External Client App with a custom permission set required for pre-authorization, so MCP access is an explicit grant rather than the org-wide default. Shorten refresh token validity to 30 days or less with rotation, as Salesforce’s own guide recommends, and enable single logout so revoking a Salesforce session revokes the client session with it.
Before enabling any SObject server in production, audit the sharing model from the assistant’s point of view. Run the schema index and the cross-object search as a representative user in a sandbox and read the output as a list of what will be exposed. Fix org-wide defaults and View All grants first. Enabling the server before that audit is the real risk. The server itself is not.
For objects that hold PHI, skip the SObject servers and expose curated operations instead. A custom hosted server can front Flows, Apex Invocable Actions, and Named Queries as tools that return the minimum fields a use case needs rather than whatever the user’s profile permits. Salesforce’s security guidance lists read-only servers, Named Queries for a specific slice of the data model, and custom tools with embedded logic as ways to dial back agent capability, and says to start with the most restrictive configuration that meets the use case. For patient data, take that literally. A “prior authorization status for this referral” tool is bounded and reviewable. SObject Reads on the Case object is neither.
Because dynamic client registration is not supported, the External Client Apps in your org, and their callback URLs, define which clients can connect. Keep that list short, review each entry as a vendor, and treat it as a compliance artifact. Watch Flex Credit consumption from the first week, because Salesforce meters hosted server usage against Flex Credits and may bill for it, and one question from an assistant can mean many tool calls.
Salesforce built the access side of this feature well. The per-user model, the disabled-by-default posture, and the scoped servers are what a platform vendor should ship. The part that remains yours is deciding what your permission model actually exposes, where the data goes after the call returns, and which clients are allowed to ask. Those decisions were always yours. Hosted MCP servers just make the cost of not having made them show up faster.