July 18, 2026

Agentforce Agent User Least Privilege: What the Wizard Grants, What Your Agent Actually Needs, and How to Audit the Gap

What the Agentforce setup wizard grants your service agent user, what it actually needs, and how to audit both before an attacker maps the gap for you.

TL;DR

Employee agents execute actions as the human asking; service agents execute as a dedicated agent user. That one distinction decides your whole security model, because a permission set that is harmless on an employee agent becomes a shared, always-on identity reachable by anonymous visitors on a service agent.
The out-of-the-box grants are narrower than the folklore: an Einstein Agent User profile, three standard permission sets, a passwordless user that cannot log in, and no object data access until you add it.
The real over-permissioning hides in the action layer. A flow running in system context or an Apex class compiled before API version 67.0 ignores the agent user's carefully scoped permissions entirely.
Prompt injection research through 2026 (ForcedLeak, then PipeLeak in April) keeps proving the same formula: untrusted input, times the agent's read scope, times any outbound action, equals exfiltration. Least privilege on the agent user is the term you control.
You can audit both directions: what the agent user can access (permission set assignments, flow contexts, Apex API versions) and what it has accessed (agent event logs, and Invocable Action and Insufficient Access event types in Event Monitoring).

What You'll Learn

The execution identity model for employee versus service agents, and why it is the first question in any Agentforce security review
Exactly what the setup wizard and Agentforce DX provision: profile, permission sets, and the properties of the agent user itself
How system-context flows and legacy Apex quietly bypass the agent user's permissions, and what Summer '26 changed
SOQL-level steps to inventory agent users, their grants, and their actual activity
A least-privilege recipe you can apply to a service agent this week

The Problem

Your service agent works. It answers customers on the website, files cases, checks order status. Somewhere in Setup there is a user you did not create by hand, with a name like EinsteinServiceAgent User, and if someone asked you exactly what that user can read, write, and export, the honest answer is probably "whatever the wizard set up, plus whatever we added while debugging."

That answer stopped being acceptable somewhere between ForcedLeak and PipeLeak. The 2026 security research on agent platforms keeps landing the same punch: nobody breaks the large language model (LLM); they feed it hostile instructions through an input you left public, and then the agent does exactly what its identity is allowed to do. A Cloud Security Alliance survey published in April 2026 found 53 percent of organizations had experienced artificial intelligence (AI) agents exceeding their intended permissions. The agent's permissions are the blast radius. Yours are probably wider than the agent's job.

The good news is that this is auditable with tools you already have. The agent user is a real user, so the whole permission-analysis toolkit applies, and the event log surface for agents got substantially better through late 2025 and 2026.

Common Questions This Article Answers:

What permissions does Agentforce actually grant the agent user by default?
Does my agent respect sharing rules and field-level security?
How do I see what my agent has been accessing in production?

Quick Answer

Start with the identity question: employee-facing agents execute actions as the user typing the prompt, while service agents execute as a dedicated agent user, and everything that agent user can see is in scope for every conversation the agent has. The default provisioning is reasonably tight: a passwordless user on the Einstein Agent User profile with three standard permission sets (Agentforce Service Agent Base, Agentforce Service Agent User, and Prompt Template User in current orgs) and no object data access until you grant it. The leak paths are elsewhere. A flow behind an agent action that runs in system context without sharing bypasses the agent user's object permissions and sharing model entirely, and Apex actions compiled below API version 67.0 default to system mode the same way. So the audit is three passes: inventory the agent user's permission set assignments, check the run context of every flow and the API version and sharing keywords of every Apex class behind agent actions, then verify actual behavior through the agent event logs and, if you have Event Monitoring, the Invocable Action and Insufficient Access event types. Cap it structurally: one agent, one dedicated agent user, one purpose-built permission set, never shared.

The first question in every review: who does this agent run as?

Salesforce's own packaging security documentation draws the line cleanly. Employee agents (the internal, CRM-embedded kind) execute actions with the identity of the user submitting the prompt. Service agents (the customer-facing kind on Messaging, Experience Cloud, and web) execute actions with the agent's own identity: the dedicated agent user. Salesforce's developer workshop states the consequence plainly: the agent has access to all of the data and metadata that its running user can see.

