AIforce Moves Salesforce Into Claude and Slack—but Permissions Still Follow the User

Salesforce unveiled AIforce during the opening Dreamforce keynote in San Francisco on September 15, 2026. TechRadar’s on-site account of the keynote places AIforce alongside Agentforce, Customer 360 and Data 360 in the company’s new architecture for AI-driven work.

AIforce is not another foundation model. It is an interface and governance layer that connects external AI work surfaces to Salesforce data, workflows, business logic and controls. The September 16 product announcement names Claudeforce, Slackforce and Agentforce Coworker as its initial surfaces, states that requests use existing permissions and business rules, and lists 37 prebuilt sales skills for Salesforce in Claude.

AIforce separates the interface from the system of record

The change is primarily about where a Salesforce interaction begins. A user can ask for information or initiate supported work in Claude, Slack or Salesforce’s Lightning environment, while Salesforce supplies the governed business context and executes Salesforce actions.

That makes AIforce connective infrastructure rather than a model competing with Claude. Computer Weekly’s account of the pre-Dreamforce briefing describes the product as three front ends backed by packaged skills, MCP servers, authentication and zero-data-retention settings.

The authorization boundary remains attached to the requesting identity. Claude or Slack may become the visible interface, but they do not replace Salesforce as the system that evaluates access to Salesforce records and applies its rules to actions. An agent is intended to see only what the authenticated user can see, with resulting operations routed through Salesforce.

The request path returns to Salesforce controls

The published architecture supports a high-level request path, although it does not establish one identical protocol sequence for every surface:

1. The user starts a supported request in Claude, Slack or Agentforce Coworker in Lightning.
2. The surface connects through AIforce components such as MCP servers, APIs, plug-ins or skills in the Headless Toolkit.
3. Salesforce provides the records, metadata, semantics, workflows and business logic available to that identity and request.
4. The model or agent reasons over the supplied context and selects a supported operation.
5. Salesforce applies existing permissions and business rules before completing a Salesforce action.
6. The result returns to the interface where the request began.

This path matters because the model is not presented as the final authority for a CRM action. Authentication and access rules remain Salesforce concerns even when the conversation occurs elsewhere. The available details do not establish that every surface uses the same transport, session model or execution mechanism.

The three surfaces have different roles and release states

Claudeforce puts Salesforce capabilities inside Claude through a prebuilt MCP server and packaged sales skills. Salesforce in Claude is in beta for customers following earlier pilots. Tableau analytics and additional skills for service, marketing, commerce and industry use cases are described as future additions rather than current beta capabilities.

Slackforce brings Salesforce context and governed actions into Slack. Slackforce Surfaces can assemble interactive views from relevant live context, while Slackbot and Slack CRM can support tasks such as creating an account, recording notes or updating a record without opening a separate CRM interface.

Agentforce Coworker is the Salesforce-native option inside Lightning. It can reason across account activity and history, take supported actions and call specialized Agentforce agents already deployed by a customer. Its placement inside Salesforce makes the inherited permissions model more direct, but availability can still vary by region and customer agreement.

Existing permissions govern access, not permission quality

Reusing the current authorization model avoids creating a separate set of access rules for every AI interface. It does not prove that an organization’s existing roles, permission sets, field access and sharing rules are appropriately narrow. If a user already has excessive access, AIforce inherits that exposure instead of correcting it.

The interface can also make legitimate access more consequential. An agent that assembles information across many records may compress work that previously required repeated navigation. That is not a permissions bypass, but it can increase the practical impact of an overbroad entitlement.

The stated Zero Data Retention design means business data used to answer a request is not retained by the model provider. It does not mean that no data is transmitted for processing, and “no migration” does not mean that information never moves temporarily between connected components.

The remaining gap is operational evidence for administrators. The available product details do not specify a single audit view that reconstructs the initiating prompt, identity, context retrieval, model processing and resulting Salesforce transaction across Claude, Slack and Lightning. Licensing, regional availability, cross-interface logs and component-level data handling therefore remain matters for detailed documentation and customer agreements as the initial surfaces roll out and further integrations are added.

Also read:

• Claudeforce Puts 37 Sales Skills in Claude—but Access Starts as a Pilot
• Gemini Legal Enters Preview—but Matter Permissions Still Set the Boundary
• OpenAI’s Agents API Moves Orchestration Into One Call—but It Is Still Beta