Secure Your Agentforce Custom Actions

Custom Action Classification

In your managed package documentation, classify all custom actions. Indicate what type of agent the action is intended to be used with. Also indicate whether the action returns public or nonpublic data. These classifications help customers understand how to use the actions, and manage user access securely.

Identify whether the custom action is designed for use with employee-facing or service agents.

• Employee-facing agent: Users authenticated within a Salesforce org can access the agent from within the Salesforce application. Employee-facing agents include Agent for Setup and SDR. See Agent Types and Considerations in Salesforce Help.

• Service agent: The Salesforce org owner’s customers can access the agent, typically via customer channels such as email and messaging. For example, a service agent exposed to customers on an Experience site.

Also, classify the action as public or private.

• Public: The action returns public data and is appropriate for unauthenticated access.
• Private: The action returns nonpublic data or results in sensitive operations, such as creating, deleting, or altering records in a Salesforce org. At a minimum, require user verification and grant access to private actions to verified users only. Any additional authentication requirements are subject to a customer’s risk tolerance based on the data the action returns and the sensitivity of the action.

Exercise caution when developing private actions that are accessible to external users, such as through a service agent. Improper authentication and authorization can create security vulnerabilities that lead to unintentional data access and exposure. To protect against this, follow the requirements in Authentication and Authorization for Custom Actions.

Authentication and Authorization for Custom Actions

When an agent invokes a flow or Apex code, the identity used to execute the action depends on the type of agent the action is assigned to. If an employee-facing agent invokes the action, the identity of the user that submitted the prompt to the agent is used to execute the action. If a service agent invokes the action, the identity of the agent is used to execute the action. As a result, extra care is required by the flow or Apex code that the action invokes to ensure that the end user is authorized to access nonpublic data or alter data within the Salesforce org.

All public and private custom actions must implement:

• Proper flow execution context that aligns with security considerations for flow design.
• CRUD, field-level security (FLS), and record-level (with sharing) access checks. See Apex Security and Sharing.

Custom Actions and Generic User Inputs

Custom actions that accept generic record references, record IDs, object names, or field names as user-controlled input aren't allowed. To prevent direct user control, disable user input when you configure the action.

In Setup, when you create a custom action, disable Collect data from user for fields that accept generic user inputs. See Create a Custom Action for Agents.

In the schema.json metadata file, for any inputs that contain record references, record IDs, object names, or field names, set the copilotAction:isUserInput property to false.

Here’s an example schema.json for an action input configuration. Notice that the copilotAction:isUserInput value is false.

1"contactId" : {
2     "title" : "contactId",
3     "description" : "The Id of the contact that will be used to create the related booking.",
4     "lightning:type" : "lightning__textType",
5     "lightning:isPII" : false,
6     "copilotAction:isUserInput" : false
7   }
8

Private Custom Actions for Service Agents

Private custom actions for service agents have additional authorization and access-control security requirements beyond those for all custom actions.

At a minimum, a private custom action that's designed for use by service agents, must:

• Require a verified customer identity.
• Use the verified customer identity to scope all data accessed by the action.

User identity verification is the process of confirming a user's identity on the basis of specific identifiers such as a one-time password or an email address plus a private, user-identifiable attribute. Implement a verification method that’s appropriate for the level of sensitivity associated with the action.

We recommend using the out-of-the-box Customer Verification topic in Agentforce to verify a user based on their email address and a one-time-password sent to that address. However, for actions that are private, but not considered sensitive enough to require one-time password verification or authentication, you can take a different approach. Use their email address and a private piece of information unique to them to identify them as a customer and let them access certain actions. See Control Agent Access and Decision-Making with Variables and Filters.

In both approaches, an ID for the verified customer is stored in the VerifiedCustomerId context variable for the agent. This variable is then required as an input value to each private custom action. The action uses it to determine what data the user can access. The action must prohibit users from viewing or altering data that isn’t associated with their verified customer identity. See Agent Variables.

To implement a custom action that properly authorizes access based on the user’s verified customer identity, the action must:

