Least privilege means every user, profile, permission set, integration, and connected app has exactly the access it needs — and nothing more. Here's what it means in Salesforce, why orgs drift away from it, and how to get back to it.
The principle of least privilege (PoLP) is a foundational security idea: give every person, account, and system the minimum access required to do its job, and no more. The less access each identity carries, the smaller the damage when a credential is phished, an account is compromised, or an integration is misused. In Salesforce, "identity" isn't just users — it's profiles, permission sets, permission set groups, roles, sharing rules, integration and API users, and the connected apps wired into your org. Least privilege means all of them are scoped tight.
Access in Salesforce only ever seems to grow. Every one of these makes the org a little more permissive than it needs to be:
Temporary grants that solve a ticket today and quietly become permanent tomorrow — because nothing ever prompts a review.
New roles built by copying an over-broad profile, so excess permissions propagate instead of being scoped from scratch.
Service accounts handed the broadest access "to be safe," then left running for years with no oversight.
Layers of permission sets and groups whose combined effect no one can see at a glance — access no screen adds up for you.
External apps granted broad scopes and long-lived tokens that persist long after anyone remembers approving them.
Full-access accounts for people who changed roles or left — still holding the keys to everything.
Map who and what can reach your data — every profile, permission set, role, integration user, and connected app in one picture.
Compare access granted against access actually used, and surface the delta — the permissions and grants nobody needs.
Trim profiles to least privilege, retire stale users, and revoke unused connected apps and over-broad OAuth scopes.
Least privilege isn't a one-time cleanup. Watch for new grants that widen access, and catch drift in days — not at the next annual audit.
Doing this by hand across a mature org is close to impossible — the access model is too big to hold in your head. Hubbl scans your org and turns least privilege into something you can actually see and enforce: over-permissioned profiles, the gap between granted and needed access, stale and integration users, and every connected app with its scopes. It's the fastest way to go from "we should tighten access" to a ranked, ready-to-act plan.
It's the security principle of granting every user, account, and system the minimum access it needs to do its job — and nothing more. Less standing access means a smaller blast radius when something is compromised.
Inventory all access (profiles, permission sets, roles, integration users, connected apps), compare granted vs. used access to find over-permissioning, right-size profiles and revoke what's unused, and then monitor continuously so access doesn't drift back open.
An agent inherits the access of the org it runs in. Every over-broad permission and unused connected app becomes something an agent can act on at machine speed — so tightening access to least privilege is a prerequisite for putting AI on your org safely.
A permission audit is a point-in-time snapshot. Least privilege is an ongoing state: access stays scoped tight as the org changes. That's why continuous monitoring matters more than a once-a-year review.
Scan your org in about two minutes and see exactly where access is too broad — profiles, users, and connected apps, ranked for cleanup.