The read path is the half Salesforce has already solved

The Claudeforce announcement Salesforce and Anthropic published on August 27, 2026 describes two directions of traffic, and only one of them is hard. Salesforce in Claude, the plugin shipping with 37 prebuilt sales skills, reads a seller's context from Salesforce, Slack, and connectors, and the release says an admin connects it once with authentication and permissions managed centrally. Salesforce says the layer it calls AIforce exposes that data through MCP servers, APIs, and CLI tools. That is the read path, and the confidence is earned.

The other direction is the write path. The same release says Salesforce in Claude routes actions through Salesforce so that business rules are enforced whenever an action is taken, and it names automating pipeline updates as one use. The release tells both stories with the same confidence, and we would not. Connecting data is a plumbing job that MCP has made cheap. Governing actions is a design job, and the source announcement leaves most of it to you.

A read has no downstream

When a seller asks Claude for a pipeline review and the plugin pulls opportunities, activities, and Slack threads, nothing in the org changes. No trigger fires. No flow starts. No integration user pushes a record to the quoting system. The controls that decide what the seller can see already exist as sharing rules and field-level security, and the worst case on the read path is a person seeing a field they should not, which every Salesforce admin already has a process for.

This is why an MCP connection feels finished on the day it is switched on. The identity questions still matter, and the permission boundary in an agent connection deserves its own review, but the blast radius of a bad read is contained by design.

A write wakes up everything you built

Now the seller says, move this opportunity to Negotiation, push the close date to November, and update the amount. The plugin routes the write through Salesforce, as the release describes, and the org does what it always does with a write. A validation rule checks that Next Step is populated. A record-triggered flow notices the stage change and posts to the deal desk channel. An outbound integration sends the new amount to the ERP quote object.

Every one of those automations assumed a person filled in a form, read the error, and decided what to do. The release does not say what the plugin does when the validation rule rejects the write, whether it reports the failure to the seller, tries a different value, or drops the field and saves the rest. It also does not say how a request that fans out to twenty opportunities behaves when the eleventh one fails.

Business rules enforced is a narrower promise than it sounds

Enforcing business rules on a write means the write cannot violate a validation rule, a required field, a sharing setting, or a trigger that throws. It is a check on the shape of the data and never on the intent behind it. A validation rule cannot tell that the seller meant Q4 of next year. The rules pass, the record saves, and the flow downstream sends the wrong number to finance with a perfectly valid audit entry.

So governing actions means deciding things the platform cannot decide for you. Which of the 37 skills may write at all. Which objects each writing skill may touch, and whether a stage move and an amount change belong under the same permission. In whose name the write lands, since a record stamped Last Modified By the seller hides that a sentence in Claude produced it. Whether the audit trail keeps that sentence, so the deal desk can answer why the amount changed.

Treat the write skills as an integration, because they are one

Your org already has a way of onboarding a system that writes to Opportunity. It gets an integration user, a permission set that names its objects and fields, and a runbook for rejected records. The case for small integration contracts argues for starting narrow and widening on evidence, and a writing skill in Claude deserves that intake.

The extra piece an agent needs is a stop. The sales manager who spots a wrong forecast needs a switch that turns the write path off without turning the read path off. We have argued that agents need a pause button, and Claudeforce is the clearest case for it yet, because the plugin's value sits in the reads while its risk sits in the writes. Separating those two switches is the decision we would insist on before the trust boundary meets real deals.

What to do before the September beta

Salesforce says the plugin is with select pilot customers now and expects an open beta in September 2026. Spend the weeks before it on the write path. Sort the 37 skills into the ones that read and the ones that write. For each writing skill, list every validation rule, flow, trigger, and outbound integration on the objects it touches, and decide which of those should run when the actor is a sentence typed into Claude. Write the identity, object scope, and audit format down where the security review can find them.

Then run one test the release does not describe. In a sandbox, add a validation rule on Opportunity that rejects any close date more than ninety days out, ask the plugin to push a close date to next spring, and watch what the seller sees and what the record shows. That one test tells you more about governing actions than anything in the announcement.