The first time I told a colleague that Claude could call Apex in my Salesforce org, the reaction was immediate: “Wait — the AI can touch your org?” Said out loud like that, it does sound alarming. An external AI assistant, reaching into your CRM, running your business logic, creating records.
But here’s the thing I’ve learned after sitting with the architecture for a while: the sentence is scarier than the system. When you actually walk through the layers of the Hosted MCP security model, what you find isn’t a hole punched in your org’s wall. It’s the same identity and permission machinery Salesforce admins have trusted for years — applied to an AI client instead of a mobile app.
Let me walk you through it the way I’d explain it to a security-minded admin on day one. No hand-waving, no “trust the vendor.” Just the layers, one at a time.
Layer 1: The External Client App and least-privilege scopes
Nothing talks to your org without an app registration, and MCP is no exception. Hosted MCP access goes through an External Client App — the modern successor to Connected Apps — that you, the admin, create and control.
This is where the first security decision happens, and it happens before any AI is involved: scopes. When you configure the External Client App, you choose exactly which OAuth scopes it gets. Least privilege isn’t a nice-to-have here; it’s the design. If the MCP client only needs to run agent actions and query data, that’s all the app is granted. It can’t suddenly decide to manage users or change metadata, because the token it receives is simply not capable of it.
Think of the External Client App as the doorway you built, with a lock you chose. The AI doesn’t find its own way in. It walks through the door you defined, and the door only opens onto the rooms you listed.
Layer 2: Per-user OAuth 2.0 with PKCE — no anonymous service accounts
Here’s the layer that changed how I talk about this: every single MCP call runs as an authenticated user. Not a shared integration user. Not an anonymous service account with god-mode permissions that nobody remembers configuring. A real, named user who signed in.
The flow is standard OAuth 2.0 with PKCE (Proof Key for Code Exchange). If you’ve ever connected a mobile app to Salesforce, you’ve seen this dance: the client generates a one-time secret, the user is redirected to the familiar Salesforce login page, they authenticate — MFA and all — and the client exchanges the code for a token that is bound to that user.
PKCE matters because MCP clients are public clients — they can’t safely hold a client secret. PKCE closes the classic interception attack: even if someone steals the authorization code mid-flight, they can’t redeem it without the original secret the client generated. This isn’t exotic. It’s the same hardening every serious OAuth implementation has used for years.
The consequence is worth pausing on. When Claude calls a tool in my org, Salesforce doesn’t see “an AI.” It sees me — my user record, my profile, my permission sets. Which sets up the next layer beautifully.
Layer 3: USER_MODE — the AI inherits your permissions, not superpowers
A token identifying the user is only half the story. The other half is what happens when code actually runs. Apex, by default, can run in system context — which is exactly what you don’t want an AI-triggered action doing.
This is where WITH USER_MODE comes in. When the Apex behind an MCP tool queries or writes data in user mode, Salesforce enforces the calling user’s field-level security and CRUD permissions on every operation. If I can’t see the AnnualRevenue field, the AI acting as me can’t see it either. If my profile can’t delete Opportunities, no cleverly-worded prompt changes that.
I find this is the moment the fear usually dissolves for admins. The question “what can the AI do?” has a boring, precise answer: exactly what the authenticated user can do, and not one field more. You don’t need a new mental model for AI permissions. Your existing profiles, permission sets, and sharing rules are the AI permission model.
And for actions with real consequences — creating records, sending things, changing data — there’s a human checkpoint on top: user consent before consequential actions. The AI proposes; the user confirms. The architecture assumes the human stays in the loop for anything that matters.
Layer 4: The audit trail — everything is attributable
The last layer is the one that makes the whole thing reviewable after the fact: full audit trails.
Because every call runs as a named user through a registered app, every action lands in your org’s existing audit machinery with a real identity attached. Records created by an MCP tool show the actual user as the creator. Login history shows the OAuth session. There is no anonymous blur of “the integration did it” — the thing every auditor dreads — because there is no anonymous anything.
Twenty years in education taught me that accountability changes behavior, in classrooms and in systems. An architecture where every action is attributable to a person, through an app you registered, with scopes you chose, is an architecture you can actually govern.
What a security reviewer would ask — and the answers
When I imagine sitting across from a security reviewer (and having a product in AppExchange Security Review, I’ve done more than imagine it), the questions are predictable. Here’s how this model answers them:
- “Who does the AI authenticate as?” A named user, via OAuth 2.0 with PKCE through an External Client App. There is no service account. No user, no access.
- “What can it access?” The intersection of the app’s least-privilege scopes and the user’s own permissions. Two fences, and the call must be inside both.
- “Does it bypass field-level security?” No — Apex running
WITH USER_MODEenforces the caller’s FLS and CRUD on every query and DML operation. - “Can it take destructive actions silently?” Consequential actions require user consent before they run. The human sees what’s about to happen and approves it.
- “How do we investigate an incident?” The same way you always have: audit trails tie every action to the authenticated user and the registered app.
Notice something about these answers? None of them required inventing new security concepts. Every layer — app registration, OAuth, PKCE, user-mode enforcement, audit logs — is a mechanism your org already relies on. The MCP model didn’t ask Salesforce security to make an exception for AI. It made AI walk through the front door like everyone else.
The honest takeaway
I won’t tell you there’s nothing to think about. You still have to configure scopes deliberately, write your Apex in user mode, and decide which actions deserve a consent gate. Sloppy configuration is sloppy configuration, with or without AI.
But the fear packed into “AI can touch my org” mostly evaporates once you replace the sentence with the diagram. An authenticated user, inside a scoped app, running permission-checked code, leaving a full trail. That’s not a horror story. That’s a Tuesday in a well-run org.
In the next post in this series, I’ll show you what this looks like when it’s real — two Apex actions from my own org, exposed as MCP tools, doing an entire lead-to-deal flow from one plain-language request.