Agentforce security and data access
Key Takeaway
The key security question for any agent is which user's access it uses. An Employee agent runs as the logged-in user, while a Service agent usually runs as a dedicated agent user.
Agentforce agents read and change Salesforce data, so they follow the same access controls people do. The Einstein Trust Layer adds protections such as zero data retention and prompt injection defense.
Whose access an agent uses
AI agents respect standard Salesforce access controls, such as:
- Licenses
- Permissions
- Field-level security
- Sharing settings
The agent type, the channel and whether credential-based user verification is turned on decide whose user record supplies that access.
| Agent type | Who it's for | Runs as | What governs its access |
|---|---|---|---|
| Employee agent | Internal users in Lightning Experience, the Salesforce mobile app, Slack or an Experience Cloud site, not unauthenticated external customers | The logged-in user | That user's profile, permission sets, field-level security, sharing rules and role |
| Service agent | External customers and partners on enhanced Messaging channels | Usually a dedicated agent user (EinsteinServiceAgent User) | That user's profile, permissions, field-level security and sharing rules |
| Lead Nurturing agent | Leads, prospects and customers, through automated outbound email | A dedicated EinsteinSDRAgent User | That user's profile, permissions, field-level security and sharing rules |
With an Employee agent, you don't need to scope queries and actions to the user's own data, because the agent already runs as that user.
The enhanced Messaging channels that Service agents use support both authenticated and unauthenticated users. Because these channels aren't limited to logged-in users, a Service agent usually can't use the end user's user record, so it runs as the agent user instead.
Agent setup creates the EinsteinSDRAgent User and assigns it system-level permissions.