Permission Set Overprivileging: The Silent Risk in Every Salesforce Org

We’ve previously covered how vendors authenticate into your org–from session hijacking to the JWT Bearer flow. But authentication is only half the equation. Once a user or integration is inside your org, what can they actually do?

In most orgs, far more than they should.

Permission set overprivileging is one of the most common and least visible security risks in Salesforce. It doesn’t show up in login history. It doesn’t trigger event monitoring alerts by default. It just sits there quietly, giving users and integrations access to data they were never meant to touch.

How Overprivileging Happens

It rarely starts with bad intentions. It usually starts with one of these:

• “Just give them full access so we can troubleshoot.” A temporary escalation that never gets rolled back.
• Cloned profiles and permission sets. An admin clones an existing permission set to save time, inheriting permissions that don’t apply to the new use case.
• Vendor requests for broad access. A vendor asks for “Modify All Data” during implementation, and no one revisits it after go-live.
• Permission set sprawl. Over time, users accumulate permission sets from multiple projects, roles, and integrations–each adding access that was never reviewed holistically.

The result is users and integrations with access to objects, fields, and capabilities they don’t need. And in security, unnecessary access is unnecessary risk.

What to Look For

The most dangerous permissions to audit are:

• View All Data / Modify All Data: These bypass all object-level and record-level security. Any user or integration with these permissions can read or write every record in your org. There are very few legitimate reasons for a vendor integration to have either.
• Manage All Users: Allows creating and modifying users, resetting passwords, and assigning permission sets–including escalating their own access.
• Author Apex / Customize Application: These allow deploying code and modifying metadata. In the wrong hands, they’re a backdoor.
• Export Reports / Data Export: Combined with broad object access, these enable mass data exfiltration.

Beyond the high-risk permissions, you should also audit object and field-level access. An integration that only needs to read Contacts shouldn’t have write access to Opportunities. A vendor that syncs calendar events shouldn’t be able to see a contact’s date of birth or personal email address.

How to Audit Your Org

Step 1: Identify Users with View All Data / Modify All Data

Run this query in the Developer Console, or your preferred SOQL tool:

SELECT Assignee.Name, PermissionSet.Name, PermissionSet.IsOwnedByProfile
FROM PermissionSetAssignment
WHERE PermissionSetId IN (
    SELECT Id FROM PermissionSet
    WHERE PermissionsModifyAllData = true
    OR PermissionsViewAllData = true
)

Review every result. For each user, ask: does this person or integration genuinely need org-wide data access?

Step 2: Find Integration Users with Excessive Permissions

If you followed the best practice from our JWT article and created dedicated integration users, audit their permission set assignments:

SELECT Assignee.Name, PermissionSet.Name, PermissionSet.Label
FROM PermissionSetAssignment
WHERE Assignee.Name LIKE '%integration%'
ORDER BY Assignee.Name

Each integration user should have a single, purpose-built permission set with only the CRUD access the integration requires. If you see multiple permission sets or any of the high-risk permissions listed above, that’s a flag.

Step 3: Audit Permission Set Sprawl

Find users with the most permission set assignments:

SELECT AssigneeId, Assignee.Name, COUNT(Id) numPermSets
FROM PermissionSetAssignment
WHERE PermissionSet.IsOwnedByProfile = false
GROUP BY AssigneeId, Assignee.Name
ORDER BY COUNT(Id) DESC

Users at the top of this list are the most likely to have accumulated unnecessary access over time.

Deeper Dive

Permission Set Groups and Muting

Salesforce introduced Permission Set Groups to help manage permission set sprawl by bundling related permission sets together. But the more powerful–and underused–feature is Muting Permission Sets.

A Muting Permission Set is assigned to a Permission Set Group and removes specific permissions from the group. This lets you take a broad permission set and tailor it for a specific role without cloning or creating yet another permission set.

For example, if a vendor’s managed package includes a permission set with Report Export access, you can create a Permission Set Group that includes that permission set plus a Muting Permission Set that revokes the export capability. The vendor’s integration still works, but the data export risk is neutralized.

Permission Set Group: "Vendor X - Production"
├── Vendor X Managed Permission Set (from package)
└── Muting Permission Set: Revokes "Export Reports"

This is a clean pattern for applying least privilege to vendor integrations. You can’t modify a vendor’s managed permission set directly, but a Muting Permission Set lets you effectively narrow it without touching the package itself.

Object and Field-Level Security Queries

Beyond the high-risk system permissions, you should audit what objects and fields each permission set can actually access. These queries help:

Find permission sets with access to sensitive objects:

SELECT Parent.Name, SObjectType, PermissionsRead, PermissionsCreate,
       PermissionsEdit, PermissionsDelete
FROM ObjectPermissions
WHERE SObjectType IN ('Contact', 'Opportunity', 'Case', 'Account')
AND Parent.IsOwnedByProfile = false
ORDER BY SObjectType, Parent.Name

Find permission sets with access to specific sensitive fields:

SELECT Parent.Name, SObjectType, Field,
       PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE SObjectType = 'Contact'
AND Field = 'Contact.Birthdate'
AND Parent.IsOwnedByProfile = false

Replace Contact.Birthdate with whatever sensitive fields exist in your org. The point is to ask: who can see this data, and should they?

Building a Permission Audit Cadence

One-time audits are helpful, but permissions drift over time. Build a recurring process:

1. Quarterly permission reviews: Run the queries above and compare results to the previous quarter. New assignments of View All Data or Modify All Data should require a documented justification.
2. Integration user access reviews: Every time a vendor’s contract is renewed, re-audit their integration user’s permission sets. Vendors’ needs change over time, and permissions should shrink as integrations mature–not grow.
3. Deprovisioning checks: When a vendor relationship ends or an employee changes roles, verify that their permission set assignments have been cleaned up. Orphaned permission sets are a common source of lingering access.
4. Permission set naming conventions: Adopt a naming standard that makes it immediately clear what each permission set is for (e.g., Vendor_X_API_Access, Finance_Team_Reports). This makes audits dramatically easier.

The Salesforce Security Model in Layers

It’s worth remembering that Salesforce security is layered, and permissions are just one layer:

LayerPurposeManual Sharing / Apex SharingRecord-level exceptionsProfiles & Permission SetsObject/field/system accessSharing RulesOpens access laterallyRole HierarchyOpens access up the chainOrganization-Wide Defaults (OWD)Most restrictive baseline

Overprivileged permission sets can undermine an otherwise well-designed security model. If your OWDs are set to Private but an integration user has View All Data, the OWDs are effectively meaningless for that user.

The Bottom Line

Authentication controls who gets in. Permissions control what they can do once they’re inside.

Most orgs invest heavily in the front door–MFA, SSO, IP restrictions–while leaving permission sets unchecked for years. That’s a gap attackers and compromised vendor integrations will exploit.

The fix isn’t complicated: audit what exists, remove what isn’t needed, and build a recurring review process so permissions don’t drift back over time.

If you’re managing permissions across a complex org with multiple vendors and business units, tools like Permissions Assistant can help streamline the audit and management process.

And if you want a hand reviewing your org’s permission landscape, we’re here to help.

Book a 15-Minute Security Strategy Call

Reference(s):

https://help.salesforce.com/s/articleView?id=sf.perm_sets_overview.htm

https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_overview.htm

https://help.salesforce.com/s/articleView?id=sf.perm_set_groups.htm

‍