What changed between August and Dreamforce

Salesforce put a number on Claudeforce at Dreamforce 2026, 37 prebuilt sales skills, all running through an MCP server inside Claude. That's the detail in Salesforce Ben's coverage of the September 15 keynote, delivered alongside a parallel push called Slackforce that runs CRM actions from inside Slack itself, both folded into a bigger reveal called AIforce.

Back in August, Claudeforce showed up as an MCP server bolted onto Claude that could reach into Salesforce data, described in broad strokes with no fixed count of what it could actually do. That was the preview this site covered in August, and the honest read on it then was that Salesforce had shipped a connection more than a finished product.

Branding aside, Claudeforce went from one integration with an unclear scope to 37 named skills in about a month, and each of those 37 is something an admin now has to individually decide whether to trust with production data.

Every one of the 37 is a new way into CRM data

Salesforce Ben's reporting doesn't say what any of the 37 skills actually do. It gives the count and the fact that they're sales skills delivered through an MCP server in Claude, nothing more specific than that. That means the only thing an admin can evaluate right now is the exposure that comes with all 37 existing at once, not the content of any single skill.

Whatever a given skill is scoped to do, drafting something or updating something, it needs a way to read or write against a Salesforce object to do it. Multiply that by 37 and you get a new way into CRM data that didn't exist in the August preview, a set of entry points a security review never had to account for when this was a single unnamed integration.

The connected app scope question every admin should ask first

In Salesforce, any external tool that reaches CRM data does it through a connected app carrying an OAuth scope. The question that matters here is what that scope actually grants, a narrow read against a single object or a broad grant that covers everything sales touches, not whether Claude can technically call into the org at all. That's where the real permission boundary sits, and it's a setting an admin can actually go look at rather than take on faith.

If Salesforce ships one connected app authorization covering all 37 skills, turning on a single skill for a pilot team quietly grants the scope behind all 37, whether the org plans to use the rest or not. That's a decision to make on purpose, in a sandbox, before the first skill goes anywhere near a production org, not something to discover during next year's access review.

Object and field level security does not care who is asking

Whatever a skill is built to do inside Claude, once its request lands in Salesforce it should run through the same security a request from the standard UI runs through, the same profile and permission set, plus whatever sharing rules already sit on the object it's touching. That's the vendor's claim built into the product story. It isn't something an admin can see from outside the org.

The way to test it is to build a user with a deliberately narrow permission set, missing edit access on a field the skill is supposed to touch, then run the skill in that user's context and watch what happens. If the skill writes to a field that user's profile blocks in the standard interface, permissions aren't enforced the way the keynote implied, no matter what the keynote said.

The audit gap nobody at Dreamforce mentioned

The harder question shows up after the fact. Whether an admin can find out that one of the 37 skills wrote to an opportunity record last week depends entirely on what the event log actually captures. Salesforce's login and API event monitoring generally records the connected app or the user context behind a change, not necessarily which of the 37 named skills triggered it.

If every Claudeforce call surfaces as the same connected app in those logs, an admin has proof that Claudeforce touched a record, not proof of which skill did it or why. The same audit question came up with ServiceNow's governed MCP actions, and it's the kind of gap that runtime policy logging built for exactly this problem is supposed to close, if an org has it turned on before the skills do.

What to check before turning one on

Before flipping on any of the 37, pull the connected app's OAuth scope first and confirm whether it's shared across every skill or specific to the one being tested. Build a narrow test user, run the skill against that user's permission set, and confirm object level and field level security actually block what they're supposed to block.

Then check the event log before the pilot starts, not after, and confirm it records enough detail to tell one skill's activity apart from another's. If it can't, that's a gap to raise before the sales team asks why a rollout that let one skill through can't be turned back off cleanly, and it's the one part of this launch a keynote demo will never show.