• Provide the VerifiedCustomerId context variable as an input value. Configure this input value so that it’s sourced from the context variable using the Assign a Variable input parameter option within Agent Builder.
• Validate that the VerifiedCustomerId is a non null value that maps to a customer identity within the Salesforce org. If using the out-of-the-box Customer Verification topic, the customer identity is either a User or Contact record. If you’re not using this topic, the record type can vary.
• Associate all data accessed, altered, or returned by the custom action with the user’s identity based on the VerifiedCustomerId.
• Prevent users from accessing or altering any data not associated with their verified customer identity.

Generating Content with Prompts

To securely generate content using Agentforce, send a prompt to the large language model (LLM) with instructions. There are multiple ways to do this. Choose the best content-generation method for your use case.

• Use prompt templates that a custom action, Apex, or flow can invoke.
• Directly invoke the Models API to generate content based on a supplied prompt. You can access Models API with Apex or the Models REST API.

When choosing an LLM to use with these methods, consider your requirements for supported features, context window size, cost, and adversarial robustness. See Supported Models.

Generated Content Output Safety in Apex and Flows

Treat all content that’s generated with prompt templates or the Agentforce Models API in your Apex code or flows as untrusted. This is especially important if the generated content serves as input for other code procedures or visible to a customer in a custom user interface, such as a Lightning Web Component or VisualForce page.

If your flow component or Apex code uses an LLM to generate content that’s used in a downstream flow component or Apex code, validate the content before processing it. Ensure it meets an expected format and value constraint. Length, character set, and integer value bounds are examples of value constraints. Instruct the model to generate structured output, such as JSON, to facilitate parsing and processing.

For example, your Apex code uses the Models API to retrieve the ID of a record from text that’s included in a prompt. Before using the ID for additional operations, such as data manipulation language (DML), SOQL, or other code operations, validate that the ID in the response is in an expected format. In this example, validate that it’s an 8 or 15 character Salesforce ID that contains allowlisted characters only.

If the content generated from an LLM is displayed to users in a custom user interface, make sure the data is properly output encoded. Use a mechanism that’s appropriate for the user interface framework. For example, use sufficient escaping when embedding content in a Lightning web component.

For more information about output handling for LLM-generated content, see LLM05: 2025 Improper Output Handling - OWASP Top 10 for LLM & Generative AI Security.

Logging

Don’t log Agentforce prompts or responses from the agent. Avoid using System.debug or other logging methods with prompts and generated responses.

If logs are needed, enable enhanced event logs in Agent Builder. These logs capture the events in an agent session. You can use them to help test and troubleshoot your agent.

Restricted Functionality

Actions that alter the Einstein Trust Layer settings of a Salesforce org aren't allowed in managed packges.

Third-Party Service Integrations

Third-party service integrations in Agentforce custom actions must meet the same security requirements as a third-party service integration in AppExchange managed packages. For clarification on what integrations are considered in-scope for this requirement, review Test Your Entire Solution.

Integrations with third-party LLM services, such as OpenAI and Google, aren't allowed. Use Agentforce’s solutions instead.

User Confirmation for Data Modification and Action Invocation

For custom actions that alter customer org data or invoke sensitive actions such as sending emails on the user’s behalf, always have the agent prompt the user for confirmation before proceeding. This gives the user an opportunity to validate the planned action before it’s executed and prevents excessive agency as defined by OWASP. Excessive agency can lead to unintended or accidental data changes and actions.

To implement user confirmation for a custom action in Agent Builder, enable Require user confirmation for the action. This code shows how to turn on user confirmation via the metadata for the GenAiFunction definition. Notice that the isConfirmationRequired value is true.

1<?xml version="1.0" encoding="UTF-8"?>
2<GenAiFunction xmlns="http://soap.sforce.com/2006/04/metadata">
3   <description>Provides details about an Experience__c that a user would like more information
4       about.</description>
5   <invocationTarget>Get_Experience_Details</invocationTarget>
6   <invocationTargetType>flow</invocationTargetType>
7   <isConfirmationRequired>true</isConfirmationRequired>
8   <isIncludeInProgressIndicator>false</isIncludeInProgressIndicator>
9   <masterLabel>Get Experience Details</masterLabel>
10</GenAiFunction>