What Can Claude See in Your Salesforce Org?

The short answer: Claude sees exactly what the user it connects as can see. Not more, not less. There is no separate AI permission model, no service account, and no way to give an agent narrower access than the person who authorised it. Salesforce documents this plainly — every transaction runs as the authenticated user, and CRUD, field-level security, sharing rules, profile permissions and permission sets all apply.

That sounds reassuring until you look at who your users actually are. Most orgs have profiles that quietly accumulated View All Data years ago, for reasons nobody now remembers. That was survivable when a human was clicking through screens one record at a time. It is a different situation when a model is reading across everything that profile can reach.

We run Claude against Salesforce orgs every day, for our own business and for clients. This post gives you the three queries we run first. They take about ten minutes, they need no new tooling, and you can run them right now whether or not you ever connect an AI agent to anything.

Key Takeaways

An AI agent connected to Salesforce inherits the exact permissions of the user who authorised it
There is no narrower “agent-only” permission scope — if you need one, you build it as a dedicated user
Salesforce Hosted MCP has been generally available since April 2026 for Enterprise Edition and above, so this applies to most orgs today
Three SOQL queries tell you your exposure: what grants it, who has it, and whether it came from a profile or a deliberate assignment
Profile-inherited access is the number that usually surprises people — it is invisible in the permission set list
Fix the assignments before you connect anything, not after

Why this became urgent in August 2026

On 26 August 2026, Salesforce and Anthropic announced Claudeforce. The product that shipped with it, Salesforce in Claude, is a plugin with 37 prebuilt sales skills that lets a seller work their pipeline from inside Claude. It is in closed pilot, with an open beta expected in September.

The announcement is new. The capability underneath it is not. Salesforce Hosted MCP Servers went generally available in April 2026 for every Enterprise Edition org and above. If you are on API v67.0 or later, the connection this is built on has been available to you for four months.

So the question is not whether your org will support this. It probably already does. The question is what happens the first time somebody in your sales team authorises it.

One line from the launch copy is worth reading carefully. Salesforce describes the setup as requiring “no per-user setup, no new permissions model to build, no re-auditing account by account.”

The first two are true. The third is the opposite of what we would tell a client. Your existing sharing rules and field-level security becoming the agent’s reach is precisely the argument for auditing account by account, not against it. Nothing about that sentence is false. It just describes a feature in a way that skips the consequence.

The rule that governs everything

An agent inherits its user. That is the whole model.

There are no service accounts and no autonomous credentials — authentication is OAuth 2.0 with PKCE through an External Client App, and every action is attributed in the audit trail to the human who authorised the connection. This is good design. It also means the permissions conversation you have been deferring is now the security conversation.

So: who are your users, and what can they reach?

Query 1: what grants the keys

Run this in the Developer Console, or with sf data query. It lists every profile and permission set in your org that carries View All Data or Modify All Data.

SELECT Label, IsOwnedByProfile, Profile.Name,
       PermissionsViewAllData, PermissionsModifyAllData
FROM PermissionSet
WHERE PermissionsViewAllData = true
   OR PermissionsModifyAllData = true
ORDER BY IsOwnedByProfile DESC

Two things to know before you read the results.

Every profile in Salesforce has a hidden PermissionSet record behind it. That is why this one query catches both profiles and real permission sets. The IsOwnedByProfile column tells you which is which: true means it is a profile, false means somebody granted it deliberately.

And when IsOwnedByProfile is true, the Label column is useless — it returns an internal ID like 00ex00000018ozT_128_09_43_34_1. That is why the query pulls Profile.Name as well. Read that column, not the label.

Query 2: who actually has them

The first query tells you what exists. This one tells you who is holding it, and where they got it.

SELECT Assignee.Name, Assignee.Username,
       PermissionSet.IsOwnedByProfile,
       PermissionSet.Profile.Name,
       PermissionSet.Label
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsViewAllData = true
  AND Assignee.IsActive = true
ORDER BY Assignee.Name

Swap PermissionsViewAllData for PermissionsModifyAllData and run it again. Modify All is the more serious of the two, and the list is usually shorter and more surprising.

Filtering on Assignee.IsActive = true matters. Inactive users cannot authorise anything, and leaving them in inflates the number in a way somebody will eventually catch.

Query 3: the number you can put in an email

SELECT COUNT_DISTINCT(AssigneeId)
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsViewAllData = true
  AND Assignee.IsActive = true

