Governing Claude Code on a Salesforce Org

It’s an easy question to defer. Claude Code runs in a developer’s terminal with the same permissions as the developer who invoked it, so on day one it inherits whatever access that person already has. If that developer is a system administrator, the agent is effectively a system administrator too. Nothing about that is obviously wrong until the day an agent, working from a misread instruction or a poisoned file in a cloned repo, does something at machine speed that a developer would have caught. 

The good news for Salesforce teams is that this is not a new discipline. Salesforce has spent fifteen years building controls for precisely this problem: how to let something that isn’t a full-time employee, a system integration, a contractor or a managed package, operate inside a customer org without handing it the keys. 

Governing an AI agent is mostly a matter of pointing those existing controls at a new kind of user, and pairing them with the enterprise controls Anthropic has built on the Claude Code side. What makes Claude Code well suited to Salesforce work is not just that it’s capable, it’s that it was built with these controls as features, so the platform’s governance model and the agent’s governance model line up rather than fight each other. 

Before working through the controls, it helps to be concrete about what is actually being decided. Six questions broadly cover it, and a team that can answer all six has a governance model whether or not it calls it one:

1. Whose identity does the agent act under?
2. What data can it see?
3. What can it change, and in which environment?
4. Can you prove afterwards what it did?
5. How far can it go before a person is involved?
6. What can it reach beyond the org?

Each section below takes one of those questions and pairs the Salesforce control that answers it with the Claude Code control that enforces it.

It is worth naming what Claude Code actually is in enterprise terms. It is not a feature of a developer’s laptop. It is a new class of identity operating inside your systems, one that authenticates, holds privileges, takes actions and leaves a trail, exactly as a human user or a service account does. Every discipline that already governs enterprise identity therefore applies: authenticate it distinctly, authorize it narrowly, review its privileges on a schedule and be able to revoke them from one place. What follows is that identity lifecycle applied to an agent, and Salesforce already supplies most of the machinery. 

Salesforce already has the right pattern for this. When you connect any external system to an org, best practice is to give it a dedicated integration user built on the Minimum Access profile, layered up with permission sets that grant only what that specific integration needs, and nothing more. You don’t hand an integration a System Administrator profile because it’s convenient. You scope it to its job. 

Claude Code deserves the same treatment. Rather than letting it inherit a developer’s full admin rights, define what it needs for the task in front of it: read access to the objects it’s reasoning about, write access only where it’s actually generating something, and grant that through permission sets you can inspect and revoke. 

On the Claude side, this pairs with managed settings that a developer can’t override, so the scope you define holds even if someone tries to work around it locally. These are pushed centrally, through the same device-management tooling IT already uses, and they sit at the top of Claude Code’s settings hierarchy, so a local tweak or a stray command-line flag can’t loosen them. The two halves reinforce each other: Salesforce controls what the identity can do in the org, and Claude Code’s managed settings control what the agent can do on the machine. 

The payoff is the same one that least-privilege has always delivered: a smaller blast radius. If something goes wrong, whether a bad instruction or a compromised endpoint, the damage is bounded by what you scoped for Claude, not by what a developer happened to have.

This is not a reason to keep Claude Code away from sandboxes. It’s a reason to do what teams handling regulated data should already be doing: mask or anonymize sensitive fields before anyone, or anything, works against them. Salesforce Data Mask is the native tool for exactly this, replacing names, emails, and other PII with realistic but fake values while preserving the shape of the data so it’s still useful for development. Salesforce has explicitly extended this thinking to generative AI, noting that masking now matters not just for developers and testers but for the prompts and context fed to AI tools, precisely so sensitive data doesn’t leak into a model. 

Claude Code meets that control halfway. Deny rules, set once in managed settings, can stop the agent from ever reading nominated files or paths, so an export of unmasked data or a credentials file is off-limits regardless of what a prompt asks for, because these rules are enforced by the tool itself rather than requested of the model. And because Claude Code works from the explicit context you give it rather than roaming for data on its own, what it sees is largely what you chose to point it at. Masking upstream and denying sensitive paths downstream are two halves of the same guarantee: the sensitive values never reach the model in the first place. 

The practical rule is simple. If a sandbox holds unmasked production data, an agent should not be pointed at it. Mask it first, or seed the sandbox with synthetic data, and the privacy problem largely disappears before it starts. This is one of those cases where the governance step and the delivery step are the same step, done once, at the point the sandbox is created.

A great deal of what makes Claude Code valuable, understanding a codebase, drafting a plan, checking work against standards, requires only the ability to read. Reading is low-risk. Writing, deploying, and changing configuration is where the real consequences live. 

Treat those as two different grants. Read access for context-gathering can be broad and granted early. Write access, especially anything that touches production, should be narrower, deliberate and ideally gated behind a separate approval step. 

This is where Claude Code’s permission model does real work, rather than leaving the distinction to good intentions. Its permissions are expressed as allow, ask, and deny rules on specific tools and commands, evaluated deny-first, so a deny always beats an allow, and they’re enforced by Claude Code itself, not merely suggested to the model in a prompt. In practice that means you can let the agent read and draft freely while forcing anything that writes, or deploys, or touches a protected path, to stop and ask for a human’s approval, and you can make that rule stick org-wide through managed settings. The read-versus-write line stops being a convention the team hopes holds and becomes a control the tool enforces on every action. 

