Before you pilot Claudeforce

Salesforce’s own documentation for Claudeforce’s underlying architecture, Headless 360, is direct about this: every permission your users already have is honored. Profile, permission set groups, org-wide defaults, sharing rules, field-level security, validation rules, and transaction security policies aren’t bypassed by connecting Claude.

That’s reassuring and also the actual risk. It means a permission that was harmless behind a slow, click-through UI, one nobody noticed because a human would never realistically abuse it at scale, becomes a different kind of risk behind something that can act quickly and repeatedly. The security model doesn’t change. What changes is how fast something can walk through the doors it already had.

---

Step 1: audit permissions before you connect anything

Don’t start with the connection. Start with an honest look at who currently has more access than their job requires.

For the profiles and permission sets involved in this pilot, list:
- Any object with delete access that isn't clearly needed for the
  pilot's use case
- Any field-level security gap where a sensitive field is visible
  to more users than it should be
- Any object where bulk operations (mass update, mass delete) are
  permitted at the profile level

You can do this by hand in Setup, or paste your permission set XML into an AI tool and ask it to summarize the access it grants in plain language, the same translation habit used elsewhere on this site for validation rules and CPQ logic. Either way, do it before step 2, not after something goes wrong.

---

Step 2: pick the narrowest MCP server that does the job

The Headless 360 connection ships as more than one server, and they’re not equally scoped. A read-only server exists specifically for safe piloting. Start there.

• SObject Reads for anything that only needs to look up or summarize data, meeting prep, deal health review, pipeline review.
• SObject All only once you’ve confirmed which specific write actions the pilot actually needs, not as the default starting point.
• SObject Deletes is a separate server from general write access. Leave it disabled unless a specific, reviewed use case needs it. There isn’t a common pilot scenario where an AI tool should have standing delete access.

---

Step 3: pilot in a sandbox, not production

Both the OAuth setup and the MCP server connection support a sandbox-specific endpoint. Use it. Confirm three things there before anything touches production:

1. Tool behavior matches expectations. Does “update this Opportunity” actually update the field you’d expect, and nothing else?
2. Validation rules and field-level security actually fire. Try an action you know should be blocked by an existing rule, and confirm it’s still blocked when triggered through Claude rather than the UI.
3. Approval mode is set to require confirmation, not auto-approve. Every tool should start in a mode that asks before acting. Promote a specific tool to run without approval only after watching it behave correctly, repeatedly, not on the first success.

---

Step 4: set the escalation path before day one, not after an incident

Decide, in writing, before the pilot starts: who gets notified if an agent-triggered action does something wrong, how a connection gets revoked immediately if needed, and whether individual teams are allowed to create their own additional MCP connections or whether everything routes through one admin-managed one.

The single-admin-connection model is one of Claudeforce’s actual selling points over ad hoc integrations teams might otherwise build themselves. It only holds if it’s actually enforced as a policy, not just a default nobody changed yet.

---

When it breaks

A bulk action affects far more records than intended. This is the specific, named risk in Salesforce’s own setup guidance: one broadly worded request can trigger something like “delete all leads matching X” across an entire object. Transaction security policies and profile-level delete restrictions are the actual guardrail here, not a careful prompt. Set them before the pilot, not as a response to the first incident.

OAuth setup fails or times out. External Client App activation can take up to 30 minutes to fully propagate. A failure in the first attempt after setup is often just that delay, not a configuration error. Wait and retry before troubleshooting further.

A team member wants their own MCP connection outside the pilot’s scope. This is exactly the shadow-IT pattern the single-connection model exists to prevent. Route the request through whoever owns the pilot rather than letting a second connection get created quietly.

The pilot works fine and someone wants to expand it to production immediately. Confirm the same validation and permission checks from step 3 pass in production specifically. A sandbox’s data shape and a production org’s actual permission assignments aren’t guaranteed to match, especially in an org with any permission sprawl.

---

What to try next

Keep the permission audit from step 1 as a living document, not a one-time pass. The point isn’t that Claudeforce introduces new risk from nothing, it’s that it makes existing risk, permissions nobody had gotten around to tightening, actually matter on a shorter timescale than before.