Who can see and change what in your Salesforce org?

Too many people hold System Administrator, and nobody remembers why half of them need it. A permission set created for one project in 2022 still grants Modify All Data — to an account that left. The public Experience Cloud site’s guest profile can read objects nobody meant to publish. An integration user authenticates without MFA and holds Author Apex. Permission sets duplicate profile grants so thoroughly that removing either one is a gamble. And somewhere in Apex, a credential is hardcoded — it always is.

None of this shows up in a login history report. It is all sitting in configuration, readable in minutes — if something reads configuration as a connected system.

Horus Eye’s security rules refuse to grade by count alone. The same overprivileged permission set is low severity while nobody holds it, high when an ordinary user does, and critical when the assignee matches an integration-account naming pattern — because an unattended automated identity with broad access is the scenario the rule exists to surface. A few of the 26:

Plus dormant privileged users, permission sets assigned to inactive accounts (each one a standing grant that springs back to life on reactivation), policy-bypass system permissions, profile grants duplicated by permission sets, hardcoded secrets in Apex, session-ID outbound messages, role hierarchies past platform guidance, and more. Every finding carries its Salesforce documentation references.

For any permission set or profile, Deep Read draws the path: grantor → grants → objects and system permissions → assignees. It is the diagram every access review meeting has been trying to whiteboard from memory.

Access hygiene is where automated remediation is genuinely safe — the operations are withdrawals, not designs. The complete journey: Horus investigates the finding, writes the fix plan, asks the one question only the owner can answer, you approve each step, validation runs with zero writes, Fix it executes, rollback stands ready, and the re-scan proves the finding cleared.

What stays with humans: sharing-model redesign, role hierarchy strategy, the judgment of which integration needs what. That is a Health Assessment conversation — run on this evidence.

How do I audit Salesforce permission sets?

Grade by exercisability: admin-tier grants first, then who holds them — integration patterns, inactive accounts, ordinary users — then duplication against profiles, then the unassigned. Horus Eye reads all of it from configuration and never stores usernames.

What can a Salesforce guest user really see?

What the guest profile grants, adjusted by guest sharing rules and site configuration. The scan lists the object-level grants and says plainly what it did not inspect — whether a public page actually surfaces the data.

Modify All vs View All — what’s the difference in risk?

View All bypasses sharing to read; Modify All bypasses it to read, change and delete. Both are sharing bypasses — which is why Horus Eye reports them separately in its Security Exposure measure rather than blending them into one number.

How do I find dormant admin users?

Cross accounts that hold privileged grants against login activity. Dormant privileged accounts are high severity for a reason: they are the attack surface nobody is watching. A disabled login, by contrast, has no live blast radius — and the rules treat it that way.

Can Horus Eye change permissions for me?

Yes: withdrawals, duplicate- grant removal, inactive-assignment cleanup and set retirement — per-step approved, zero-write validated, reversible, refused on managed packages, re-scan verified.

Does this help with Salesforce HIPAA compliance?

It produces the access evidence a compliance program needs — who can exercise what against patient-adjacent objects, sharing bypasses, dormant privileged accounts — in a form an assessor can read. Horus Eye is not a certification and doesn’t claim your org is HIPAA compliant; it shows the least-privilege reality that Salesforce HIPAA compliance work has to start from.