Study guide
3.2 Security Context: Who the Agent Runs As and How It Affects Actions
Salesforce Certified Agentforce Specialist Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & How Agentforce Agents Work
1.1 Agentforce Specialist (AI-201) Exam Facts & Spring '26 Blueprint 1.2 How an Agent Works & the Building Blocks of Agent Script 1.3 Hybrid Reasoning: Agent Script in Canvas View and Script View
2 Chapter 2: Deterministic Control, Topics (Subagents) & Actions
2.1 Deterministic Behavior: Filters, Variables & Template Expressions 2.2 Standard and Custom Topics (Subagents) 2.3 Standard and Custom Agent Actions
3 Chapter 3: Agent Types, Security Context, Channels & Agent API
3.1 When to Use an Employee Agent or a Service Agent 3.2 Security Context: Who the Agent Runs As and How It Affects Actions 3.3 Connecting Agents to Channels: Digital Experiences, Email, Voice & Slack 3.4 When to Use the Agent API
4 Chapter 4: Prompt Builder Fundamentals
4.1 When to Use Prompt Builder 4.2 Access Controls Governing Prompt Templates 4.3 Prompt Template Types: Field Generation, Flex & More 4.4 Creating, Activating & Executing Prompt Templates
5 Chapter 5: Grounding, Prompt Best Practices, Trust Layer & Model Access
5.1 Choosing the Right Grounding Technique 5.2 Best Practices for Writing Effective Prompts 5.3 Einstein Trust Layer Security and Privacy Features 5.4 Managing and Preventing Access to Specific Models
6 Chapter 6: Data 360 Fundamentals for Agentforce
6.1 Agentforce Data Library: Types and Concepts 6.2 Chunking: Breaking Content Into Retrievable Units 6.3 Indexing and Search Types: Vector, Hybrid & Keyword 6.4 Retrievers: Individual, Ensemble & Filtered Retrieval
7 Chapter 7: Testing Agents with Testing Center
7.1 Testing an Agent with Testing Center 7.2 How Testing Center Evaluations Work
8 Chapter 8: Deploying Agents and Prompt Templates
8.1 Deploying an Agent from Sandbox to Production 8.2 Deploying Prompt Templates from Sandbox to Production
9 Chapter 9: Governance and Observability
9.1 Managing and Monitoring Agents 9.2 Agent Analytics and Agent Optimization
10 Chapter 10: Multi-Agent Orchestration, MCP & A2A
10.1 When a Multi-Agent Architecture Is Appropriate 10.2 Open Multi-Agent Protocols: MCP and A2A
3.2 Security Context: Who the Agent Runs As and How It Affects Actions
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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 against VerifiedCustomerId before 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
Loading diagram... Which user's permissions apply?
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.