Before giving Claude access to Salesforce, establish whether the connection can change CRM records. The September 15, 2026 beta launch brings Salesforce data and sales workflows into Claude, but the vendors' current documentation gives different answers about write access. That changes what a security team needs to approve.
Start with a small group of ordinary sales users and a read-only scope. Check their existing access before connecting and define where retrieved CRM data may go. Add write actions only after confirming that your organization's integration supports them and exposes enough detail for a reviewer to approve the change.
This is a documentation-based rollout guide. The pilot cases below are recommendations, not results from a General Analysis test of the beta.
Resolve the beta documentation conflict first#
The following differences were present when we checked the documentation on September 16, 2026:
| Requirement | Anthropic's admin and user guides | Salesforce's Winter '27 release note |
|---|---|---|
| CRM writes | Describes proposed updates with user approval by default. | Describes read-only access; records cannot be created, updated, or deleted. |
| Claude plan | Lists all paid plans. | Requires Claude Enterprise. |
| Salesforce edition | Requires access to the latest Sales Cloud enterprise edition. | Lists several editions, including Enterprise and Developer. |
| Beta onboarding | Requires Salesforce acceptance through beta sign-up. | Says customers activate directly without additional approval. |
Sources: Anthropic admin guide, Anthropic user guide, and Salesforce release 264, which dates the rollout to September 15. The release note's onboarding approval refers to joining the beta, not approval of individual CRM actions.
These pages do not explain the discrepancy. Confirm eligibility and onboarding with the vendors for your organization, then record the exact connector, server, and available operations in an approved test environment. Do not enable writes based on the launch description alone. If your connection is read-only, keep the update examples below outside the pilot; use them only if write support is confirmed and separately approved.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Choose the connection you intend to approve#
Anthropic's packaged-plugin instructions and Salesforce's custom-connector instructions describe separate setup paths. Follow the instructions confirmed for your deployment rather than combining their settings:
| Connection | Documented setup | Decision for the administrator |
|---|---|---|
| Salesforce in Claude sales plugin | A Salesforce admin completes beta onboarding. A Claude Primary Owner or Owner selects group installation preferences and configures Salesforce (Beta) with the External Client App's client ID and secret. Members sign in individually. | Approve the packaged skills and bundled connectors for a defined group. |
| Custom connection to a hosted Salesforce MCP server | Add a custom connector with a chosen server URL and your OAuth client ID. Salesforce's Claude guide says to leave the secret blank unless the authorization server requires it. | Choose the server and tool scope for a separate integration. |
Sources: plugin administration and Salesforce's custom Claude connector instructions.
Do not copy the custom connector's secret setting into the packaged plugin setup. Transfer credentials through your approved secret-handling process; keep secret values out of tickets, screenshots, and the pilot record.
Group distribution determines who receives the plugin. Review the connected Salesforce account separately. A narrow pilot group can still contain a user with extensive administrative access.
Review the action behind the tool name#
Record which server the connection uses and inspect how its tools map to business actions. Salesforce's Headless 360 reference gives a concrete reason to look beyond the tool list: four tools expose a library of operations that grows independently.
discover finds candidate operations. describe supplies an operation's contract, including its parameters and steps. dispatch executes the selected operation; dispatch_readonly executes in read-only mode. These are server capabilities, not a promise that every beta account or plugin workflow exposes the same operations.
For a confirmed write-capable connection, consider a hypothetical request to move an opportunity's close date. Inspect the target organization and record, the proposed date, and any additional steps before approving. An approval that displays only dispatch gives the reviewer too little information to judge the business effect. For a read-only connection, review the records and fields a retrieval can expose instead.
For the write example, require the reviewer to identify the affected record and the proposed change. If the client cannot expose enough detail, keep that action out of the pilot or use a separately reviewed workflow. Do not treat an opaque confirmation as evidence of informed approval.
Revisit the approval when operations or skills change, even if the outer tool list stays the same. The broader MCP security threat model explains why installation review needs follow-up at runtime.
Put the access boundary in Salesforce#
Salesforce's security guidance says hosted MCP calls inherit the authenticated user's object access, field-level security, and record sharing. It also describes External Client App restrictions through profiles and permission sets.
For the pilot, choose an identity whose permissions match the sales task. Avoid using an administrator just to make authentication troubleshooting easier. Otherwise, a successful pilot may say more about that administrator's broad access than about the configuration ordinary users will receive.
If the requirement is strictly to retrieve records, Salesforce documents platform/sobject-reads as a read-only hosted server. That is an option for a separate custom integration. The plugin setup guide does not document replacing its connection with that server while preserving the packaged sales skills.
Tool metadata does not settle this choice. Salesforce's general MCP guidance explicitly treats annotations such as readOnlyHint as hints rather than enforcement. Check the server, operation, and user authority instead of accepting a read-only label as the control.
Also review where retrieved data can go. The launch includes Slack alongside Salesforce. A CRM permission review alone does not approve every destination a later workflow might use. For a deal-summary pilot, name the permitted output destination and exclude external sends unless separately authorized.
Keep an acceptance record that can survive an investigation#
Give the administrator and business owner a short set of cases with expected outcomes. Use authorized test identities and non-sensitive sample records in an approved test environment. These are ordinary access and workflow checks; they do not require exploit payloads.
- Read an allowed sample opportunity and confirm the returned fields match the intended role.
- Request a sample field or record outside that role and confirm the access restriction holds.
- Where writes are available, propose one harmless field change. Decline it first and check the record; then run a separately approved case and compare the final value with the proposal.
- Attempt the connection with a test user excluded from the configured access scope and record which control rejects it.
Keep the expected outcome separate from the observed result. The example below applies only to a separately approved, confirmed write-capable connection. For a read-only pilot, record the requested retrieval and expected field restrictions instead. This illustrative JSON is a review record, not a vendor API payload or a configuration to paste into Claude.
Code source: illustrative.
{
"case_id": "crm-pilot-01",
"connection": "salesforce-in-claude-plugin",
"environment": "approved-test-org",
"salesforce_user": "pilot-sales-user",
"requested_change": {
"record": "sample-opportunity",
"field": "CloseDate",
"proposed_value": "2026-10-30"
},
"approval_decision": "deny",
"expected_result": "record-unchanged",
"observed_result": "unverified",
"evidence_references": []
}
Add the actual operation identifier, timestamps, and evidence references when you run the case. Do not invent a successful result from a conversational response saying the work is complete.
Salesforce documents identifying hosted MCP traffic in API logs with API_CLIENT_CATEGORY = SALESFORCE_HOSTED_MCP. Its monitoring guidance describes user attribution, operations, objects, and timestamps. Confirm what your organization's log access exposes before depending on it for the pilot.
Use that downstream evidence to check the effect. Keep the approval decision with it: attribution to a Salesforce user does not establish that the user reviewed a particular proposed change. For Claude-side records, use the Compliance API coverage guide to determine which supported conversations or sessions your organization can retrieve. Do not assume the two products supply an automatic common correlation ID.
Approve the rollout for the identities, actions, and output destinations covered by the pilot. If a reviewer cannot see what an action will change, or an investigator cannot reconcile its result, assign an owner to that gap before adding the action to the approved scope.
Frequently asked questions
- Is Salesforce in Claude read-only during the beta?
The vendor documentation disagrees. On September 16, 2026, Salesforce's Winter '27 release note described a read-only beta, while Anthropic's user guide described approved CRM updates. Verify the actual connector and capabilities enabled for your organization. Keep the pilot read-only until write support and approval behavior are confirmed.
- Does Salesforce in Claude get more access than the connected user?
Anthropic says the plugin uses each member's Salesforce account. Salesforce's hosted MCP documentation says object permissions, field-level security, and record sharing apply. Review those permissions before connecting: a user with broad access gives the agent broad authority within that account.
- Can I make the Salesforce sales plugin read-only by changing its MCP server?
The opened setup documentation does not establish that substitution. Salesforce offers a separate read-only hosted server, platform/sobject-reads, for custom MCP connections. Evaluate that route separately and do not assume it preserves the packaged plugin's skills.
- Does a Salesforce API log prove that a person approved an agent action?
No. User attribution identifies the Salesforce identity used for the operation. Retain the approval decision and the proposed target and changes separately, then compare them with the downstream result.

