Identity verification in sensitive agent actions
Key Takeaway
A Service agent usually runs as the agent user, not as the customer. So before a private action, verify the customer, store the trusted ID in VerifiedCustomerId, and use that ID to limit the action to that customer's records.
Identity verification is how a Service agent confirms who a customer is before it runs a sensitive (private) action for them. It matters because a Service agent usually runs as a dedicated agent user, not as the customer it is chatting with. Verification gives the agent a trusted customer ID, which it uses to limit each private action to that customer's own records.
Whose identity runs an agent's actions
The agent type decides whose identity runs an action.
| Agent type | Runs as |
|---|---|
| Employee agent | The logged-in employee |
| Lead Nurturing agent | The dedicated EinsteinSDRAgent User |
| Service agent | The agent user (EinsteinServiceAgent User), unless credential-based user verification is turned on |
Because an Employee agent runs as the logged-in employee, these settings for that employee already limit the agent:
- Profile
- Permission sets
- Field-level security
- Sharing rules
As a result, an Employee agent's queries don't need extra scoping to the user.
When a Service agent runs as the agent user, the agent user, not the customer, is also the running user of any flow that an action calls. Both the flow's run context and the agent's execution context apply to that flow.
Credential-based user verification is a different model for Service agents deployed to Experience Cloud sites through Enhanced Chat. When it is turned on, the agent runs as the logged-in site user. The agent then respects these settings for that site user instead of the agent user's:
- Profile
- Permissions
- Field-level security
- Sharing rules