Claudeforce runs in two directions, and only one keeps the record inside Salesforce

What was actually announced

Salesforce and Anthropic called it Claudeforce, and the press release describes it as bringing Claude's reasoning together with Salesforce's "trusted enterprise harness" — its data, workflows, business logic, actions and governance. Underneath that framing are two distinct shipments moving in opposite directions.

The coverage largely read this as a model-selection story — a bellwether for whether enterprise software stays model-agnostic, with Salesforce naming a default rather than a menu. That is a real question and it is the less interesting one. Defaults in enterprise suites have always been sticky, Agent Builder still lets an admin pick something else, and the model behind a CRM's reasoning engine is a swap you can plausibly make later. What you cannot swap later is where the record of a decision ended up.

The same partnership, two boundaries

Claude in Agentforce: the model comes to the data

In this direction the agent's actions are Salesforce actions. They execute in a running user's context, which means the platform's sharing model, field-level security and object permissions apply to each one without anybody re-implementing them. The tool catalogue is the org's own actions and flows. Inference runs through Bedrock inside what Salesforce calls its Trust Boundary, which is the specific claim that lets regulated customers say the data did not leave. And the artefacts a compliance team wants — what changed, by whom, under whose permissions — are produced by machinery that predates agents by a decade.

The cost is autonomy of a different kind: you are inside somebody's platform, on their action model, with their default reasoning engine. That is a normal trade and most enterprises have already made it.

Salesforce in Claude: the data comes to the session

The plugin direction is the more interesting one precisely because it is being sold as a convenience. The user works in Claude. The transcript is in Claude. The uploaded spreadsheet, the half-finished proposal, the other connectors that same user has enabled — all in Claude. The plugin fetches live CRM context, the model reasons over it, and a governed action writes back.

Notice what changed and what did not. The write is still a Salesforce write, still permissioned, still logged: that half is genuinely solved. What moved is the deliberation — the retrieved context, the alternatives considered, the instruction the user actually gave — and it moved into a workspace whose retention, export and legal-hold story is a different vendor's.

The auditable half and the missing join

Field history tells you that the discount on an opportunity went from 5% to 22% and that it was the integration user who did it. It does not tell you that the agent had read a competitor's quote pasted into the chat, weighed a renewal risk the rep mentioned in passing, and proposed the number. In the Agentforce direction that context is at least recoverable from the same tenant. In the plugin direction it is in a conversation that may be edited, may be deleted, and is subject to whatever the user's own workspace policy says.

This matters in three concrete places, none of them hypothetical for a company of any size:

• Discovery and legal hold. If a decision is disputed, the reasoning is discoverable material. A hold that covers the CRM does not cover a session in a different product unless somebody scoped it there.
• Regulated justification. Wherever a decision needs a reason on file — pricing that must be non-discriminatory, an approval with a threshold, anything touching a supervised process — "the record shows the change but not the basis" is a finding waiting to be written.
• Incident reconstruction. When a bad write is discovered three weeks later, the useful question is what the agent believed. That is the reasoning, and the repair work is much harder without it.

The fix is unglamorous and worth budgeting for: make the agent write its own rationale back as a record on the object it touched. A one-paragraph justification with the ids of what it read, stored in the CRM at write time, closes the gap in both directions and costs a field.

What the plugin's scope is, and why it is coarser than it looks

A connected app's OAuth scope is granted once and sized for everything the app might do. Bundle 37 skills behind one plugin and the scope has to be the union of what any of them needs — pipeline reads, record updates, probably contacts and activities. A single conversation that only wanted to summarise one account is running with all of it. That is not a flaw specific to this plugin; it is the shape of every connector-style integration, and it is the practical reason a per-action permission model is worth something.

The second-order version is the one that produces incidents. A CRM is full of text that other people wrote — inbound emails, case descriptions, notes from a form on your website. Pull that text into a general assistant that also holds the user's mailbox, their files and three other connectors, and you have assembled the classic confused-deputy setup: attacker-authored content on one side, the user's full authority on the other, and a model in between deciding what to do. Inside Agentforce, a successful injection buys an attacker a Salesforce action under a sharing model. Inside a general workspace, it buys whatever the user's other connectors reach. This is the whole argument of ambient authority, arriving as a product decision rather than a security review.

What to do before the beta lands

The September beta is a reasonable thing to want. Four things make it survivable:

• Decide, per workflow, which direction it belongs in. Work whose record has to be complete — pricing, approvals, anything a regulator or a court might read — goes in the direction where the deliberation stays in the tenant. Exploratory work, drafting and analysis are fine in the other one.
• Write the rationale back. Whichever direction, a machine-written justification stored on the record at write time is the single cheapest control here, and the only one that survives a change of vendor.
• Scope the connected app like a service account, not like a user. Ask what the plugin's OAuth scope actually grants, and whether it can be split. If the answer is one scope for all 37 skills, that is your blast radius; treat sensitive objects as out of scope rather than assuming per-conversation restraint.
• Extend retention and legal hold to the new surface before you enable it, not after the first request arrives. If that is not possible, that fact is itself the decision for regulated workflows.

And keep the model-agnosticism question in proportion. A default reasoning engine is a commercial fact worth negotiating, but it is reversible in a way that a two-year archive of decisions with no recorded basis is not.

Further reading

On this wiki:

• Ambient authority — why a connector's unenumerated reach, not the model, turns an injection into an escalation.
• Agent identity & permissions — running-user context versus service-account scope.
• Audit trails & provenance — what a decision record has to contain to be usable later.
• Delegated access & consent records — the paperwork behind an agent acting for a person.
• Agent connector platforms — the category this plugin belongs to.

Sources:

• Salesforce and Anthropic Announce Claudeforce — the announcement.
• Salesforce investor relations release
• CNBC coverage — the commercial framing.