Straight answer: AIforce turns your org into something an outside AI client can call, and Claudeforce is the first client to do it. The technology underneath is an MCP server plus your existing APIs. The important consequence has nothing to do with AI: every permission you never got around to tightening becomes reachable from a tool that will actually use it, by a user who previously had no practical way to exercise it.
What is actually shipping
Three separate things carry the branding, and conflating them is the main source of confusion this week.
| Component | What it does | Status |
|---|---|---|
| Salesforce in Claude | Plugin with a prebuilt MCP server and 37 sales skills — meeting prep, deal health, pipeline review | Select pilots; open beta quoted September 2026 |
| Salesforce Development plug-in for Claude Code | 40+ skills aimed at building on the platform rather than selling with it | Announced |
| Claude inside Salesforce | Claude as a reasoning model for the Atlas Reasoning Engine; default behind Agentforce Vibes and Coworker; selectable in Agent Builder | Shipping |
Only the third is Salesforce-to-model. The first two are the reverse direction, and that reversal is the architectural news. The Claudeforce announcement also states that Claude is the first LLM provider fully inside the Salesforce Trust Boundary, running via Amazon Bedrock.
The mechanism, plainly
MCP is a published open standard for describing tools to a model: what a tool is called, what arguments it takes, what it returns. The client discovers the tools, decides which to call, and the server executes. It is closer to a typed API catalogue than to anything AI-specific — the AI part is only that the caller chooses.
Salesforce’s version wraps your org’s capabilities as tools and layers “skills” on top — prepackaged multi-step sequences, so “prep me for this meeting” becomes a defined series of calls rather than the model improvising against raw objects. It groups this under the Headless Toolkit: MCP servers, APIs, plug-ins and CLI tools.
Crucially, actions route back through Salesforce, so validation rules, required fields and business logic still apply. An outside client cannot write a record your org would have rejected. That is the right design, and it is worth confirming rather than assuming when you get access.
The security model is the entire story
Salesforce’s claim is that requests run under the calling user’s existing permissions and sharing, and that model providers operate under zero data retention — the data answers the question and is not kept.
Take that claim at face value for a moment, because even if it is perfectly true, it changes your exposure. Consider a sales manager with a profile that grants View All on Opportunity because someone needed a report in 2019. Today that permission is theoretical: they see what the Lightning UI shows them, a few hundred records at a time, and nobody has ever exercised the grant. Connect an AI client with that user’s permissions and “summarise every open opportunity in the region” is one sentence away from being real.
Nothing was breached. The permission was always there. What changed is that the gap between what a user may access and what they practically can access just closed, and that gap has been quietly absorbing permission debt in most orgs for a decade.
This is why the useful preparation is not an AI review. It is the ordinary, boring exercise of finding out who holds View All, Modify All, Export Reports and API Enabled, and whether any of it is still justified — the object permissions versus record access distinction, audited for real. The permissions review for Agentforce applies unchanged, with one addition: assume the caller is no longer a human clicking.
Three things nobody mentioned on stage
Attribution in the audit trail. When a record changes, you will want to know whether a person did it in Lightning or a model did it from Claude on that person’s behalf. Both are the same user. Ask how those are distinguished in Event Monitoring and Field History before this goes near a regulated process. If they are not, your approval workflows mean less than they did.
Read volume against API limits. A model exploring a question issues far more queries than a person answering it. Your daily API allocation is finite and shared, and the first symptom of a popular plugin is not a security incident. It is an integration failing at 4pm because the allocation is gone. Get API limit monitoring in place before the pilot, not after.
The skills are sales-shaped. Thirty-seven prebuilt skills, described as meeting prep, deal health review, pipeline review. That is one persona. If you run a service org, a field org or a nonprofit, the first release does not have your workflows in it, and Salesforce has said further skills arrive late 2026.
Where it falls short right now
It is a beta with an unannounced price, and “pricing and packaging are subject to change” appears on every release this week. A pilot you cannot cost is a pilot you cannot get approved past a certain size, so scope accordingly.
There is a dependency question too. Routing your sellers’ daily work through a second vendor’s client means a second status page, a second incident channel and a second support relationship for something that will quickly feel load-bearing. A real operational cost, and never in the keynote.
Who should try it, and who should wait
Try it if you already have a clean permission model, a sales team that lives in a chat client, and an appetite for beta software with no SLA attached. The upside is genuine: the tedious pre-call work really is the kind of task this shape of tool does well, and 37 skills means you are not designing the prompt.
Wait if you are in a regulated industry until you have the audit-trail answer in writing. If your permission model is untidy, because you would be exporting the untidiness. Or if your users are not already working in Claude, since the entire premise is meeting people where they are and there is no benefit to moving them somewhere new to be met.
My own position: this is the most consequential thing in the whole Dreamforce announcement set, and I would not put it in front of users this quarter. Not because it is bad, because the interesting failure modes of a permission-inheriting agent take longer than a quarter to surface, and the same argument applies here as to topics and instructions. An instruction is a preference. The permission model is the constraint. This release moves more weight onto the constraint.
What I would test first
I have not had access, so this is a test plan rather than results. In order:
- Give the plugin a user with a deliberately over-broad profile and ask it for something that user should not practically be able to compile. Confirm the sharing model holds under a broad query, not just a single-record read.
- Attempt a write that violates a validation rule, and confirm it fails with the org’s error rather than being silently dropped.
- Run one realistic session and count the API calls it costs. Multiply by your seat count before anyone commits to a rollout number.
- Change a record through the plugin, then check Field History and Event Monitoring to see what the attribution actually says.
- Revoke the user’s permission mid-session and confirm the next call fails. Cached scope is where this class of integration usually goes wrong.
Frequently asked
Does this replace Agentforce? No, it inverts it. Agentforce runs agents inside your org. AIforce exposes your org to agents running outside it. Most organisations will end up doing both, for different jobs, and the limits in what Agentforce cannot do apply to the outside caller just as firmly.
Is my data used to train a model? Salesforce states zero data retention with model providers, meaning data answers the request and is not kept or trained on. Get that in your contract rather than from a press release. The same advice that applies to the Einstein Trust Layer.
Can I build my own MCP server against my org instead? Yes, and some teams already have. The APIs underneath are the ones you already use. What Salesforce is selling is the packaging, the skills and the trust-boundary story, not access that was previously impossible.
How does this deploy between sandboxes? Unclear, and worth asking early. Plugin configuration that lives outside your org is by definition not in your metadata, so it will not travel with a change set and will not appear in a diff.
Reference: the Salesforce AIforce announcement and the Salesforce–Anthropic Claudeforce press release, Salesforce newsroom, August–September 2026. Component statuses as of 17 September 2026. Salesforce in Claude was in limited pilot at the time of writing, so nothing here is hands-on tested; the test plan above is what I intend to run when beta access opens, and the security observations follow from Salesforce’s own stated permission model rather than from observed behaviour.