Sit with what that means for a service agent. Every anonymous web visitor who opens a chat is, permission-wise, borrowing the same identity as every other visitor. There is no per-customer scoping at the permission layer, because the permission layer sees one user: the agent's. Whatever record scoping happens per conversation has to come from the action design (more on verified identity context below), not from the sharing model. That is why Salesforce's ISV security review treats service agent actions as requiring extra authorization controls, and why the rest of this post is mostly about service agents.

If you have not yet inventoried which agents exist in your org at all, start with Auditing Your Agentforce Footprint and come back; this post assumes you know what is running.

What the wizard actually grants

The folklore version says the setup wizard creates a super-user. The observable version is tighter, and it is worth being accurate because the real problem lives elsewhere.

When you create a service agent, the wizard (or sf org create agent-user, added in Summer '26) provisions a dedicated user, typically named EinsteinServiceAgent User, on the Einstein Agent User profile. Via the Agentforce DX path, it arrives with three standard permission sets: AgentforceServiceAgentBase, AgentforceServiceAgentUser (described as analyzing topics and performing actions as an autonomous AI service agent), and EinsteinGPTPromptTemplateUser for prompt templates. The user has no password and cannot log in through any login page. Salesforce's stated position is that new agents have no permissions and actions inherit from the Apex, flows, and prompt templates they reference.

Object and record access is the part you add. The standard template guidance has you build a custom permission set granting, say, read on Contact and read, create, and edit on Case, scoped to the fields the agent's topics need. Orgs using Data Cloud grounding also assign the permission set group for Data Library access, plus access to the specific data space; miss that and retrieval works in the playground but fails at runtime with insufficient-access errors, which is a useful reminder that the two environments check permissions differently.

So the defaults are close to least privilege. The drift comes later, from three habits: bolting broad permission sets onto the agent user while debugging ("just give it Read All on Account and see if that fixes it"), reusing one agent user or one permission set across multiple agents so every agent inherits the union of all their needs, and, biggest of all, the action layer.

Where over-permissioning actually hides: the action layer

The agent user's permission sets only govern actions that respect user permissions. Two large categories do not.

Flows in system context. Flow agent actions are autolaunched flows, and an autolaunched flow set to run in system context without sharing reads and writes whatever it likes, regardless of what the agent user is allowed to see. Your beautifully scoped permission set is not consulted. Audit the run context of every flow behind an agent action, prefer user context, and treat system context without sharing on an internet-facing agent as a finding, not a convenience. I could not find documentation stating which context agent-invoked flows default to, so check each flow's setting explicitly rather than trusting a remembered default.

Apex below API version 67.0. Historically, Apex database operations ran in system mode unless the developer opted into user mode, which means a 2024-era Apex action happily ignores object permissions, field-level security, and sharing. Summer '26 flipped the default: at API version 67.0 and above, SOQL, SOSL, and DML default to user mode, and a class with no sharing keyword defaults to with sharing. The flip only protects code compiled at 67.0 or above. Every agent action backed by an older class keeps the old behavior until someone bumps the version, so the audit step is concrete: list the Apex classes behind agent actions, check their API versions, and for anything below 67.0, either upgrade and retest or verify it uses WITH USER_MODE explicitly. The wider Summer '26 security changes are covered in Salesforce Summer '26: SAML Single Logout Retirement and Apex Secure by Default.

For guest-reachable service agents there is a third control that operates above permissions: identity scoping inside the action. Salesforce's security review requires private service agent actions to verify customer identity and scope data access through the verified customer context variable, assigned by the platform rather than typed by the user, so that even a fully authorized action can only touch the records of the person actually in the conversation. Internal builds should steal this pattern wholesale: an action that accepts a bare record ID or object name from conversation text is an injection target, which is exactly why the ISV rules ban that shape outright.

The blast radius formula, updated for 2026

The ForcedLeak disclosure (covered in Hardening Agentforce Against ForcedLeak-Style Prompt Injection) established the pattern; April 2026's PipeLeak, from Capsule Security, confirmed it is a class, not a one-off. An attacker submits a public Web-to-Lead form with instructions embedded in a text field. Later, an internal user asks the agent to review the lead. The agent reads the hostile text as part of its task, follows the embedded instructions, retrieves customer relationship management (CRM) data through its lead-information function, and emails it out. Researchers demonstrated bulk extraction; Salesforce characterized the issue as configuration-specific and pointed to optional human-in-the-loop controls.

Read that response carefully, because it assigns you the homework. Configuration-specific means the permission burden is on the org. The formula is: untrusted input surface, times the agent identity's read scope, times any outbound action. You control all three terms, but the middle one is the pure permissions question, and it is the one this post is about. An agent user that can read only the objects its topics need turns "database extraction pipeline" into "the attacker can see one case." The Varonis framing from January 2026 is the right mental model: an over-permissioned agent does not let excess access sit unused the way a human does; when the wrong instruction arrives, everything reachable is reached.

Audit direction one: what can the agent access?

This is ordinary permissions work once you know the identities involved.

Find the agent users:

SELECT Id, Username, Name, IsActive, Profile.Name
FROM User
WHERE Profile.Name = 'Einstein Agent User'

Then their grants:

SELECT PermissionSet.Name, PermissionSet.Label
FROM PermissionSetAssignment
WHERE AssigneeId = '<agent user Id>'

Anything beyond the standard sets and your own purpose-built one deserves an explanation. From there, walk each agent in Agent Builder: note its assigned user, its topics, and every action, then trace each action to its flow (check run context) or Apex class (check API version and sharing keywords). Also check the structural anti-pattern directly: if two agents share one agent user or one permission set, each has the union of both jobs' access, and Salesforce Ben's hardening guidance calls this out as a pitfall worth fixing even when both agents are currently benign.

Because the agent user is a real user, your existing tooling applies. Our sf-audit plugin's permission checks (see sf-audit: 61 Checks, Attack Chains, and Compliance Mapping) treat agent users like any other identity, which is precisely the point: no special AI category, just an account whose grants must justify themselves.

Audit direction two: what has the agent accessed?

Capability is half the picture; behavior is the other half, and the observability surface matured a lot through 2026.

Agent event logs, no Shield required. Agent Builder can log conversation events to the ConversationDefinitionEventLog object once you enable enriched event logging for the agent. That gives you a queryable record of steps, invoked actions, and targets per session, which is enough to answer "what did the agent actually do last Tuesday."

Event Monitoring, if you have it. Two event types earn their keep here. Invocable Action events record which actions were invoked and when, which maps directly onto agent activity. Insufficient Access events record denials, and for a least-privilege setup, denials are good news: each one is evidence the fence held. A service agent generating zero insufficient-access events ever is either perfectly scoped or, more likely, so broadly scoped it never hits a fence. Treat the deny signal as your regression test.

Session tracing. Salesforce's agent observability stack went generally available in stages (agent observability in November 2025, the fuller session tracing and analytics set by February 2026), storing per-turn traces of LLM calls, tool invocations, and guardrail checks in Data Cloud. If you run agents at scale, this is where behavior review moves eventually; for a first audit, the event logs above are enough.

If you are not capturing baseline event logs at all yet, start with Free Salesforce Event Monitoring: Build a Security Baseline from EventLogFile Without Shield; agent activity lands in the same pipeline you build there.

The least-privilege recipe

Pulling it together into the checklist I would apply to any service agent:

One agent, one dedicated agent user, one purpose-built permission set. Never reuse across agents, so each agent's access reads as a statement of its job.
Keep the profile minimal (Einstein Agent User) and put every grant in permission sets, so the whole posture is diffable and reviewable.
Grant objects and fields per topic, not per convenience. The service template pattern (read Contact, read-create-edit Case, named fields only) is the right grain.
Set every agent-action flow's run context explicitly, preferring user context; reserve system context with sharing for narrow, documented cases and refuse system without sharing on anything guest-reachable.
Compile agent-action Apex at API 67.0 or above, or prove older classes use user mode explicitly.
Trim topics and actions you do not need, and never let an action take a raw record ID, object name, or field name from conversation input.
Scope guest-facing actions by the platform-assigned verified customer context, so authorization and identity are checked per conversation, not just per agent.
For Data Cloud grounding, grant the data space deliberately and test retrieval at runtime, not just in the playground.
Wire up the deny signal: enriched agent event logs on, Insufficient Access and Invocable Action events reviewed on a cadence.
Keep a human approval step on destructive or outbound actions (email, record deletion, anything that leaves the org); it is the control Salesforce itself points to when injection research lands.

Frequently Asked Questions

Q: Does the Agentforce agent user respect sharing rules and field-level security?

A: The agent user is a real user, so organization-wide defaults, role hierarchy, sharing rules, and field-level security all apply to it exactly as they would to a human, for any action that runs in user context. The exceptions are the same ones that exist for humans' automation: flows in system context and Apex running in system mode bypass sharing and field-level security regardless of what the agent user is granted. That is why auditing the action layer matters more than auditing the permission sets alone.

Q: Is the agent user a login risk? Could someone sign in as it?

A: The provisioned agent user has no password and cannot log in through a login page, so it is not a credential-stuffing target in the usual sense. It is still a permissioned identity: it appears in sharing calculations, it can own records your actions create, and its grants define what a prompt-injected conversation can reach. Treat it as an attack surface through the agent, not through the login page.

Q: My agent worked in the sandbox but fails with insufficient access errors in production. What do I check?

A: In rough order: the production agent user's permission set assignments match what you tested (the custom object-access set is the usual gap); Data Cloud data space access if the failure is retrieval-related, since the Retriever Playground can succeed while runtime access fails; and the run context of the flow behind the failing action, since a sandbox flow flipped to system context for debugging may have been deployed in user context, or vice versa. An Insufficient Access event in the logs will tell you which object or field was denied, which shortcuts the guessing.

Q: We only run employee agents. Does any of this apply?

A: The identity model inverts but the action-layer risk stays. Employee agents execute as the prompting user, so there is no shared agent user to audit, and a user cannot reach more through the agent than their own permissions allow, provided the actions run in user mode. That proviso is the catch: a system-context flow or pre-67.0 Apex action behind an employee agent lets any user who can talk to the agent operate beyond their own permissions, which is a privilege escalation, not just a data exposure. Audit the flows and Apex the same way.

Key Takeaways

Execution identity first: employee agents run as the human, service agents run as a shared agent user, and everything downstream follows from that split.
The defaults are tight; the drift is yours. Profile plus three standard permission sets plus no data access is the starting point, and debugging-era grants and shared permission sets are how it decays.
The action layer is the real audit target: system-context flows and pre-API-67 Apex bypass the agent user's permissions entirely, and Summer '26's user-mode default only protects recompiled code.
Prompt injection turns read scope into blast radius, so least privilege on the agent user is the one term of the PipeLeak formula that is entirely in your control.
Audit both directions: grants and action contexts for what the agent can do, agent event logs and Invocable Action plus Insufficient Access events for what it did.

What's Next?

Recommended Reading:

Auditing Your Agentforce Footprint
Hardening Agentforce Against ForcedLeak-Style Prompt Injection
Salesforce Connected App Least Privilege: Granted vs Used
Why Your Developers Don't Need Modify All Data for the same granted-versus-needed exercise applied to human delivery roles
Salesforce Summer '26: SAML Single Logout Retirement and Apex Secure by Default

Action Items:

Run the two SOQL queries above, list every agent user and its permission set assignments, and demand a justification for anything beyond the standard sets plus one purpose-built set per agent.
Trace every agent action to its flow or Apex class and record the run context, API version, and sharing keywords; fix system-context flows and pre-67.0 classes on guest-reachable agents first.
Enable enriched agent event logging, and if you have Event Monitoring, add Invocable Action and Insufficient Access events to your review cadence so the deny signal becomes your regression test.

The agent user is, in the end, just an identity whose grants have to justify themselves, and that is a solved audit problem. Our open-source sf-audit plugin (sf plugins install @cclabsnz/sf-audit) runs read-only permission and configuration checks across exactly this kind of identity, and the footprint audit post shows the inventory pass that should precede any hardening. If you would rather have your Agentforce surface reviewed end to end, from agent users to action contexts to the event trail, that is what CloudCounsel does day to day.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.