Maintain Trust with Agentforce Actions in the Legacy Builder
Agents connected to employee channels, such as Lightning Experience, the Salesforce mobile app, and Slack, limit access to subagents and actions by default, based on the end user's context. Agentforce Service agents connected to customer channels, such as enhanced Messaging channels and Enhanced Chat, require additional configuration to ensure secure access. As you configure your agent, it's important to think through the security and identification requirements for your use case and only grant your agents the actions and access required to complete the tasks you want them to be able to complete autonomously on behalf of your customers. For sensitive actions, we recommend building customer verification directly into the action’s flow.
Required Editions
| Available in: Lightning Experience |
| Available in: Enterprise, Performance, Unlimited, and Developer Editions. Required add-on licenses vary by agent type. |
You have full control over the actions that your agents can take, so you can tailor your customer experience to your needs. To enhance security and ensure that agents operate within defined boundaries, we recommend:
- Assigning agents that connect to customer channels the minimum user permissions required to do their job.
- Building identity confirmation and access control directly into the flow of sensitive actions.
Every company’s risk tolerance and security standards are unique, and there’s no one way to incorporate identity verification into your agent implementation. For instance, depending on your company policy, you might allow an Agentforce Service agent to accept order IDs conversationally and provide order statuses without requiring any formal identity verification beyond that. However, if your business requires shipping sensitive or regulated materials, you might require customers to authenticate themselves before looking up order information on their behalf. Consider your company’s risk tolerance and security standards before configuring your agent. To prevent agents from sharing data outside the intended scope, configure them with authentication and authorization in mind.
Agentforce Actions and Security
When your agent is connected to customer channels, think of agent actions as either public or private. While Salesforce doesn’t have a specific setting to designate actions as public or private, this framework helps you conceptualize and implement your company’s security standards.
- Public Actions
- Public actions are actions that your company is comfortable taking on behalf of anyone, regardless of identity, without authentication. For example, the Answer Questions with Knowledge action is usually considered a public action, especially if it’s grounded in public information such as return policies. Looking up an order can also be a public action if you’re comfortable doing so without securely confirming the requester's identity. In such cases, the information required to identify a specific order, such as the order ID or email address, can be passed conversationally.
- Private Actions
- Private actions require the requester’s identity to be confirmed according to your company’s comfort level; for example, through authentication or through the sharing of identifying information in a messaging session. Updating personal appointment information, making purchases, or requesting services on a support contract are typically examples of private actions, and we don't recommend making them public. For an Agentforce Service agent to complete a private action, the user triggering the action must be authorized to access the action, and their identity should be securely confirmed.
Guidelines for Securely Implementing Private Actions
To enhance the security of agents connected to customer channels, it's best practice to require agents to confirm the identity of the person they’re interacting with before they take a private action on their behalf.
For particularly sensitive actions, we recommend confirming identity using techniques such as two-factor authentication, which handle the authentication process outside the scope of the conversation. Sharing identifying information within the chat isn't a secure verification method, but the approach you choose depends on your risk tolerance and security standards.
After a customer's identity has been confirmed, the identifying information can be saved in the associated MessagingSession record. Before completing any private action, the agent can reference the MessagingSession record to confirm the identity and permissions of the person it's interacting with. This process can be built directly into the flow of private actions.
When building an agent that connects to customer channels and can take private actions, it’s crucial to consider how to mitigate risk. While all use cases are different, keep these guidelines in mind.
Organization-wide sharing defaults (OWD) determine what access users have to records they don’t own. In an agent session with an authenticated user, the session runs in the end user’s context and OWD depend on whether the user is external or internal. In an agent session with an unauthenticated user, the session runs in the agent user’s context and OWD for internal users apply.
Carefully review your OWD, your agent user’s permissions, and your agent configuration to ensure the right record access for your end users and your business.
- For all agents that use the agent’s user record, we recommend using filters and variables to limit record access at the subagent and action levels. This strategy protects sensitive data regardless of your OWD.
- You can restrict your OWD for internal users to limit record access for all internal users. Then you can create sharing rules to selectively grant access, excluding the Einstein Agent User where appropriate.
Next Steps
Learn how to build user authentication into your private agent actions, including with the Customer Verification standard subagent.
- Add User Identification to Agentforce Actions
When configuring your agent that connects to customer channels so that it can take private actions securely, have it confirm the identity of the person it’s interacting with according to your company’s standards. - Verify Customers with Standard Subagents in the Legacy Builder
Before an Agentforce Service agent takes a private action on a user’s behalf, Salesforce recommends verifying the identity of the person the agent is interacting with. To verify the identity of an unverified user in an agent session, configure your agent to use the Customer Verification subagent or the Service Customer Verification subagent and limit access to subagents and actions that you specify. You can require different levels of verification for different subagents and actions, based on your business’s security requirements. - Example Implementation of a Secure Agentforce Service Agent
The details of implementing secure Agentforce Service agents vary depending on where the agent is deployed and the surrounding user authentication policies. To get a feel for the underlying patterns, let’s look at an example.