On the Salesforce side, this maps directly onto how you’d scope the agent’s permission sets, and onto environment strategy. An agent working in a scratch org or a masked developer sandbox can be given more latitude than one anywhere near production. The line between "help me understand and draft this" and "go make this change in the org that customers depend on" should be a line the team draws on purpose, not one that gets crossed by default because the access happened to be there.

If Claude Code operates through a shared or ambiguous identity, every change it makes is attributed to whichever developer’s credentials it borrowed, and the audit trail quietly loses its meaning at exactly the moment you need it. 

Salesforce gives you the tools to keep that trail clean. Setup Audit Trail records configuration and metadata changes at the org level: who modified a validation rule, when login policies changed. Field History Tracking and Field Audit Trail capture record-level changes with user attribution, the old value, the new value, and who made the change. The key is that these are only as useful as the identity behind the change. If the agent acts under its own scoped identity rather than a borrowed one, these native tools do exactly what they were built to do: tell you, definitively, what the agent changed and when. 

Claude Code supports the other half of this. Its enterprise tier can export audit logs of agent activity, and identity-based authentication through SSO ensures every session is tied to a specific user rather than a shared key. 

Put the two together, distinct identity in Salesforce, exported activity logs from Claude Code, and you have a defensible answer to the auditor’s question, rather than a shrug.

In "Building Salesforce with Claude Code" we described using a separate review subagent to check work, catching governor-limit risks or missing test coverage before code reaches a sandbox. That pattern is genuinely useful, and it also hides a governance decision that’s easy to make by accident. 

There’s a wide gap between three things a review agent might be allowed to do: flag issues for a human to act on, approve changes on its own, or merge them without a human in the loop. Those are three very different risk profiles wearing the same label. 

A clearer way to make that call is to treat agent autonomy as a ladder rather than an on/off switch.

1. Observe. It reads and reports, and changes nothing. Inventorying the automation on an object, or flagging governor-limit risks in code that already exists.
2. Recommend. It proposes a specific change with its reasoning, and a person decides. For example, this belongs in a Flow rather than Apex, and here is why.
3. Execute with approval. It writes the code or the configuration, but nothing moves until someone signs off the plan.
4. Execute within a boundary. It acts without per-action approval, inside limits set in advance. For example, regenerating test classes in a scratch org, never touching production.

The discipline is to name the level you are on, per project and per environment, rather than discovering it after the fact. Review work can sit on the first two indefinitely and still pay for itself. The third is where most delivery value lives, once the team has evidence the setup behaves. The fourth should stay rare, and it should be a decision someone is willing to put their name to.

Claude Code makes that choice explicit rather than implicit, which is part of why it’s a good fit for regulated Salesforce work. It runs in distinct permission modes, and the difference between them is exactly the difference between those levels. Plan mode, for instance, lets the agent read, analyze and propose, but it cannot edit, deploy or run anything that changes state, which is precisely what you want from a reviewer. Higher-autonomy modes exist for the cases that warrant them, but they’re a deliberate setting, not a default the team drifts into. You decide on the posture up front and enforce it, rather than discovering after the fact how much latitude the agent actually had.

So, make it deliberate, per project and per environment, not a default to accept. For most Salesforce work, a review agent should raise its hand, not sign the form. Reserve any greater autonomy for narrow, well-understood, low-consequence cases and revisit it as your confidence in the setup grows, rather than granting it up front because the capability exists.

The Model Context Protocol has become a well-established open standard through which Claude connects to enterprise tools. Instead of being confined to the files on a developer’s machine, the agent can reach a Git repository, a Jira backlog, a CI pipeline or a Salesforce org through a defined MCP connection, read live context from it and act on it. It is what makes the agent useful beyond the editor, and for exactly that reason it is a surface that needs governing. 

Left ungoverned, MCP connections tend to accumulate: a developer adds one to unblock a task, it’s never reviewed, and it quietly persists long after the need has passed, which is the same lifecycle that produces orphaned, over-privileged connected apps in Salesforce orgs. 

The fix is to treat a new MCP connection the way you’d treat any new connected app or integration user: as something that goes through review before it’s trusted, not something added ad hoc by whoever’s setting up the project. 

Anthropic has built the control for this: an organization can require that only MCP servers defined in managed settings are allowed to run, so developers can’t add their own unvetted connections. That turns MCP access from something that accumulates by default into something an organization approves on purpose, maintained as a vetted allowlist, the direct equivalent of the periodic connected-app access reviews a well-run Salesforce org already does.

Every control here already exists on the Salesforce side as permission sets, integration users, Data Mask and audit trails, and on the Claude Code side as managed settings, permission rules, modes, MCP allowlists, SSO and exportable logs. That alignment is the real point. Claude Code isn’t a generic agent bolted onto Salesforce; its governance model was built such that it lines up with the controls a Salesforce team already runs, which is what makes it a fit for enterprise work rather than a liability to be managed around. 

Governing an AI agent on a Salesforce org isn’t a new discipline anyone has to invent from scratch. It’s the disciplines a good delivery team already practices, pointed at a new kind of user that acts faster than the humans who used to manage the loop.