Salesforce in Claude runs on your existing permissions. Audit them before you turn it on.

Salesforce’s September 15 AIforce announcement tells customers something CRM vendors rarely say: “With AIforce, people don’t have to come to Salesforce to get work done. Salesforce comes to them – in Claude, Slack, Lightning, or wherever they want to work.”

One piece of it, Salesforce in Claude, is “a prebuilt MCP server directly inside Claude,” and Salesforce said it was “now available to all customers in beta.” Slackforce brings the same data into Slack conversations. Clari + Salesloft is heading the same way: it says its spring 2026 platform integration “introduced a Model Context Protocol (MCP) server to open live revenue intelligence to any AI tool.”

Our take

We think this moves the RevOps job from screens to permissions. Page layouts, list views, and adoption dashboards are built for people who open the app, and they matter less when the rep works in a chat window you don’t configure. What matters more is what each person can see and what gets written back.

The agent sees what the user can see

Salesforce’s answer to the obvious security question is that “every request runs on existing permissions and business rules, every agent sees only what the person asking can see, and every action routes back through Salesforce.” That’s the right design, and it means the agent inherits every grant your users already have, including the ones nobody remembers making.

Say a rep picked up “View All” on accounts during an old territory project. In Lightning they’d rarely notice, because their usual views show their own book. In Claude, a question like “which accounts in Germany look at risk?” draws on everything they can see. The rep had that access all along. Chat puts it one question away.

Logins stop measuring adoption

If reps don’t have to come to Salesforce, login counts and page-view dashboards will undercount anyone who works from Claude or Slack. Count record changes by user instead, such as opportunity updates and logged next steps. Before rollout, check whether field history shows which app made an edit. If it doesn’t, ask your account team how to tell chat edits from Lightning edits.

What to do before you turn it on

• Review permissions for the pilot group first: profiles, permission sets, sharing rules, and any “View All” or “Modify All” grants.
• List the fields that should never show up in a chat answer, such as compensation or HR cases, and confirm field-level security covers them, since the agent follows the same rules your users do.
• Build a record-change adoption report now, so you have a baseline from before the pilot.
• Ask how it will be billed. The announcement says only that “pricing and packaging are subject to change.” If you’re already choosing among Agentforce’s three meters, find out which one, if any, covers work done in Claude.

What would change our mind

We’d worry less about permissions if Salesforce added an agent-specific access layer, so an admin could give Claude narrower access than the user has. We’d drop the adoption point if beta customers report that most chat use is read-only lookups and reps still make their updates in Lightning.

Salesforce’s own numbers point the other way, too. It says “one hundred thousand users activated Coworker within its first 35 days,” and Coworker is an assistant “right in the Lightning interface.” If reps keep choosing the in-app assistant, the screens matter more than we’re giving them credit for.

If you’re in the Salesforce in Claude beta, what did your permissions review turn up? Are reps updating records from chat, or only reading them?