Salesforce Agentforce Is Inheriting Your Permission Debt: Auditing Agent Access Before It Amplifies a Breach

Three separate mechanisms compound into the same underlying problem.

Org-wide defaults and sharing rules drift wider over time, not narrower. Object-level sharing settings in Salesforce are commonly set permissively during initial rollout to avoid blocking early adoption, with the intention of tightening them later once usage patterns are understood. That tightening pass frequently never happens, because nothing forces it: a Public Read/Write default on a sensitive object does not generate an incident on its own, since human users are not systematically exploiting the full breadth of what they could technically see.

Permission sets accumulate through project-driven grants that outlive their project. A permission set assigned broadly to unblock a specific initiative, a data migration, an integration rollout, a temporary cross-team collaboration, routinely stays assigned long after the initiative ends, because removing access requires someone to notice it is no longer needed and take deliberate action, while leaving it in place requires nothing.

Human exploration habits mask the actual scope of both. A user with access to an entire object's records through a permissive sharing rule does not typically open every record; they work the subset relevant to their role. That self-limiting behavior is incidental, not a control, but it has functioned as one for years in many orgs, because nobody was systematically walking the full breadth of what a profile permitted.

Agentforce removes that incidental limitation. Reco's own security guidance on Agentforce notes that, unlike a standard connected app with fixed OAuth scopes, an Agentforce agent can dynamically invoke flows, APIs, and tools within its authorization boundary, and inherits row-level and field-level security from whatever profile, permission sets, and sharing rules apply to the user context it runs under. An agent's task-driven queries are comprehensive by design; it retrieves what is relevant to the task across everything it is permitted to see, not a habitually-limited subset. Varonis frames the resulting shift directly: with excessive access in place, the question is not whether sensitive data gets surfaced, but how quickly, since an AI agent does not let unused access sit idle the way a human user does.

The ForcedLeak disclosure illustrates how this compounds with a technical flaw rather than replaces the need to audit permissions in the first place. The vulnerability chain combined an indirect prompt injection (malicious instructions hidden in a public-facing Web-to-Lead form field), agent overreach (the agent acting on those injected instructions within its permitted scope), and a Content Security Policy gap that let exfiltrated data reach an attacker-controlled domain. The permission scope the agent operated within was what determined how much data that chain could reach once triggered; a narrower, well-audited scope limits the blast radius of a prompt injection flaw even when the flaw itself is patched.

Before enabling Agentforce more broadly, or as an urgent retroactive check if it is already enabled, work through the following to map the actual access surface an agent operates within.

Apply least privilege and, per Varonis's framing, least agency: limiting not just what data an agent can see, but which actions it can take autonomously versus which require human approval.

Tightening a setting in Setup is not the same as confirming an agent's effective access changed. Validate against the agent's actual behavior, not just its configuration.

If tightening org-wide defaults to Private breaks legitimate access for human users who relied on the broader default, this usually means the sharing rules rebuilt to replace it were not comprehensive; audit which roles, groups, or existing permission sets need an explicit sharing rule added rather than reverting the org-wide default back to its prior permissive setting.

If an agent still surfaces data from an object you scoped down, check whether the agent's user context holds a separate permission set or profile-level "View All" or "Modify All" object permission that overrides row-level sharing entirely; object-level sharing rules do not constrain a profile or permission set that separately grants View All Data or Modify All Data on that object.

If field-level security changes do not appear to take effect for the agent, confirm the agent is not accessing the field indirectly through a formula field, a report, or a related list that surfaces the underlying value even when the source field itself is restricted; field-level security on Salesforce does not automatically propagate to every derived or aggregated view of that field's data.

If adversarial prompt testing still surfaces sensitive data despite a tightened permission scope, the gap is likely in the agent's own instructions or guardrail configuration rather than in Salesforce's native access controls; review the agent's system prompt and any tool-invocation guardrails separately from the permission audit, since the two are complementary controls and a fix to one does not substitute for a gap in the other.

Handle internally when the gap traces to a specific, identifiable org-wide default, permission set, or field-level security setting that your team has the access and change-management process to correct directly.

Escalate to Salesforce support, or to a dedicated security review involving your CISO or security team beyond the Salesforce admin function, when: an agent's data access does not match what its documented permission set and sharing configuration should allow, suggesting a platform-level behavior rather than a misconfiguration; you discover evidence an agent already exfiltrated or exposed data before remediation, which shifts this from a configuration fix to an incident response matter; a connected app's OAuth scope cannot be reduced through standard Setup configuration and appears to require a platform-level change; or your organization's current Salesforce Security Health Check score falls well outside the audit-ready range across multiple objects and a single admin-level remediation pass is not sufficient to close it without a broader governance process.

Before escalating, gather: the specific agent's user context and full list of assigned permission sets and profile, the org-wide default and sharing rule configuration for every affected object, the current Security Health Check score and the specific findings driving it, connected app OAuth scope details for any integration involved, and, if applicable, agent query or activity logs covering the period in question. For the adjacent pieces of this same audit, our guides on Salesforce security hardening, auditing OAuth app grants across Microsoft 365, Entra ID, and Google Workspace, and our coverage of the Amtrak ShinyHunters Salesforce breach affecting 9 million records cover the connected-app and third-party-integration exposure this same permission debt frequently extends into.