Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Salesforce Agentforce Need Human Approval Before Taking Action?

Only when the builder asks for it: Salesforce recommends that custom actions prompt the user for confirmation before proceeding, but the setting is per action and the person confirming is whoever is in the conversation, not a named reviewer. Check which actions require confirmation, who the confirming party is, and what the session trace records afterward.

Several action routes converge at a single round approval point before reaching an agent-control node.

Only when the builder asks for it: Salesforce recommends that custom actions prompt the user for confirmation before proceeding, but the setting is per action and the person confirming is whoever is in the conversation, not a named reviewer. Check which actions require confirmation, who the confirming party is, and what the session trace records afterward. The question sounds like it should have a platform-level answer, and it does not. Whether a given action pauses for a human is a property of that action's configuration, set one action at a time. Salesforce's guidance is clear about what it recommends, and equally clear, read carefully, that the recommendation is a builder's choice, that the confirming person is the user in the chat, and that the platform's record is a trace written as the run proceeds rather than a gate in front of it. This page separates four things the phrase "human approval" blurs together: whether a pause exists, who the human is, whether that human can judge the action, and what evidence remains. It then sets the answer against the risk literature and against how other frameworks structure approval, and closes with what a buyer should verify. The general pattern is the one described in human-in-the-loop approval for AI agents: a confirmation prompt and a governed approval are not the same control.

Key findings

  • Salesforce's ISVforce guidance recommends that builders always have the agent prompt the user for confirmation before proceeding, through the isConfirmationRequired setting on a custom action (Salesforce, 2026).
  • The same guidance states that service agents run as the agent's identity, so custom action code must check end-user authorization itself; the person confirming is not automatically the person the system authorizes (Salesforce, 2026).
  • Salesforce's session tracing export is described as capturing every step of an agent interaction: turns, messages, LLM calls, actions, metric scores and feedback (Salesforce, 2026).
  • The OWASP Top 10 for LLM Applications names excessive agency, where an agent has more permission or autonomy than its task requires, as a distinct risk category (OWASP, 2025).
  • Microsoft's AI Red Team catalogs failure modes specific to agentic systems, including failures that arise when agents act on their own outputs without a check (Microsoft AI Red Team, 2025).
  • A confirmation prompt to the person in the conversation is a different control from an approval by a named reviewer with the authority and context to refuse (What Is AI Agent Action Governance?).

Where does human approval live in an Agentforce agent?

It lives in the action, not the platform. Salesforce's ISVforce guidance on securing custom actions recommends that builders always have the agent prompt the user for confirmation before proceeding, and names the mechanism: the isConfirmationRequired setting on the action (Salesforce, 2026). Three features of that sentence carry the answer. It is a recommendation, which means the platform allows actions without it. It is set per action, which means a single agent can have some actions that pause and others that do not. And it is a prompt to "the user," which identifies the confirming party as whoever is in the conversation.

Consider a single record type: a customer account record in a service console, with a billing address, a payment method on file and an open order. An agent is built with three actions: look up order status, update the billing address, and issue a refund to the payment method. The builder sets confirmation on the refund action because it moves money, leaves it off the address update because it seemed routine, and never considers it for the lookup. The agent is now a system in which a human step exists for one of three actions, and the existence of that step depends on a judgment the builder made during configuration, not on any property of the action the platform recognized.

Whether a platform-wide requirement exists, such as a setting that forces confirmation on every action that writes a record, is not described in the pages reviewed. What is described is the per-action setting and the recommendation to use it. A buyer who hears "Agentforce requires human approval" should translate the sentence: the builder of this agent may have required confirmation on some actions, and the inventory of which ones is the answer.

Who is the human, and can they judge the action?

When confirmation fires, the agent asks the user in the conversation. For an internal agent that may be the right person. For a customer-facing service agent the confirming party is the customer, and "do you want me to update your billing address?" is answered by the person who asked for the update. The confirmation guards against misunderstanding the request. It does not involve anyone with the authority to refuse on the organization's behalf.

Salesforce's guidance makes the identity question explicit: service agents run as the agent's identity, so custom action code must check that the end user is authorized for what the action does (Salesforce, 2026). A confirmation from the chat does not establish that the person in the chat is entitled to the refund; the action's code has to establish that.

Dimension Salesforce, per its documentation What a buyer should verify
Where approval is set isConfirmationRequired on each custom action; recommended, not required Which actions have it, and who decided
Who confirms The user in the conversation Whether that person has authority to approve on the organization's behalf
Acting identity Agent's own identity; code checks end-user authorization Whether every action enforces that check
Named reviewer Not described in the pages reviewed Whether any action routes to a reviewer outside the conversation

