Agentforce agent access
Key Takeaway
An Employee agent runs as the logged-in user, and you choose who can use it by enabling it for permission sets or profiles. A Service agent usually can't rely on the end user's user record, so it runs as a dedicated agent user that starts with minimal access, which you expand using the principle of least privilege.
Agentforce agent access answers two questions: who is allowed to use an agent, and what data the agent can see and change while it works. The answer depends on the agent type. Some agents run as the person using them. Others run as a dedicated user record that the admin must configure and lock down.
Execution context by agent type
Each agent type serves different people and runs in a different execution context, which means it runs as a different user:
| Serves | Runs as | |
|---|---|---|
| Agentforce Employee agent | Internal employees | The logged-in end user |
| Agentforce Service agent | External customers and partners | A dedicated agent user (EinsteinServiceAgent User) |
| Agentforce Lead Nurturing agent | Leads and prospects, through automated outreach by outbound email | A dedicated EinsteinSDRAgent User |
An Employee agent runs as the logged-in end user. That user's profile, permission sets, field-level security, and sharing rules decide what the agent can do, so you don't need to scope its queries to user-specific data.
A Service agent works over enhanced Messaging channels, such as Enhanced Chat. These channels allow unauthenticated users, so the agent usually can't rely on the end user's user record. Instead, it runs as the agent user. The agent user's profile, permissions, field-level security, and sharing rules govern data access.
For a Lead Nurturing agent, agent setup creates the EinsteinSDRAgent User and gives it system-level permissions. Assignment rules, automated actions, or individual sales users assign prospects to the agent.