Salesforce Permissions Audit: 9 Hidden Access Risks Costing B2B Teams in 2026

Here's where I'm writing from. I've audited 50+ B2B Salesforce and Pardot orgs over seven years, and access is the layer almost nobody scopes until something breaks — a deactivated employee who still had Modify All Data, a Pardot connector that could read fields it had no business touching, a "temporary" admin grant from 2022 that never got revoked. None of it looks like a problem from the outside. The dashboards render, the sync runs, the reps log in. The problem is what all those people and systems can reach — and in 2026, one of those "systems" is an AI agent that acts on whatever you let it see.

I don't deploy Agentforce agents for clients. That's deliberate. What I do is audit the permission model an agent inherits the moment you switch it on — because Salesforce's own security guidance is blunt about it: every agent runs as a user, and it gets exactly that user's access. So this is the audit that used to be optional and isn't anymore. Let's walk it.

1What Does a Salesforce Permissions Audit Actually Check?

A permissions audit reviews who can see and do what across four mechanisms — profiles, permission sets, roles, and field-level security — and measures that effective access against the principle of least privilege. It's not a feature inventory; it's a risk review. The output is a prioritized list of access findings: users with more than they need, integration accounts that over-reach, sensitive fields exposed too widely, and stale grants nobody revoked. A focused audit on a B2B mid-market org typically produces 8 to 12 findings, each with a remediation step and a sense of how much data exposure it carries.

The reason this matters more than a generic "health check" is that access is invisible until it isn't. Nothing on a dashboard tells you that a marketing coordinator can export every Opportunity, or that a long-dead integration user still has API access to your entire customer base. Salesforce's Well-Architected guidance frames the whole problem around least privilege: every identity should hold the minimum access required to do its job, and everything beyond that is risk you're carrying for free. The audit is how you find the gap between "what's granted" and "what's needed."

2Profiles vs Permission Sets vs Roles: What Controls What?

These three get mixed up constantly, and confusing them is the most common reason an audit produces findings with no impact. The clean distinction: profiles define what you can do, roles define which records you can see, and permission sets add flexible extra access on top. A lead-routing fix doesn't repair a sharing problem; a permission-set change doesn't fix a role-hierarchy gap. Knowing which layer you're working on is what makes a fix actually move the needle.

The modern best practice, and the direction Salesforce is pushing hard, is a permission-set-led model: lean profiles that grant almost nothing, with access layered on through permission sets and permission set groups mapped to job personas. If your org still does most of its granting through fat profiles, that's not a style preference — it's the root cause behind half the over-access an audit finds.

3Are Permissions on Profiles Really Being Retired in 2026?

Short answer: not on a hard deadline — but profiles are frozen, so the direction is unambiguous. Salesforce originally announced an end-of-life for permissions on profiles targeting the Spring 2026 release, then reversed it — that enforcement date is off the table. But the same announcement was equally clear that profiles will get no further enhancements, and that every future investment goes into permission sets and permission set groups.

So don't let "the deadline got cancelled" lull you. Practically, profiles are now legacy: they still carry login hours, IP ranges, default apps, record types, and page-layout assignments, while object, field, and system permissions belong in permission sets. In an audit, profile sprawl is a finding precisely because it's the old model — and because over-assignment through profiles is the single most common least-privilege violation I see. The migration to a permission-set model is no longer a question of if; it's a question of doing it deliberately versus being dragged into it later — the same "legacy vs current" split that runs through the Pardot vs MCAE naming story.

4What Are the 9 Access Risks a Permissions Audit Finds?

Across B2B mid-market orgs, the same access risks repeat with uncomfortable consistency. Here are the nine I scope first — each one independently exposes data or breaks an integration, and most orgs have at least three active. This is the table to screenshot before your next security review.

Notice how the list ladders. Risks 1, 2, and 7 are the human-access mess. Risks 3 and 4 are the integration layer — where a single credential is the blast radius. Risk 9 is the new one, and it's why this audit jumped up the priority list in 2026: an agent doesn't introduce new access, it amplifies whatever access is already too loose. Let's take the heavy hitters one at a time.

5How Do Over-Permissioned Users Put Your Data at Risk?

Over-permissioning is the default failure mode of every growing Salesforce org, and it almost always comes from the same place: someone needed access fast to fix a time-sensitive issue, the access was granted on a profile, and nobody ever walked it back. Multiply that across years and you get marketing coordinators who can export every Opportunity, support agents who can edit closed deals, and "temporary" admins who've held Modify All Data since 2022. None of it was malicious. All of it is risk.

The two permissions worth hunting first are Modify All Data and View All Data — they bypass your entire sharing model in one checkbox, and they end up on far more users than any org can justify. An audit quantifies the exposure: how many people can see records they have no business reaching, and what the worst case looks like if one of those accounts is phished. This is exactly the kind of architectural debt I document in a Sales Cloud audit too — but there, it shows up as bad pipeline data; here, it shows up as a security and compliance liability.

6Why Are Integration Users (and the Pardot Connector) the Biggest Blind Spot?

