When I show a hosted MCP server to a Salesforce admin for the first time, the first question is almost never about the technology. It is some version of: “If a model changes a record through this thing, who changed it?” I spent six years as a guidance counselor before I moved into tech, and I recognize that tone immediately. It is not resistance. It is responsibility. The person asking will be the one sitting in the meeting when something goes wrong, and they want to know, in advance, what they will be able to say. This post is for that person — and for the developer who has to answer them.
Earlier in this series I walked through the setup itself: an External Client App acting as the OAuth bridge with least-privilege scopes and PKCE, activating a server, choosing its tools, connecting a client. I will not re-teach that here. Setup is an afternoon. Today is the harder part: rolling that working connection out to a team of humans — the scopes, the tool list, the pilot, and the audit trail. (If MCP is new to you: the Model Context Protocol is the open standard that lets an AI client call tools your Salesforce org exposes. Start at the beginning of the series and come back.)
Every call has a name
Here is the single most important fact about hosted MCP in Salesforce, and I want you to have it ready before any rollout conversation: every MCP call runs as the authenticated user.
Each teammate connects through their own OAuth login. OAuth, if the term is new, is the standard way one system grants another limited access on your behalf without ever handing over your password. There is no anonymous service account sitting between the model and your data, no shared integration user that everyone quietly borrows.
That means the audit trail — the record your org keeps of who did what, and when — carries a real person’s name on every action that came through MCP. Not “the AI did it.” A name.
In my experience, this one fact answers most admin objections before they are raised. The fear underneath “what if the model does something?” is almost always “and we will not know who was responsible.” With per-user OAuth, you will.
Every MCP call runs as the authenticated user. “Who did this?” is never a mystery — it always has a name.
Least privilege, twice
Least privilege is the old, boring, correct idea that everything should have exactly the access it needs and not one field more. In an MCP rollout it applies twice, at two different layers, and understanding both is what lets you sleep.
Layer one: the connection. The External Client App’s scopes bound what the connection is allowed to do at all. A scope is a named slice of capability granted to the app — and if the app was never granted a capability, no tool call can use it, no matter how the model phrases the request.
Layer two: the person. Even inside those scopes, every call still runs as the user — so the user’s own permission sets and profiles bound which objects and fields they can actually read or write. Someone who cannot see a field in Salesforce cannot suddenly see it through an MCP tool. And inside custom tools you write yourself, WITH USER_MODE in your SOQL and DML enforces field-level security and CRUD (create, read, update, delete permissions) right at the database operation, instead of trusting the code to remember.
One warning I repeat every time, because it catches even experienced admins: UI visibility settings are discoverability, never authorization. Removing a field from a page layout only decides what people happen to see on a screen. It does not decide what they — or a tool acting as them — may access. Only permissions do that, and only USER_MODE makes your own code respect them.
Hiding something in the UI is not security. Authorization lives in permissions, scopes, and USER_MODE — the layout just decides what is easy to find.
Curate the tool list like a syllabus
The second rollout decision is which tools each server exposes, and the rule is simple: the smallest useful list.
Twenty years in classrooms taught me that you do not hand a new group every tool in the workshop on day one. You start with the safe ones, watch how they are used, and expand deliberately. MCP servers work the same way.
Start the pilot with read-only tools — queries, lookups, “find me this record” — and nothing that writes. A read-only mistake is a wasted query; a write mistake is a data-quality incident. Once the team trusts the flow, add write tools one at a time.
And resist the urge to build one giant server for everyone. A server for the support team and a server for the sales team do not need to offer the same tools, because the jobs are not the same. Smaller, purpose-shaped tool lists are easier to explain, easier to audit, and easier to reason about when something looks odd.
Run the pilot like a first week of school
Three habits make the difference between a pilot and a mess.
Start with a small group. Not the whole org, not even the whole team. A handful of people who will actually use it and actually tell you the truth about it.
Read the audit logs in week one — not after an incident. This is the habit I push hardest. Logs you only open during a crisis are logs you cannot interpret, because you never learned what normal looks like. Spend twenty minutes in the first week just reading: who called what, how often, anything surprising.
Write one paragraph per tool, for humans. Yes, the model reads the tool descriptions to decide when to call them. But your teammates need their own version: what this tool does, and what data it touches, in plain language. From my counseling years I can tell you — people trust what they can explain to someone else. If a support agent can say in one sentence what the “order lookup” tool touches, they will use it with confidence instead of superstition.
If you need to step back, step back
Here is the quiet advantage of hosted MCP: rollback is cheap. Deactivating a server, or removing a single tool from it, is configuration — not a deployment. No pipeline, no release window. If week one shows you exposed too much, narrow it and carry on. That safety net is exactly what makes “start small, expand deliberately” a practical plan rather than a slogan.
Two honest limits before you go. First, admin UI labels and exact settings in this area are still evolving — treat my wording as the shape of the thing, and check the current documentation and verify in your org before you write your own runbook. Second, no amount of scoping replaces judgment: for anything consequential — writes, sends, anything a human would want to approve — keep a human confirmation step in the client. The model proposes; a person confirms.
Your next step
Pick one team. Set up one server for them, with three read-only tools — no writes yet. Write the one-paragraph human description for each tool before anyone connects. Connect your pilot group through their own logins, and set a calendar reminder to read the audit logs on day three and again on day seven.
That is the whole rollout: named users, layered permissions, a short tool list, and logs you read while everything is still fine. It is not glamorous. Neither is a good first week of school — and that is exactly when trust gets built.