Salesforce MCP Write Access: Set It Up Safely

Salesforce MCP write access exists, it is generally available, and most of the people asking about it are asking the wrong question. The question people type into Google is “does the Salesforce MCP have write capabilities.” The answer is yes. The question that actually decides whether this is useful to you is which writes — because Salesforce ships four different SObject servers with four different blast radii, and the one you turn on is the entire security decision.

Here is the short version, then the setup, then the part nobody tells you: the Salesforce MCP writes records. It does not write your org.

The four servers, and why picking one is the whole decision

Salesforce’s hosted MCP reference lists the standard servers, and the SObject family splits along exactly the line you would want it to:

SObject Reads — “Read and query only, no mutations.”
SObject Mutations — “Create and update operations, no delete.”
SObject Deletes — “Delete operations only.”
SObject All — “Full CRUD operations (create, read, update, delete) plus query and search across all Salesforce objects.”

Most orgs reach for SObject All because it is the one that obviously does everything. That is the reflex worth resisting. The split exists so you can hand an agent the ability to create and update without also handing it the ability to delete — and for the overwhelming majority of real agent work (log the call, update the stage, create the follow-up task), Mutations is the whole job.

Salesforce’s own security guidance is blunt about this: “By default, all MCP servers are inactive. Only activate the ones that you intend to expose to agents.” Take that literally. Turning on Deletes because you might need it someday is how you end up explaining a recycle bin to your VP of Sales.

Step 1: Decide what “write” means here before you touch Setup

Before the admin work, write down the sentence you want to be true. Not “our AI can update Salesforce” — that is not a specification, it is a wish. Something like: “Our AI can create Tasks and update Opportunity StageName and NextStep on opportunities the running user already owns.”

That sentence does three things. It picks your server (Mutations). It tells you which objects and fields the permission set needs. And it gives you the test you will run in Step 5 to confirm the thing you built is the thing you described.

Skip this and you will configure access by vibes, then discover the boundary six weeks later when something writes to a field that feeds a commission report.

Step 2: Register your client as an External Client App

Setup is OAuth, not an API key. Per Salesforce’s setup overview, you need “System Administrator or equivalent permissions to create an External Client App in Setup,” and the flow is:

Identify the MCP client you are connecting (Claude, ChatGPT, Cursor, Postman, or similar).
Create the External Client App — this “registers your MCP client as an OAuth application in Salesforce.”
Configure OAuth scopes for the operations the servers will perform on behalf of the authenticated user.
Enable “Proof Key for Code Exchange (PKCE) and JWT-based tokens.”
Set the callback URL specific to your chosen client.

The External Client App is the modern replacement for the Connected App you may have muscle memory for. If your last integration setup was two years ago, this is the part that has changed.

Step 3: Scope the app, then let permission sets do the real work

This is where people over-invest in the wrong control. OAuth scopes govern what the app may attempt. They are coarse. The thing that actually decides what happens is your existing Salesforce security model, and it applies unchanged.

Every hosted MCP server, per Salesforce’s reference, enforces “per-user authentication” and respects “field-level security, object permissions, and sharing rules” on every tool call. Object-level CRUD, FLS, and sharing rules all still apply. That is genuinely good news, and it means the correct move is boring: build a permission set that grants exactly the objects and fields from your Step 1 sentence, assign it to the users who will connect, and stop there.

Salesforce says the same thing in its security guidance — “work with permission sets to protect sensitive operations and follow the principle of least privilege.” An agent connected as a user with narrow permissions is narrow. An agent connected as a user with Modify All Data is a very fast intern with Modify All Data.

Step 4: Connect, and test on reads first

Point your MCP client at the org, complete the OAuth handshake as a real user, and then — before you enable anything mutating — run a read. Ask for a handful of records. Ask for the fields you expect to write to later.

Two things go wrong here and both surface on reads, cheaply. The first is scope: a field comes back empty and you assume the data is missing when FLS is hiding it. The second is identity: you authenticate as yourself, an admin, see everything, and ship a configuration that behaves completely differently for the rep who actually uses it. Read-testing costs ten minutes and catches both.

Step 5: Verify the write lands as the right user

Now enable Mutations and write one record. Then go look at it in the UI, and specifically look at Last Modified By.