Human over-access is bad; integration over-access is worse, because a single credential running 24/7 has the widest blast radius in your org. Salesforce's own architecture guidance is explicit: create a unique integration user for every integration, scoped to exactly what it touches — so a breach or misfire is contained to one system instead of your whole database. Shared, over-permissioned integration accounts are the opposite of that, and they're everywhere.

For my clients, the Pardot / MCAE connector user is the first integration account I scope, because it sits right at the Salesforce-marketing boundary. The connector only syncs data its user can see — so too little access breaks the sync silently (the classic "why aren't these prospects updating?" ticket), and too much turns the connector into a broad data-exposure path. More than half the Pardot sync problems I diagnose trace back to this user's permissions and sharing visibility, which is why a permissions audit and a Pardot audit so often overlap. If you're heading toward Marketing Cloud Next and Data Cloud, this gets sharper still: unified data means more systems reading from one place, and every one of those readers is an integration identity you'll need to scope — the same boundary-mapping discipline behind a Salesforce + Slack architecture audit.

7How Does Field-Level Security Control What Users — and Agents — Can See?

Field-level security (FLS) is the most granular layer of the model and the one most often left wide open. It controls which individual fields a user can read or edit — and crucially, it's the gatekeeper an AI agent honors too. An agent reads exactly the fields its running user is allowed to read, so any sensitive field left visible to that user is visible to the agent, and potentially to the end users the agent serves.

In an audit, FLS gets special attention on the fields that carry real consequences: personal data, financial figures, contract terms, anything that would matter in a breach or a compliance review. The common finding isn't dramatic — it's that FLS was set once, years ago, and never revisited as new fields and new roles piled on. That drift is harmless right up until an over-permissioned role, an integration, or an agent reaches a field it should never have touched. Auditing FLS on sensitive data is the cheapest insurance you can buy before any of those three start reading at scale.

8Why Does Agentforce Make a Permissions Audit Urgent in 2026?

Because an Agentforce agent doesn't get its own special access — it inherits a user. Every agent runs as a "running user," and it can see and do exactly what that user can. Salesforce's secure-Agentforce guidance is explicit: design for least privilege, start agents from a minimum-access profile, and migrate access controls out of profiles before you deploy. New agents begin with no permissions by default — but the moment you wire them to a running user with loose access, the agent has all of it.

This is the whole reason the audit moved up my priority list this year. I don't deploy agents — I audit the permission model they'll reason over, because an over-permissioned agent makes confident, wrong, fast decisions across data a human in that seat would never reach. Security vendors put it plainly: agents inherit the permissions of the users who run them, so excessive access becomes excessive exposure — and "scope sprawl" sets in as teams keep adding topics and actions to a useful agent until it quietly holds far more than it started with. The fix isn't a feature; it's the access discipline an audit enforces. If you're weighing readiness more broadly, the Agentforce reality check covers the full picture; this audit is the permissions slice of it.

9What Does MFA-for-All (July 2026) Change for Your Access Model?

Multi-factor authentication for all employee users hits production starting July 20, 2026, staggered over roughly 30 days, with a stricter phishing-resistant MFA requirement for privileged users and admins. It's a real deadline worth planning for — but understand what it does and doesn't cover. MFA is an authentication control: it governs who gets through the front door. A permissions audit is an authorization control: it governs what they can reach once they're inside.

The two are complementary, and you need both. MFA-for-All stops a stolen password from becoming a login; least-privilege permissions stop a successful login — human, integration, or agent — from becoming a full-database breach. Treating MFA as "we did security this year" is the trap: it hardens the door while leaving every interior room unlocked. Pair the July authentication deadline with an authorization review, and you've closed both halves instead of one.

10How Do You Actually Run a Salesforce Permissions Audit?

At a high level it's five moves: export every grant, find the over-access, scope the integrations, lock down sensitive fields, and document a permission-set-led model. You don't click through users one at a time — the free User Access and Permissions Assistant on AppExchange (and tooling like User Access Policies) lets you report on who has what and how they got it, which is the only sane way to handle an org with dozens of profiles and hundreds of permission sets.

The honest catch is interpretation. Pulling the data is mechanical; deciding which of 400 grants are risks, which are fine, and which are breaking your Pardot sync takes someone who's read a lot of orgs. That's the difference between a permissions export and a permissions audit. If you'd rather hand it off, that's the audit work I do — and if your real goal is the bigger profile-to-permission-set migration, the review and the migration belong in the same project, because fixing access mid-migration is far cheaper than fixing it twice — the same scope-it-once logic in the implementation cost guide. Either way, the move that protects you isn't buying a new security tool. It's knowing, honestly, who can reach what — before an agent, an integration, or a phished login reaches it for you.

Access is the layer that's invisible until it isn't — until a deactivated user still has the keys, a connector reads what it shouldn't, or an agent surfaces a field no one meant to expose. None of it looks like a problem on a dashboard. All of it is risk you're carrying for free. Audit who can reach what, enforce least privilege across users, integrations, and agents, and you turn a quiet liability into a documented, defensible access model — which is exactly what the next security review, Data Cloud rollout, or Agentforce deployment is going to demand anyway.