How We Found 78 Forgotten Permissions in a Single Salesforce Org
A 1,200-user Salesforce org. Eight years old. A clean list of profiles. A neat handful of public groups. From the outside, the permission model looked tidy.
Inside, there were 78 dormant permission sets nobody had touched in three years. A third-party app reading 14 fields it had no business reading. And a sharing rule that, under one specific edge case, exposed customer profile data across a partition that should have been opaque.
This is what a Salesforce pentest finds. Not the headline-grabbing zero day. The slow, decade-long permission bleed that compounds quietly until someone exploits it.
Why permission sets become a blind spot
Salesforce permission sets accumulate like inbox debt. Each new feature launch ships its own set. Each acquisition arrives with a stack. Each “temporary” elevation gets created on Friday and never removed on Monday. Three years in, the org has 200+ permission sets, most of which apply to fewer than five users — and a quarter of which apply to zero users but remain assignable.
That last category is the bleed. Zero current assignments does not mean zero historical risk. A permission set with no assignees this quarter is still a set of object-level grants, field-level visibilities, and Apex class accesses that anyone with the right Setup permission can attach to a user account. They are loaded ammunition.
Permission sets without assignees are not “unused.” They are pre-staged escalation paths. Anyone who can assign one has a 30-second privilege escalation tool sitting in Setup.
What our audit looked for, in order
Stage one: enumeration. Pull every permission set, every assignment, every grant. Tag the dormant ones (zero assignments in 90 days). For this client: 78 of 234.
Stage two: third-party connected app review. OAuth scopes against
actual usage. We found one connected app with api and full scope
making zero API calls in the last 60 days, and another with api scope
reading customer fields outside its documented surface.
Stage three: sharing-rule edge cases. We model the sharing rules as a graph and walk it looking for sequences where ownership changes plus group membership plus a public-read flag combine to surface data across partitions. One such sequence existed. It had been there for four years.
Stage four: FlexiPage and Lightning component grants. Some of the most useful escalation paths in modern Salesforce orgs are not permissions at all — they are visibility rules on FlexiPages that reveal record fields to roles the field-level security would otherwise hide. We always check this. Most pentest playbooks do not.
The result
- 78 dormant permission sets revoked.
- 2 connected apps had their OAuth scopes tightened.
- 1 sharing rule rewritten to close the partition leak.
- Attack surface (our internal scoring; not a marketing metric) reduced 41% in one engagement.
- Zero new functionality lost. No user complained. The org simply held less ammunition.
What we’d do
If you have a Salesforce org older than three years and you have never had a pentest specifically for the permission model, this is the engagement we run. It is short — typically two weeks — and the findings list is always longer than the client expects.
If you have agentic AI integrations on top of that org, the surface multiplies. We address those in the same audit.
The first 30 minutes of a discovery call is usually enough to know whether your org has the same shape we found in this one. Book one →