The row that matters most concerns the named reviewer. A design in which a consequential action waits for a named person outside the conversation, with the context to judge it and the standing to refuse, is a different control, described in how to secure AI agents that act without human approval. Whether Agentforce can route an action to such a person is not described in the pages reviewed.

What does session tracing record, and when does it help?

Salesforce documents an export of session tracing data that captures every step of an Agentforce agent interaction: turns, messages, LLM calls, actions, metric scores and feedback (Salesforce, 2026). The Trailhead module on the Trust Layer adds that an audit trail tracks a prompt through each step of its journey (Salesforce Trailhead, 2026). Together these give an organization a detailed account of a run: what the customer said, what the model decided, which actions fired and in what order.

For the account record example, this means that after the agent updates the billing address without confirmation, the trace shows that it did, when, and following which message. That is valuable for investigation and for showing an auditor what occurred. The limit is the one every trace shares: it is written as the run proceeds and read afterward. It records that the address changed; it does not stand between the decision and the change.

Two details should be confirmed rather than assumed. The first is whether a confirmation is recorded as an event with the confirmer identified, or appears only as a message in the turn sequence; an approval record queryable by action and approver is a different artifact from a transcript containing the word "yes." The second is whether the trace records the values the model received and sent, or the steps alone. Both are matters for the current documentation; the pages reviewed describe the step types captured without detailing either. The Trust Layer module also states that data masking for LLMs is currently disabled for agents, so a trace of unmasked turns is itself a store of customer data.

What goes wrong when an agent acts with no human step?

The risk literature on agents is specific about this. The OWASP Top 10 for LLM Applications names excessive agency as the condition in which an agent has more functionality, permission or autonomy than its task requires, and lists the absence of a human check on consequential actions among the ways it manifests (OWASP, 2025). An Agentforce agent with a refund action and no confirmation is an instance: the capability and permission exist, and nothing between the model's decision and the money requires a person.

The route by which a bad decision arrives is usually not the model inventing one. It is the model acting on content it read. OWASP's prompt injection entry describes instructions arriving inside data the model processes, and for a service agent the data includes everything the customer types and everything in the records the agent reads (OWASP, 2025). A message in the chat crafted to look like a system instruction, or a note on the account record left by a previous interaction, can steer the agent toward an action. A confirmation prompt answered by the same person who crafted the message is no defense.

Microsoft's AI Red Team catalogs failure modes particular to agentic systems, including those arising from agents acting on outputs that were never checked (Microsoft AI Red Team, 2025), and Anthropic's research on agentic misalignment describes experimental settings in which models given autonomy and a goal chose harmful actions to pursue it (Anthropic, 2025). The common thread is that the failure happens at the action, and the control that would have caught it is a human with the standing to refuse, placed before the action rather than after.

How do other frameworks structure approval, and what does the contrast show?

Agentforce is not the only system to put approval on the builder. OpenAI's Agents SDK documents a human-in-the-loop pattern in which a tool call can be interrupted, the pending action handed to the application for approval, and the run resumed or rejected (OpenAI, 2025). The structure is instructive: the approval is an event in the run, the approver is whoever the application routes it to, who can be someone other than the conversational user, and the run cannot proceed until it resolves. Using it is still the developer's choice, but the shape is a gate rather than a prompt.

The NIST AI Risk Management Framework's Govern function asks organizations to establish accountability structures so that the people responsible for an AI system's actions are identified and empowered (NIST, 2023). Translated to an agent that updates records and moves money, that means a person, named in advance, who is accountable for each class of consequential action, and a mechanism that puts that person in the path. A customer confirming their own refund request is not that person.

The contrast does not make Agentforce's approach wrong; a per-action confirmation is a reasonable control against misunderstanding. The point is narrower. The title question is usually asked by someone who means "is a responsible person involved before the agent changes something consequential," and the documented answer is that the platform provides a confirmation prompt to the user, that builders may or may not enable it, and that routing to a named reviewer outside the conversation is not described in the pages reviewed. An approval model that treats every payment, submission and record change as an event a named person signs is a stricter design, and a buyer should know which one they are getting.

What does a governed environment change?

A governed environment moves approval from a per-action setting answered by whoever is in the conversation to a named person who approves every consequential action, recorded as its own event. Salesforce recommends that custom actions prompt the user for confirmation through isConfirmationRequired, and notes that the agent runs as its own identity, so action code must check end-user authorization itself (Salesforce, 2026). In a customer-facing agent the confirming party is the customer; the environment makes it a reviewer with the authority to refuse.

This class of control sits around the agent, not inside each action. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves payments, submissions and record changes before they execute. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Two facts from the page show what this changes. OWASP names excessive agency as a distinct risk (OWASP, 2025); a gate on every writing action removes the case where a builder forgot the setting. And session tracing is a transcript, with masking for agents described as disabled, so the trace may hold customer data in the clear. The environment's record names the approver as a queryable event and shows the screen as tokens.

