Who Is Responsible When an Agentforce Agent Acts for Your Business?

What you can decide after checking the facts

Instead of a general statement that AI is safe or unsafe, aim for a documented decision: which information may enter Salesforce Agentforce, who is allowed to invoke it, what evidence supports the arrangement, and which exceptions should trigger human escalation. The result may be approval with conditions, a redesigned process or postponement until more facts are available.

• Understand which Salesforce Agentforce service and business arrangement you are actually using.
• Identify practical protections for agent-initiated case updates, customer messages and actions.
• Decide which contracts, permissions and workflows need attention before relying on the system.

Why this assessment is different

The analysis starts with Salesforce Agentforce, the concrete workflow and the governing source documents. A product-specific matrix compares who controls information, who can perform actions, what the provider says in its current materials, and which gaps require evidence from the customer. It avoids treating the existing Agentforce customer-data access page as interchangeable with this service.

How an enquiry and review could work

A suitable first step is to identify the account or product, the proposed user activity, the information categories and the business decision. The next step is to assemble the terms and available technical settings, then map permissions, records, safeguards and unresolved questions. Any specialist testing or jurisdiction-specific advice requires a separately qualified review.

Suggested enquiry: Need a clear decision about this workflow? Send the product, sample data categories and relevant agreement or settings.

Questions, documents and safeguards to review

The following sections distinguish published provider statements from the organization-specific facts still needed. Each question should be answered for the actual version and deployment rather than for a generic model family.

When does an Agentforce agent act for the customer?

Begin with the specific customer journey: does the agent answer a question, create a case, issue an update or change an account? Not every response is a legally meaningful act, and not every automation uses the same user identity. A responsibility analysis should map actions to their business consequence and the person or organization authorizing them.

Treat the question as a user-outcome test: who will be affected if the setting or contractual assumption is wrong, and which person can approve the alternative? For Salesforce Agentforce, capture the specific step before and after the AI interaction so the company can distinguish processing by the provider from later internal use.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

Which user identity applies to actions?

Salesforce documentation identifies agent user permissions and controls on standard actions. The agent’s assigned identity, object access and permitted flows determine what it can do. Review whether identity is established for an external customer before a private action. Do not assume the agent inherits every administrator permission or that all activities run under the chat participant.

The analysis should identify both the expected route and a foreseeable exception, such as an externally shared file, optional logging, a contractor account or a changed feature. Record whether the exception requires a prohibition, an access change, a human checkpoint or additional legal review. Avoid promising the absence of risk.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

Which tasks require human approval?

Separate information-only actions from actions affecting customer records, refunds, contracts or access rights. Salesforce provides methods to identify users and constrain secure actions; a business should define its own approval threshold. A human approval control must be represented in the actual process, not simply as a promise in a policy document.

Prepare a short supporting record with the responsible owner, source reviewed, product configuration, any sample output and a decision to permit or restrict the activity. If the facts are unknown, mark the conclusion unresolved. This is especially important where commercial or professional promises depend on documentation rather than an informal demonstration.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

Who records decisions and changes?

For changes that matter, record the initiating request, agent identity, authorized action, affected record and available reviewer evidence. The platform and connected automation tools may generate different logs, and the business should know which one is authoritative. A dispute process is harder when decision evidence cannot be linked to an individual customer interaction.

For this point, compare the supplier’s published position with the service and account version. Ask which statement is a product-level commitment and which remains conditional on features the company selected. A useful evidence item is a dated administrative export or architectural note, not an unsupported recollection of a settings screen.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

What third-party integrations perform actions?

A Salesforce agent may invoke flows, Apex or third-party integrations whose service accounts have different permissions. The contract and risk review must follow that chain beyond the Agentforce interface. If an integration triggers an outside message, service request or identity change, identify the party controlling that downstream action and its error recovery path.

Treat the question as a user-outcome test: who will be affected if the setting or contractual assumption is wrong, and which person can approve the alternative? For Salesforce Agentforce, capture the specific step before and after the AI interaction so the company can distinguish processing by the provider from later internal use.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

Which contract allocates agent errors?

Supplier terms may address availability, warranties and platform responsibility while the business remains accountable to its own customers for agreed services. Review indemnity, data use, limitations and support arrangements without asserting a universal liability allocation. The actual customer-facing promise, jurisdiction and causation would influence any legal conclusion.

The analysis should identify both the expected route and a foreseeable exception, such as an externally shared file, optional logging, a contractor account or a changed feature. Record whether the exception requires a prohibition, an access change, a human checkpoint or additional legal review. Avoid promising the absence of risk.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

How is a customer complaint handled?

A useful complaint workflow includes a human contact, access to relevant records, a means of correcting incorrect changes and an incident owner. For sensitive actions, the business should decide when an agent must stop and escalate. Treat mistaken advice, unauthorized data disclosure and incorrect account modifications as potentially different problem types.

Prepare a short supporting record with the responsible owner, source reviewed, product configuration, any sample output and a decision to permit or restrict the activity. If the facts are unknown, mark the conclusion unresolved. This is especially important where commercial or professional promises depend on documentation rather than an informal demonstration.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

What differs from record-access rules already covered?

The existing Agentforce customer-data page addresses what information can be accessed. This proposed page instead examines what an agent is authorized to do, on whose behalf and who responds to mistakes. That difference must be preserved throughout copy and finally tested against the old page, otherwise the two pages should be consolidated.

For this point, compare the supplier’s published position with the service and account version. Ask which statement is a product-level commitment and which remains conditional on features the company selected. A useful evidence item is a dated administrative export or architectural note, not an unsupported recollection of a settings screen.

Primary supporting references: Salesforce: secure actions and user identification; Salesforce: permissions for standard agent actions.

Common follow-up questions

Does using the enterprise version automatically make the workflow compliant? No. Contract and security controls are important, but applicable rules, permissions and the end use still require analysis.

Can the review approve every future AI feature? No. Changes to providers, model releases, connected tools, information categories or countries can change the answer.

What information should we send first? The product or service name, intended users, a redacted workflow, the types of records affected and the agreement or policy being relied on. Do not send secrets or unnecessary personal data in an initial enquiry.

Related business and technology guides

• U.S. AI Law and AI Governance
• AI Governance Consulting for U.S. Technology Companies
• What Customer Data Can Salesforce Agentforce Access?
• Who Is Responsible When Your AI Agent Uses Another Provider?