"God mode" in Salesforce is access that lets a user read or modify nearly everything in the org. It accumulates silently, through profiles and permission sets, and by the time you audit permissions, you might have dozens of users with far more power than their job function needs.

Auditing for god-mode access is a critical security task. Here's what you're looking for.

What "God Mode" Means

God-mode users typically have one or more of these permissions:

Modify All Data — edit every record in the org, regardless of ownership or sharing rules.
View All Data — read every record in the org.
Modify All Metadata (Customize Application) — change org configuration (custom fields, validation rules, flows).
Author Apex — write and run Apex code.
Manage Users — create and modify users.
Object-level View All / Modify All — for critical objects like Account or Opportunity, View All / Modify All on the profile or permission set.

Any one of these is powerful. In combination, they're dangerous.

The Accumulation Problem

Here's the silent part: a user can accumulate these permissions across multiple places.

Their profile might grant View All on the Account object.
An assigned permission set might grant Modify All Data.
A permission set group they're added to might grant Author Apex.
A separate muting permission set (which subtracts permissions) might try to remove one, but the others remain.

An admin might know the user was assigned a permission set six months ago, but not remember what it grants. The user's role changes, but their old permission sets never get removed. The permission set gets updated to add a new permission, and that change cascades to everyone assigned to it.

By the time you audit, the user has six layers of permissions from six different sources, and the cumulative effect is god-mode access.

Toxic Permission Combinations

Some combinations are especially dangerous.

Modify All Data + Data Export

A user with Modify All Data can edit records. If they also have the Export Data permission, they can export every record in the org and walk away with your customer list, financial data, and employee information.

View All Data + API Enabled

A user with View All Data and API access can query every record via REST or SOQL and bulk-download data in minutes.

Modify All Metadata + Author Apex + Manage Users

This user can change any configuration, write and run code that executes in any security context, and create new users. They can create a backdoor.

Modify All Data + Workflow + Process Builder

If this user can also create workflows or flows, they can create automation that modifies or deletes records silently and at scale.

The concept is "blast radius" — the scope of damage a compromised account can do. An intern with Modify All Data has a blast radius equal to every record in your org.

Finding God-Mode Users Manually

You'd start in Setup:

Check every profile for system permissions.

Check every assigned permission set.

Check every permission set group.

Check for muting permission sets assigned to the user.

For each object (Account, Opportunity, Contact, etc.), check if there's a View All / Modify All grant.

Then you'd cross-reference: who has Modify All Data? Who has View All Data? Whose cumulative permissions cross into toxic territory?

This is a half-day audit for a 100-user org. It's error-prone and hard to automate manually.

The Automated Way: Security Insights

SFDC Police's Security Insights module surfaces god-mode users and toxic permission combinations instantly.

It scans every user in your org and identifies:

God-mode users — users with Modify All Data, View All Data, Modify All Metadata, Author Apex, or Manage Users.
Toxic combinations — users whose stacked permissions create dangerous blast radius (e.g., Modify All Data + Export Data).
Over-permissioned accounts — users who have permissions for objects they shouldn't need (e.g., a contractor with Modify All Data on the Product object).

For each user, it shows the exact source of each permission (which profile or permission set), so you can audit and remove permissions without guessing.

It also scores your org's overall security posture: compliance risk (sensitive permissions granted), audit risk (who can change configurations?), and data risk (who can read and export data?).

Reducing Blast Radius

Once you've identified god-mode users, the fix is straightforward:

Inventory their current permissions — use Permission Chain or Persona Simulator to see the full stack.

Ask: what does their job require? — A support agent probably needs read access to Cases and Knowledge Articles, not Modify All Data.

Build focused permission sets — create permission sets that grant only the objects and actions they need (e.g., "Support Agent" grants Read/Create/Update on Case, Read on Knowledge).

Remove the broad permissions — replace the high-blast-radius permission set with smaller, more specific ones.

Validate before and after — use Persona Simulator to confirm they can still do their job with the new permissions.

For most users, god-mode permissions are technical debt, not necessity. An admin needs Customize Application and Author Apex. A support agent doesn't need Modify All Data. A financial analyst needs View All Data for reports, but not Modify All Data.

Starting Your Audit

Use Security Insights to run your first god-mode audit. It takes seconds.

See the Security Insights feature documentation to get started. No setup required — it runs on your existing Salesforce session and analyzes permissions as they are right now.

For a guided walkthrough on moving away from god-mode profiles toward specific permission sets, read Profiles Are Fading: A Practical Move to Permission Sets.

How to Find Every God-Mode User in Your Org