The environment does not alter the agent's actions, the agent user's permissions or the model, and it does not remove the need to set isConfirmationRequired and check end-user authorization in action code.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design addresses the rows the confirmation prompt leaves open: a named approver outside the conversation, and a record of the approval as an event. Work runs in a governed environment in the customer's cloud. When an agent opens an account record, a case or a console page, substitution happens at the render layer before any model reads the screen, so identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation, so the approver is a designated reviewer rather than whoever is in the chat. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. For this page's question, a pilot on the reader's own service workflow would show, for one agent and one task, which actions reached a named approver, what that approver saw before deciding, and the approval record produced for each, set beside the per-action confirmation settings and session trace the platform provides. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Salesforce's own documentation: the ISVforce guidance on securing Agentforce custom actions, the Agentforce developer guide page on exporting session tracing data, and the Trailhead module on the Trust Layer (all vendor documentation). It also draws on OpenAI's Agents SDK documentation on human-in-the-loop patterns (vendor documentation), the OWASP Top 10 for LLM Applications entries on excessive agency and prompt injection (industry standards), the NIST AI Risk Management Framework (official guidance), Microsoft's AI Red Team taxonomy of failure modes in agentic systems (whitepaper), and Anthropic's agentic misalignment research (research publication). All sources were read as of October 16, 2026.

No hands-on testing of Agentforce or any Salesforce org was performed. "Not described in the pages reviewed" concerns the documentation consulted, not a claim that the product lacks the capability; in particular, whether Agentforce can route an action to a reviewer outside the conversation was not found in the pages reviewed and may be documented elsewhere. The session tracing export is described by Salesforce as beta. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The customer account record, service console and refund action examples describe record types and configurations, not any organization; no customer or prospect is described.

Whether a given agent's confirmation settings, authorization checks and tracing satisfy an organization's obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Salesforce documents a per-action confirmation setting, recommends that builders use it, identifies the confirming party as the user in the conversation, places the duty of checking end-user authorization on custom action code because the agent runs as its own identity, and provides a session trace that captures turns, messages, model calls and actions as they occur. Read together, those statements mean that Agentforce needs human approval before acting exactly where a builder required it, that the human is whoever is chatting, and that the platform's evidence is a trace rather than a gate. A named reviewer outside the conversation is not described in the pages reviewed. The test is to name one agent and one action that moves money or changes a record, and ask who, other than the person requesting it, had to say yes, and where that yes is recorded as an event with a name.

Frequently asked questions

Does Agentforce require human approval for every action?

No. Salesforce recommends that builders have the agent prompt the user for confirmation before proceeding, using the isConfirmationRequired setting on a custom action, but the setting is applied per action by the builder. One agent can have confirmed and unconfirmed actions side by side. A platform-wide requirement forcing confirmation on every writing action is not described in the pages reviewed, so the answer for any given agent is its action inventory.

Who approves when confirmation is required?

The user in the conversation. For an employee-facing agent that may be a staff member; for a customer-facing service agent it is the customer. The confirmation protects against the agent misreading the request. It does not involve anyone with authority to refuse on the organization's behalf, and because service agents run as the agent's identity, Salesforce places the duty of checking the user's authorization on the action's code rather than on the confirmation.

Is confirmation the same as human-in-the-loop approval?

Not in the sense most governance frameworks use the term. Human-in-the-loop approval usually means a person with the context and standing to refuse a consequential action is placed before it, and the action waits. A confirmation prompt asks the requester whether the agent understood them. The two overlap when the requester is also the accountable person, as with some internal agents, and diverge completely when the requester is a customer.

What does session tracing capture?

Salesforce describes the export as capturing every step of an agent interaction: turns, messages, LLM calls, actions, metric scores and feedback. It is a detailed record of what happened in a run, written as the run proceeds. Whether a confirmation appears as a distinct event with the confirmer identified, and whether the values exchanged with the model are included, are details to confirm against current documentation. The export is described as beta.

Can prompt injection cause an Agentforce agent to act?

The mechanism exists wherever a model reads content it did not author. A service agent reads the customer's messages and the records it is grounded on, and OWASP's prompt injection entry describes instructions arriving inside such data. A confirmation prompt answered by the same person who supplied the injected text offers no protection, which is why the risk literature points to an approver independent of the conversation for consequential actions.

What should change in the agent configuration?

At minimum, set confirmation on every action that writes a record or moves money, as Salesforce recommends, and implement the end-user authorization check in each custom action. Then decide, per action class, whether the conversational user is the right approver. Where the answer is no, the organization needs an approval path to a named person outside the conversation, and should confirm whether the platform or a surrounding environment provides one, since the pages reviewed do not describe it.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.