COUNT_DISTINCT matters here. A user who has View All Data through both a profile and a permission set produces two assignment rows, and a plain COUNT() counts them twice.

Run the same query against your total active user count and you have a percentage. That percentage is the thing to take to a security review.

How to read what you get back

Compare the output of query 2 against query 3. The gap between them is the finding.

Mostly permission sets. If the people holding View All Data got it from named permission sets, somebody made a decision. You may disagree with the decision, but it was made, and you can find out why and by whom. This is the healthy version.

Mostly profiles. If most of your list shows IsOwnedByProfile = true, the access was inherited from a profile that has been in place for years, and nobody chose it for these specific people. This is the common version, and it is the one worth acting on.

Integration users in the list. Platform and integration users frequently carry broad access because it was the fastest way to make an integration work. They are usually invisible in this conversation because nobody thinks of them as people. They are still users, and they still hold the keys.

The pattern we see most often is a long-standing admin profile granting more than anyone would grant today if they were starting fresh — plus one or two integration users nobody has reviewed since the integration went live.

What to fix, and in what order

Reduce Modify All Data first. It is the shorter list and the higher consequence. For most orgs, the honest answer is that only genuine system administrators need it.

Move grants out of profiles and into permission sets. Not because permission sets are inherently safer, but because they are visible and attributable. A permission set has a name, an owner and a reason. A profile permission is just there.

Review your integration users separately. They do not attend the meeting where you discuss this, and they usually have the broadest access in the org.

Then, and only then, connect anything. If the first user to authorise an AI connection is a system administrator, you have connected an agent to your entire database on day one. Start with a user whose access you have actually looked at.

None of this is new advice. Least privilege has been the right answer in Salesforce for fifteen years. What has changed is that the cost of ignoring it used to be theoretical, and now it is a specific thing a specific tool will do on a Tuesday afternoon.

What Salesforce has not published yet

We have read the documentation carefully. As of 28 August 2026, some things are simply not addressed, and you should know which:

Whether validation rules, Apex triggers, record-triggered Flows and duplicate rules fire on a write through this path is not documented anywhere we can find
Salesforce’s MCP security guidance does not mention prompt injection, untrusted content or exfiltration. A CRM is full of text that strangers wrote — web-to-lead submissions, inbound email, attachments, meeting notes — and that is a reasonable question to put to your account team
Neither company has published pricing. Three separate cost lines are already visible: paid Claude seats per user, Salesforce API consumption that varies by edition and licence, and an Enterprise Edition floor for Hosted MCP

We would rather flag these as open than guess at them. If any of it gets answered, we will update this post and date the change.

Frequently asked questions

Can I give Claude read-only access to Salesforce? Yes, and for a first deployment you probably should. Salesforce’s Headless 360 MCP server exposes four tools — Discover, Describe, Dispatch, and Dispatch (Read-Only). A read-only deployment is architecturally supported. The cleaner approach is to authorise from a user whose profile is read-only for the objects in scope, so the constraint lives in the permission model rather than in a configuration choice somebody can change.

Does this require Claudeforce or the September beta? No. Salesforce Hosted MCP Servers went generally available in April 2026 for Enterprise Edition and above. If your org is on API v67.0 or later you can evaluate this today, in a sandbox, without pilot access.

Can I create a dedicated user for the AI connection? Yes, and this is the pattern we recommend. Salesforce does not support service accounts for this — authentication is per-user OAuth and every action is attributed to the authenticated user. But nothing stops you creating a named Salesforce user with a purpose-built profile, authorising from that user, and giving it exactly the objects and fields the use case needs. You get a scoped agent and a clean audit trail.

What edition do I need? Enterprise Edition or above, on API version 67.0 or later. If you are on Professional Edition, that is the prerequisite conversation to have first.

Will these queries work in a sandbox? Yes, and a sandbox is the right place to start. Bear in mind that permission set assignments in a refreshed sandbox reflect the state of production at refresh time, so run them against production when you want the real number.

How long does a proper permissions review take? For a mid-market org, gathering the data is a morning. Deciding what to do about it — who genuinely needs what, and who signs off on removing access — is the part that takes weeks, because it requires people, not queries. Start the data gathering now so the conversation has something concrete in it.

Estarei implements and manages Salesforce for mid-market companies. We have been building with Claude since 2025 and running it against client Salesforce orgs since January 2026. If you want the queries above run properly across your org — including field-level security, sharing and a named exception register — book a free consultation.