3.2 Security Context: Who the Agent Runs As and How It Affects Actions
Key Takeaways
- Service agents run as the agent user for unidentified and identified-but-not-logged-in customers, and as the logged-in site user for authenticated Experience Cloud users.
- A new agent user gets the Einstein Agent license, the Einstein Agent User profile, internal OWD, and minimal permission sets by default.
- Object permissions for an agent user are managed in the [Agent_Name]_Permissions permission set; record access comes from role, sharing rules, and internal OWD.
- Employee agents in Lightning Experience, mobile, Slack, and Enhanced Web Chat on Experience Cloud run with the logged-in user's access controls.
- Retrievers and grounding respect the running user's access, so records the running user can't see don't appear in results.
3.2 Security Context: Who the Agent Runs As and How It Affects Actions
Quick Answer: Every agent action runs as someone. Employee agents (and agents serving authenticated Experience Cloud site users) run as the logged-in user, so that user's profile, permission sets, field-level security, and sharing apply. Service agents on channels open to the public run as a dedicated agent user (EinsteinServiceAgent User), so that user's permissions determine what every customer conversation can read and change. Most "the agent can't see the field" and "the agent exposed too much" questions come back to this.
The Rule Behind the Design
Salesforce's principle is simple:
- Channels restricted to logged-in users (Lightning Experience, the Salesforce mobile app, Slack, Enhanced Web Chat on an Experience Cloud site) → the agent operates in the context of the logged-in user, and that user's access controls apply. Assign permissions to individual users or profiles.
- Channels not restricted to logged-in users (Enhanced Chat and other messaging channels) → the agent operates as an agent user, a Salesforce user record with the permissions the agent needs. Assign permissions to the agent's user record.
Service Agent Access by End User Type
| Unidentified end user | Identified (verified) end user | Authenticated user | |
|---|---|---|---|
| Example | Anonymous FAQ chat | Customer with a contact record who passed a one-time passcode check but isn't logged in | Customer logged in to an Experience Cloud site with a user record |
| Runs as | Agent user (EinsteinServiceAgent User) | Agent user (EinsteinServiceAgent User) | Logged-in site user |
| Data access governed by | Agent user's profile, permissions, FLS, sharing; internal OWD apply | Same as unidentified | Site user's profile, permissions, FLS, sharing. OWD depend on internal vs. external user |
| User identified by | N/A | Context variables such as MessagingSession.ContactId, which identify the user but don't control access | The logged-in site user |
The authenticated column applies to Enhanced Chat and Experience Cloud sites with credential-based user verification enabled.
What a New Agent User Looks Like
When you create a Service agent, you create or select an agent user. Salesforce creates it secure by default:
| Property | Default value |
|---|---|
| Name | EinsteinServiceAgent User |
| User license | Einstein Agent |
| Profile | Einstein Agent User |
| Org-wide sharing defaults | Internal |
| Permission sets | Agentforce Service Agent Secure Base, [Agent_Name]_Permissions |
| Permission set group | AgentforceServiceAgentUserPsg (Agentforce Service Agent User, Data Cloud User, and Prompt Template User permission sets) |
| Permission set licenses | Agentforce Service Agent User, Data Cloud, Einstein Prompt Templates |
Only admins can view or edit agent users. The generated user has no password and can't be used to log in interactively.
Granting the Agent User What It Needs (and Nothing More)
- Object access. Give the minimum object permissions for each object the agent touches through flows, Apex, or prompt templates. Manage them in the [Agent_Name]_Permissions permission set. A different permission set must be associated with the Einstein Agent license and Einstein Agent User profile. Agents on Enhanced Messaging also need access to the Messaging Session object.
- Record access. Assign a role that reaches only the records needed, and use sharing rules. Because internal OWD apply to the agent user, restrictive internal OWD limit exposure.
- Field access. If the agent user can't read a field through FLS, grounding and actions can't return it.
- Action access. Add Run Flows or specific flow access, Apex Class Access, Prompt Template User, and for Knowledge and Data 360: Allow View Knowledge, Access Conversation Entries, Data Cloud User, and data category visibility.
- Review in the builder. The Agent Access page shows the agent's user record and its permission sets and groups.
Never give the agent user agent-management permissions, and avoid broad permissions such as View All Data or Modify All Data. With them, every anonymous chat inherits that access.
Scoping Customer Data When Running as the Agent User
Because every customer conversation runs as the same agent user, you must scope private data to the verified customer:
- Verify identity with the standard Customer Verification subagent (or a custom action) and store the ID in
VerifiedCustomerId. - Add a filter (
VerifiedCustomerId is not None) to subagents and actions that expose private data. - Check the verified ID inside the flow or Apex, for example
WHERE ContactId = :verifiedCustomerId. Some standard actions do this already. Get Cases for Verified Contact checks the contact againstVerifiedCustomerIdbefore querying.
How the Security Context Changes Action Execution
| Situation | What happens |
|---|---|
| Employee agent runs Update Record for a rep without edit access | The action fails for that rep, the same as if they edited the record manually |
| Service agent flow queries a custom field missing from the agent user's FLS | The value isn't returned, and the agent can't use it |
| A flow configured to run in system context without sharing is called by a Service agent | The flow can read records the agent user couldn't otherwise see, so review run modes carefully |
An Apex action is declared without sharing | Record sharing is bypassed; prefer with sharing and user-mode queries such as WITH USER_MODE |
| A retriever returns chunks from records the running user can't access | They're excluded, because retrievers apply row-level access checks |
| An Employee agent is used in Slack | It respects the user's Salesforce licenses, permissions, and access controls |
Multi-Agent Solutions (Preview of Chapter 10)
When one agent delegates to another in the same org, the running user follows documented rules. An Agentforce Service agent orchestrator passes its session user to Service agent connected subagents. An Employee agent orchestrator's Employee agent subagents run as the logged-in user. A Service agent connected to an Employee agent orchestrator runs as its own agent user.
Exam Traps
- Context variables aren't authorization. A Contact ID in the session doesn't limit what the agent user can query.
- Adding permissions to the customer does nothing for anonymous Service agent chats, because the agent user is the running user.
- Fix missing data with least-privilege FLS, object, or sharing changes, not by assigning System Administrator or View All Data.
- Testing reflects production. In the legacy builder, Salesforce notes a Service agent operates as the same agent user in the builder as on messaging channels, so design-time tests reveal permission gaps.
An anonymous website visitor chats with an Agentforce Service agent on Enhanced Chat. Whose permissions govern the data the agent's actions can access?
A Service agent can't return a custom Warranty_Expiration__c field that human reps can see. The field is populated. What is the most likely fix?
A customer who is identified by MessagingSession.ContactId asks a Service agent for their open cases. Which design keeps other customers' cases private?
An Agentforce Employee agent is deployed in Slack. How does it determine what Salesforce data a user can access?