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?
The agent user's profile, permission sets, FLS, and sharing
The website visitor's guest user profile in Experience Cloud
The permissions of the admin who last activated the agent
No permissions, because anonymous visitors have no user record
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?
Assign the System Administrator profile to the agent user record
Add a stronger instruction telling the agent to read that field
Grant read field-level security on the field to the agent user
Give the customer's contact record read access to the custom field
A customer who is identified by MessagingSession.ContactId asks a Service agent for their open cases. Which design keeps other customers' cases private?
Rely on MessagingSession.ContactId, which automatically limits the agent user's queries
Give the agent user View All Data so it can find the customer's cases more reliably
Store VerifiedCustomerId, filter the action on it, and check it in the flow or Apex
Tell the agent in its instructions never to show cases that belong to other customers
An Agentforce Employee agent is deployed in Slack. How does it determine what Salesforce data a user can access?
It runs as the EinsteinServiceAgent User for every Slack user it helps
It uses the Salesforce permissions of the Slack workspace administrator
It respects the user's Salesforce licenses, permissions, and access controls
It can access all org data because Slack is treated as an external channel
Sections you finish are checked off in the contents.