TL;DR:
- Salesforce permission models get messy fast — profile sprawl, permission creep, and layered access controls make it nearly impossible to answer "who has access to what?" without a structured audit.
- The audit should map every permission against a persona matrix, prioritize high-risk grants like "Modify All Data" and "View All Data.”
- With Agentforce introducing AI users that inherit permissions from your security model, a permission audit should be the start of an ongoing governance program.
*****
"So who has access to what… and why?"
There's a moment in the life of every growing Salesforce org where someone asks these questions and then waits for a quick answer.
And then, nobody can answer quickly.
Maybe these questions come from a compliance officer preparing for SOC 2. Maybe they surfacesduring a security review after a data incident. Or maybe there’s just a new admin staring at 47 custom profiles, 120 permission sets, and a role hierarchy that looks like it was designed by a committee of people who never spoke to each other.
In any case, the question is easy to ask and terrifically difficult to answer — especially in complex environments where permissions have accumulated over years, across multiple business units, through acquisitions, org merges, and the quiet entropy of "just give them access so they can do their job."
This guide walks through how to actually run a permission audit in that kind of environment: not a theoretical exercise in a clean demo org, but a practical methodology for orgs where the permission model is already tangled and the stakes are real.
Why Salesforce Permission Audits Are Non-Negotiable Now
The operational case for permission audits has always been straightforward.
Over-permissioned users represent a security risk. Users with "Modify All Data" or "View All Data" who don't need it are one compromised credential away from a catastrophic data breach.
An 2025 FBI advisory (pdf) documenting threat actors compromising Salesforce orgs through stolen OAuth tokens made this viscerally real: when integration accounts have permissions far beyond their functional requirements, attackers don't need to be clever.
They just need one token.
But the compliance case has sharpened considerably.
- SOC 2 commonly drives quarterly access reviews to validate permissions against current job responsibilities.
- HIPAA mandates that access be limited to the minimum necessary. GDPR requires access restrictions proportionate to data sensitivity…
- ISO 27001 demands formal, documented user access management procedures with regular reviews.
If your organization operates under any of these frameworks, permission sprawl isn't just an operational headache — it's an audit finding waiting to happen.
And then there's Agentforce
AI agents in Salesforce are associated with a "running user" whose permissions determine what the agent can access and do. In Agentforce, actions can inherit permissions from referenced Apex, Flow, or Prompt Templates, so the running user’s scope matters a lot.
An over-permissioned agent user expands the attack surface for prompt injection, data exfiltration, and scope creep in ways that are harder to detect and contain than traditional human-user risks.
Salesforce's own security guidance is explicit: each agent user should be unique, should never be reused across multiple agents, and must strictly adhere to the principle of least privilege.
You can't enforce any of that without first knowing what permissions exist and where they live.
The Anatomy of a Messy Permission Model
Before you can audit permissions, you need to understand how they got messy in the first place. In most complex orgs, the story follows a familiar pattern.
It starts with profile sprawl. Someone clones "Sales User" to create "Sales User – London." Then someone else clones that to create "Sales User – London Events." Then someone creates "Sales User – London New Starter" as a temporary fix that becomes permanent.
Five years later, you have dozens of nearly identical profiles with minor, undocumented variations. Auditing who has what access becomes a guessing game because nobody remembers why the profiles diverged.
On top of that, permission creep accumulates.
A user needs access to a report, so an admin adds a permission to their profile instead of creating a permission set. A manager escalates a ticket about a blocked workflow, and someone grants "Modify All Data" to resolve it quickly. The temporary fix never gets reverted. Multiply this across hundreds of users and several years of turnover, and you end up with an org where most users have substantially more access than their role requires.
Then there's the layering problem. Salesforce's security model is inherently layered: organization-wide defaults set the baseline, the role hierarchy opens up record visibility, sharing rules add exceptions, profiles define broad access, and permission sets add granular capabilities on top.
Understanding what a single user can actually do requires tracing through all of these layers simultaneously — a task that's difficult for humans and essentially impossible without tooling at scale.
The profile-to-permission-set migration adds another dimension of complexity. Salesforce originally announced that permissions on profiles would reach end-of-life in the Spring '26 release, requiring all object access, field-level security, and system permissions to live exclusively in permission sets.
While Salesforce later walked back the hard enforcement date, the direction of travel hasn't changed: all investment is going into permission sets and permission set groups. Profiles will retain only baseline settings like login hours, IP ranges, default apps, record types, and page layout assignments. For teams that haven't started migrating, the audit becomes both an assessment of the current state and a planning exercise for the future state.
Step One: Inventory Everything
The first step in any permission audit is producing a complete inventory of the permission mechanisms in your org. This means cataloging every profile, every permission set, every permission set group, every role in the hierarchy, every sharing rule, and every public group. You need to know what exists before you can evaluate whether it's appropriate.
Salesforce provides several native paths for this.
The Setup Audit Trail captures changes to security configurations, including profile and permission modifications, though it only retains data for 180 days and the detail it provides on complex changes is often limited to "Modified profile X" without specifying what changed inside it.
For a more systematic extraction, SOQL queries against the Tooling API give you direct access to permission metadata. Querying the ObjectPermissions object surfaces every CRUD setting for every profile and permission set in the org. Querying FieldPermissions reveals field-level security grants. And querying PermissionSetAssignment shows you which permission sets are assigned to which users. These queries can be run through the Developer Console, Data Loader, or third-party tools that wrap SOQL in a more accessible interface.
The User Access and Permissions Assistant, a free app on the AppExchange from Salesforce, adds a significant capability here. It lets you report by user, permission set, or permission set group to understand who has what. It can surface which users hold dangerous permissions like "Modify All Data" or "Customize Application," and it includes a permission dependency visualization that shows what's downstream of a specific permission. For teams that don't want to write raw SOQL, this is a meaningful starting point.
But there's a catch. Even the Salesforce product management team has acknowledged that natively computing a user's effective permissions — the net result of their profile, all assigned permission sets, any permission set groups, and any muted permissions — is genuinely hard. The data model wasn't designed to make this calculation simple, and native reporting can't fully handle the complex joins required.
Step Two: Map Permissions to Personas
A raw export of permissions is necessary but not sufficient. The audit only becomes meaningful when you map permissions against what users actually need.
This requires building (or validating) a persona matrix: a document that defines the distinct job functions in your org and the minimum permissions each function requires. "Sales Rep," "Sales Manager," "Service Agent," "Marketing Ops," "Finance Analyst," "System Admin" — each of these personas has a specific set of objects they need to read, create, edit, or delete, a specific set of fields that should be visible to them, and a specific set of system permissions they require.
The persona matrix is your baseline. Once you have it, you compare it against reality. Export every profile's permissions and every permission set's grants, then overlay the actual assignments against the expected assignments. The gaps — permissions that exist in the org but don't appear in any persona definition — are your audit findings.
In practice, this comparison almost always reveals three things: users with far more access than their persona requires, permission sets that were created for a specific project and never cleaned up, and profiles that have drifted so far from their original intent that they're essentially ungovernable.
Step Three: Hunt for High-Risk Permissions
Not all permission gaps are created equal. Some are minor annoyances. Others are genuine security exposures. The audit should prioritize identifying and remediating the highest-risk permissions first.
The usual suspects include "Modify All Data" and "View All Data" (which bypass all sharing rules and field-level security), "Export Reports" (which enables bulk data exfiltration), "Manage All Data" on specific objects containing PII or financial records, "Author Apex" (which allows code execution), and "Customize Application" (which grants the ability to modify the org's configuration).
These permissions should be held by the smallest possible number of users, and every assignment should be documented and justified. If your audit reveals 30 users with "Modify All Data" and only three of them are system administrators, that's a finding that needs immediate remediation.
For Agentforce-specific audits, the high-risk list extends further. Agent users that share permission sets with human users, agent users with access to objects or fields beyond their functional scope, and agents with CRUD access they don't need for their defined actions are all red flags. Salesforce's guidance is clear: avoid sharing the same permission sets between multiple agents, and avoid granting broad access "just in case."
Step Four: Evaluate Sharing Rules and Role Hierarchy
Permissions audits often focus narrowly on profiles and permission sets while ignoring the role hierarchy and sharing rules — which is like auditing the locks on your doors while ignoring the open windows.
The role hierarchy determines record-level visibility.
A user positioned high in the hierarchy automatically inherits visibility into records owned by users below them. If the hierarchy doesn't accurately reflect your organization's reporting structure, users may be seeing records they shouldn't.
Sharing rules add lateral access: they open up record visibility between roles that aren't in a parent-child relationship. Criteria-based sharing rules, in particular, can create access paths that are hard to trace without careful review.
Organization-wide defaults (OWDs) set the foundation for all of this. If your OWDs for sensitive objects like Opportunities, Cases, or custom objects containing financial data are set to "Public Read/Write" instead of "Private," then no amount of profile cleanup will prevent over-exposure.
The audit should verify that OWDs for sensitive objects are appropriately restrictive, and that the role hierarchy and sharing rules only open up access where it's genuinely needed.
Step Five: Establish Ongoing Governance
A permission audit is not a one-time project. It's the first iteration of an ongoing governance program. Without a recurring cadence, permission creep will reassert itself within months.
The governance program should include quarterly access reviews (aligned with SOC 2 requirements if applicable), a formal change-control process for any permission modification, automated monitoring of high-risk permission changes (which Salesforce's Security Center can provide for organizations that have licensed it), and a clear ownership model where someone — an admin, a security team, or a dedicated governance role — is accountable for the permission model.
The profile-to-permission-set migration, even though it's no longer being enforced on a hard timeline, should be part of this governance program. Every new permission should be created as a permission set, not added to a profile.
Over time, the goal is to consolidate down to a small number of minimum-access profiles with a library of composable, well-documented permission sets that map cleanly to your persona matrix.
For organizations deploying Agentforce, governance extends to agent-specific concerns: regular reviews of agent user permissions, monitoring of agent access logs and conversation data, and periodic testing to verify that agents can't access data beyond their defined scope.
The Payoff
A clean permission model isn't just a compliance checkbox. It's the foundation for everything else: safe deployments, confident change management, Agentforce readiness, and the basic organizational trust that comes from knowing who can see what and why.
In complex environments, getting there takes real work. But the alternative — an org where nobody can answer the question "who has access to what?" — in world of AI agents, regulatory scrutiny, and expanding attack surfaces, is totally untenable.
