The #1 Information Security Risk Your Enterprise Has With Claude in Your Salesforce

Somewhere in your Salesforce there is a user profile that was cloned from a manager's profile years ago, handed to a new hire, and never looked at again. There is a permission set that was added for a project that ended long ago. There is an active login that belongs to a contractor who finished their work two fiscal years ago. I don't know your instance, but I know how instances age, and I would be surprised if none of those three were true.

Up to now none of them mattered much. Claudeforce is what makes them matter, and this post is about why, and what I'd do about it before your Salesforce administrator connects the Claude plugin for the first team.

What a person can see through Claude is what they could already see in Salesforce, and that has been true for years without causing trouble.

The security model behind Claudeforce is simple to explain. Claude does not get its own access to your data. When a seller asks it for a pipeline review or a deal health check, the plugin works through that seller's own Salesforce access, so it can only read and change what that seller's permissions already allow. When Claude changes a record, the change goes through the same path a person's change would, so your validation rules run, your approval flows run, and the audit trail records who did what. Nothing in the announcement adds a back door.

That's reassuring, and I think it should be. The catch is in the phrase "already allow." The permissions your people have on paper and the permissions they use are two different things, and up to now the gap between them has been protected by something that isn't a control at all: effort.

Effort was the only thing protecting a profile with too much access, and Claude removes the effort.

Picture a regional sales manager whose profile lets her see every opportunity in the company, not just her region's. On paper that's a problem. In practice, to see a deal in another region she would have to know it exists, build a report or a list view, filter it, and read through it. She has a full job. She has never done it, and she never would, because the reward isn't worth the trouble. The over-permission sat there for years, technically real and practically harmless.

Now put Claude in front of the same profile. She types "which enterprise deals over a million are slipping this quarter?" and gets a tidy answer in a few seconds, with the deals from every region in it, because her permissions allow it. She wasn't snooping. She asked a normal question, and the tool did exactly what it was told. The trouble that used to protect that data is gone, and a profile that was harmless for five years is now data exposure at company scale.

Multiply that profile by a few hundred users and a few thousand questions a week, and that's the exposure.

Profiles in an instance that is a few years old carry more access than the jobs need, for ordinary reasons.

Access accumulates in a Salesforce instance the way it does in any system that has been in use for years, and the causes are mundane.

New profiles get cloned from existing ones. When a new role is created, the fastest way to set it up is to copy a profile that already works and adjust it a little, and the "adjust it a little" step tends to get skipped. Whatever the original had, the copy has too.

People change roles and keep what they had. A rep becomes a manager, a manager moves to enablement, and the permission sets get added for the new job without the old ones being removed. Over a career at one company, access only grows.

Users outlive the reasons they were created. Contractors, agency partners, integration users tied to tools you stopped paying for, and employees who left are all still active until someone deactivates them, and deactivation isn't on anyone's weekly list.

Sharing defaults were set for convenience. Early on, it's common to set an object like Opportunities so everyone can see every record, because it makes reporting easier. Years later that setting is still there, and now it decides what Claude will show anyone who asks.

The audit is three questions to your Salesforce administrator, and the answers should come back as lists, not reassurances.

You don't need to understand the permission model to run this. You need to ask three questions and insist on a list with names in it.

Who can see everything? Salesforce has system-level permissions (your administrator will know them as View All Data and Modify All Data) that override the record-sharing rules underneath them. Ask how many active users have them, through which profiles and permission sets, and whether each of those people needs them to do their job. The right number is small.

For the records Claude will be asked about first (accounts, opportunities, cases), what's the default? Can everyone see every record, or only their own and their team's? If the answer is "everyone," ask what it would take to narrow it and what would break.

Which active users shouldn't be? Contractors whose work ended, partners you no longer work with, integration users for retired tools, and people who changed departments and kept the old access. Ask for the list and a decision on each row.

Give this a deadline: findings closed before the plugin gets connected for the pilot group. In our twelve-month plan for Claudeforce this is the first thirty days, and it's the exit test for that phase.

Start the pilot read-only, and put the review on a quarterly calendar.

Once the audit is closed, my recommendation is to turn the plugin on for one sales team, in one region, read-only. Claude drafts the meeting prep and the pipeline update, and a person saves it. Write access comes later, one skill at a time, once you've watched it work. Then review permissions every quarter, because the four causes above don't stop when the audit ends.

If your team already reviews access quarterly and rebuilt profiles recently, this post is a confirmation rather than a warning. Turn it on. For everyone else, the review is the work I'd do first, before anyone in the company asks Claude a question you'd rather it couldn't answer.

The next thing I'd worry about is the bill, because Claudeforce is priced by usage rather than by seat. That's the next post.