This is the check that matters, because attribution is the property the whole model rests on. Salesforce’s security post states that “all actions that are performed by the MCP tools are attributed to the user that connected to the ECA in audit trails,” and that “Salesforce automatically logs MCP server activity using Event Monitoring.” If Last Modified By shows the human who authenticated, your setup is correct and your audit trail is intact. If you were expecting some generic integration user, read the next section — that expectation is the one Salesforce deliberately broke.

The constraint most people trip over: there is no service account

If you have built Salesforce integrations before, your instinct is to create an integration user, give it a certificate, and let the system act as itself. That instinct does not work here, on purpose.

Salesforce is explicit: “There’s no option to specify a service account with a principal user… This is an anti-pattern that customers should avoid,” and “at this time, there’s no plan to allow machine-to-machine flows. The human remains in the loop.”

Read that as a design position, not a gap. Every MCP write is attributable to a named person, which is exactly what you want when an agent is touching pipeline data. But it also means the hosted MCP servers are built for a person working with an assistant, not for unattended automation. If your plan was “the agent runs at 2 a.m. and reconciles records,” this is not the tool for that plan.

What write access does not get you

Here is the ceiling, and it is the reason the original question is the wrong one.

The SObject servers write records — rows of data, subject to your sharing model. Nothing in Salesforce’s hosted MCP reference documents deploying metadata, Apex, or configuration changes to an org. The Headless 360 server reaches further into Setup through its Discover, Describe, and Dispatch tools, but it is labeled Beta and is a different thing from a deploy pipeline.

So an agent with full SObject write access can update ten thousand opportunity records. It cannot create the field those records need. It can populate your custom object. It cannot build your custom object. It can fix the data. It cannot fix the thing that keeps producing bad data.

That distinction is not a knock on the Salesforce MCP — it is doing precisely what it says. It is a knock on the assumption that “AI can write to Salesforce” and “AI can develop in Salesforce” are the same sentence. They are two different capabilities with two different setups, and only one of them is solved by an External Client App.

Where the ceiling shows up in practice

You will meet it faster than you think, because record work and org work are tangled in every real request.

Ask an agent to clean up duplicate accounts and it can merge records all day — until the cleanup needs a matching rule that doesn’t exist yet. Ask it to route leads and it can reassign owners — until the routing logic needs to live somewhere other than a chat session. Ask it to fix a stalled process and it will patch the symptom beautifully, one record at a time, forever, because the standard tooling stops exactly where the interesting problems start.

The pattern repeats across every one of these: the routing rule you actually need is a nested set of exceptions, and no amount of record-level write access builds it. At some point somebody has to deploy something.

What the other half of the setup looks like

The second capability — an AI that changes how the org works, not just what is in it — needs a different set of pieces: somewhere persistent for the AI to run, credentials it can use for Metadata API deploys, a sandbox-first path so changes are tested before they hit production, and a record of what was changed and a way back if it was wrong.

That is what Sentinel is: a dedicated environment per client where your AI connects over MCP and can actually develop against the org — read data, write code, deploy through a sandbox-first pipeline — with every action logged and snapshots taken before deploys. Not because the AI is prevented from making mistakes; it isn’t, and nothing honest claims otherwise. Because the mistakes are visible and the changes are recoverable, which is the property that lets you move quickly on purpose.

If you have already done the External Client App work above, none of it is wasted — connecting your AI to the org for read and record access is the same first mile, and plenty of teams should stop there and be happy. This matters when the backlog stops being data problems and starts being “Salesforce can’t do that” problems, which is the same fork you hit when you evaluate an agent that lives inside the CRM.

The takeaway

Turn on the narrowest server that does your job — almost always Mutations, not All. Let permission sets carry the security, not OAuth scopes. Test on reads, then verify Last Modified By on your first write. And go in knowing what you are buying: the Salesforce MCP gives your AI hands for your data, per-user and fully attributed, which is a real and useful thing.

Just don’t confuse it for hands on your org. Those are separate builds, and the second one is where the backlog actually lives.

Want to see what your AI could build in your Salesforce org — not just what it could update? Pricing is flat per Sentinel and is covered on a short demo call.

Book a Demo Call

Sources: Salesforce Developers, Standard Servers reference, Set Up Your Org, and How to Secure Salesforce Hosted MCP Servers (June 30, 2026). ORG Endgame is not affiliated with Salesforce or Anthropic.