Claude Code · guardrails on a live org
Is it safe to let Claude Code work in your Salesforce org?
Yes, when the guardrails sit outside the model.
It is safe when the agent can reach only the org you name, runs as a Salesforce user you would trust with a contractor’s access, and proves every change by reading it back from the org. It is not safe when it inherits a command line already signed in to several orgs, production among them, with nothing between the model and a deploy. These are the guardrails I run on my own org, and where each one stops.
Salesforce and Anthropic pages read on 31 October 2026. Reviewed 1 November 2026.
What it can reach
What can Claude Code actually do in a Salesforce org?
Whatever the Salesforce user behind it can do. Claude Code runs the Salesforce CLI on your machine, signed in as whoever logged in, so it can query, retrieve, deploy and delete with that user’s rights. Salesforce enforces those rights on every route. Which org a command reaches, and whether a deploy really worked, is left to you.
Salesforce’s own tutorial for Salesforce Skills in Claude Code, published on 9 June 2026, starts from exactly that setup: the CLI authenticated to a Developer Edition org, sandbox or scratch org. Its library holds more than 60 skills and promises test coverage of 75% or more, and it still tells you to review the output and test in a sandbox before production. There are three ways Claude reaches an org, and they are not equally bounded.
| Route | Acts as | What stands between the model and a change |
|---|---|---|
| Salesforce in Claude, the plugin | Each person’s own Salesforce user and permissions | Asks the person to approve each change before it is written; beta, Sales Cloud Enterprise |
| Hosted MCP servers, from Claude Code or Claude Desktop | The user who signs in through your External Client App | Servers are off until an admin activates them; app checks and user permissions both apply |
| Claude Code running the Salesforce CLI | Whoever ran sf org login on that machine | Salesforce asks nothing; in its default mode Claude Code asks before any shell command you have not allowed |
Sources for the table: the Claude support article Set up Salesforce in Claude for your organization, updated 25 September 2026; the Salesforce developer post Connect Claude with Salesforce Hosted MCP Servers of 26 May 2026 and the Hosted MCP setup guide for Claude, which gives production and sandbox orgs different server addresses; and Anthropic’s permissions documentation. The plugin route is the subject of the Claude and Salesforce page; this article is about the other two.
Who enforces what
What do Salesforce and Anthropic enforce, and what is left to you?
Salesforce enforces the user’s object, field and sharing permissions. Claude Code enforces its permission rules and hooks, not the model, so a line in CLAUDE.md guides Claude without binding it. Nobody enforces which org a command goes to, whether the local copy is current, or whether a green deploy changed anything. Those are yours.
The partnership announced on 26 August 2026 routes the plugin’s actions through Salesforce so that business rules apply, and ships it with 37 prebuilt sales skills. None of that reaches a command line session, which is why the guardrails below exist. The question an agent forces, which user it is and what that user may see, is the second reveal in what an agent exposes in a B2B org.
My own org, every day
Seven guardrails, in the order they act.
These run on the Developer Edition org behind this site, where the estimates from the calculators, the lead pipeline and invoicing live. The first two are code, a PreToolUse hook as Anthropic describes in its hooks reference. The rest are written rules that every session loads, each one added after a real mistake.
- 01
A hook that refuses any write to an org not on the project’s list
Claude Code runs a script before every shell command. It finds the Salesforce commands, reads the target org from the command and checks it against a short list kept in the project folder: orgs it may write to, orgs it may only read. Anything else is refused with exit code 2, and the reason goes back to Claude in plain words. In the folder of this site the write list holds one org, my own Developer Edition.
- 02
No write without a named org
A deploy without an explicit target goes to whatever the folder’s default org happens to be, so the hook refuses it. An org hidden in a variable is refused too, unless the same command declares it in a loop the hook can read. A folder with no list at all is read only for every org.
- 03
The org named on reads as well
The hook does not stop reads, and a query without a target still reads the default org. The written rule closes that: every command names the org, reads included, so an answer never quietly comes from somebody else’s data.
- 04
Retrieve before every change
I edit in Setup while Claude works on files. A deploy from a copy that is an hour old silently puts back what I changed in that hour. So the order is fixed: retrieve the components, edit the retrieved files, deploy only those files, never the whole project folder.
- 05
Permissions in the same deployment, then the overall status
A new field without field level security behaves as if it does not exist, and describe does not show it. A deployment is all or nothing: one failed component rolls back the rest, including lines that said ok. Claude reads the overall status, and when the CLI prints an error after a successful deploy, it asks the server for the job instead of deploying again.
- 06
Done means read back from the org
Succeeded proves the XML was parsed. Proof is a fresh query of the fields that should have changed and of the neighbours that should not, or metadata retrieved from the org rather than the local file. The rule exists because a local app file once showed every tab while two were missing from the user’s screen: tab visibility lives in the profile.
- 07
Nothing sent, and nothing deployed, without a yes
No email, invoice or message leaves the org unless I asked for that exact send, and test mail goes only to my own address. A general go ahead is not permission to deploy: Claude asks what exactly goes in and waits. Site changes go out only after the full regression passes.
The list the hook reads is this small. Names here are placeholders; the real file names one org and nothing else.
The honest part
Where these guardrails stop.
A guardrail you overestimate is worse than none. Four limits, each one known before it mattered.
- 01
It reads the command text
Anthropic’s own documentation says a Bash rule matches the text Claude writes and is not a security boundary around the program. The same is true of my hook: a command written in an unusual form can pass a pattern. It catches the commands Claude normally writes, which is most of the risk, not all of it.
- 02
It fails open, on purpose
Any error inside the script lets the command through, so a broken hook never stops a working day. The documentation is blunt about the cost: a crashing policy hook lets everything through. Newer versions of Claude Code can make a failed hook block instead; that is the setting to choose if the hook is your only control.
- 03
It only sees shell commands
A call through a Hosted MCP connector is not a shell command, so the hook never sees it. That route is bounded by the External Client App, the user’s permissions and, if you want none of it, a deny rule that removes every MCP tool from Claude’s reach.
- 04
It looks at the folder, not the task
A session opened in a folder whose list allows another org could write there for a task meant for mine. Code cannot know which task is meant, so a written rule covers it: my org is written to only from my own folders.
Before you say yes
Should you let an AI agent into your org at all?
Yes, if you can answer three questions in writing first: which org it may change, as which user, and who approves a deployment. If any answer is everything, the administrator, or nobody, fix that before the agent arrives. The permission review is the part people skip, and it decides what the agent can expose.
The access risks an agent inherits from an org that nobody has reviewed in years are listed in nine access risks, and an agent inherits all of them. Each one is a question to settle before the first session, not after it.
Asked often enough to answer here
Questions
- Q
Is CLAUDE.md enough to keep Claude out of production?
No. Anthropic documents that permission rules are enforced by Claude Code, not by the model, and that instructions in CLAUDE.md shape what Claude tries to do without changing what it is allowed to do. Write the rules there, and enforce the ones that matter with a hook, a deny rule and the Salesforce user.
- Q
Should Claude Code deploy to production?
Only a change that already passed in a sandbox, retrieved and verified there, and only after a person approved that exact deployment. Salesforce's own Skills tutorial says the same in its words: review the output before deploying to production, and test in a sandbox first.
- Q
Is the Salesforce in Claude plugin safer than Claude Code?
By default it carries less risk. It acts as each person's own Salesforce user, sees only what their permissions allow and asks them to approve each change. Claude Code acts as whoever signed in to the CLI, often an administrator. The plugin answers questions; Claude Code changes the org.
- Q
What is the single most important control?
The Salesforce user the agent runs as. Every guardrail above is a habit layered on that user's access. Give the agent a sandbox and a user whose profile you would hand to a contractor, and a mistake costs an afternoon instead of production data.
The middle package on the Claude and Salesforce page: the connection set up in one org, plus a written permission and field level security review per profile on every object Claude will read and write, before anyone asks it a question.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 1 November 2026.
Read next
The question that usually comes after this one.
- 01
Salesforce Permissions Audit: Fixed €650
Nine access risks a Salesforce permissions audit finds and why agents inherit them all. Check them yourself, or one fixed day at €650 against your exports.
- 02
What Agentforce Exposes in an Existing Org
An agent answers from what is in the org. Seven things it makes visible, each one a question the org has to answer before deployment rather than after.
- 03
Case: Residential developer, shared org
Another business's sales team could open the developer's deals and payments. A count found it; the access model was closed in dependency order.