main logo icon

Published on

November 1, 2026

|

17 min read

Salesforce Agentforce Action Security Assessment: Buyer Scope

A practical scope for testing Agentforce action identity, record access, confirmation, prompt injection and migration before a customer-facing rollout.

Arafat Afzalzada

Arafat Afzalzada

Founder

LLM SecurityWeb App Security

Summarize with AI

ChatGPTPerplexityGeminiGrokClaude

TL;DR

An Agentforce action assessment should verify the identity used by each action, what records it can read or change, when customer confirmation is required, and whether untrusted content can redirect the action. Salesforce documents distinct permission contexts for employee and service agents, so the buyer must name the channel and action configuration before accepting a test scope. Require approved and denied cases on synthetic records, action traces, a retest, and a report that separates Salesforce configuration from customer-owned Apex, Flow, and integration logic.

Agentforce actions can call Apex, Flow or prompt templates, and Salesforce lets an action require customer confirmation before it runs. The same action can be invoked through configured logic or exposed as a tool that the model chooses to use. Those are different paths to a business operation, which makes the action boundary a useful place to test before an agent is exposed to customers. Salesforce Developers, Agent Script Reference: Actions

Quick answer. An Agentforce action security assessment should prove which identity reaches each action, which customer or employee records it may access, which actions require confirmation, and whether untrusted text can change an authorized decision. Commission a test with named channels, actions, synthetic records and permitted negative cases. Stingrai can scope a human-led AI and LLM penetration test across the agent, its actions and the application or API around them.

The buyer's question is specific: can a customer-facing agent perform an operation or disclose a record that the person in that conversation was not authorized to reach? A pleasant response from a test chat does not answer it. The evidence has to connect the conversation identity, the action the agent selected, the permissions of the principal that executed it, the record decision and any confirmation the user gave. This article provides a way to buy and accept that work without assuming that every Agentforce deployment shares one permission model.

Start with the business operation, not the chatbot

An Agentforce project may answer a general question, read a case, change a reservation, update a contact, issue a refund or call a custom service. The risk and test depth change with the operation. Salesforce's legacy Builder guidance describes private actions as actions for which the person triggering them must be authorized and securely identified; its recommendation to put identity confirmation and access control inside the sensitive action's flow remains a useful security principle to test in the configured version. Salesforce Help, Maintain Trust with Agentforce Actions in the Legacy Builder

Before requesting a quote, have the application owner write an action inventory in plain terms. Name the channel where the conversation starts, the agent type and Builder version, the action target, the data the action reads or writes, and the business owner of that data. Record whether the action is intended for an anonymous visitor, a signed-in customer, an employee or an administrator. If an action uses a downstream API, name the API owner and the principal used at that boundary. A provider cannot price a meaningful assessment from the phrase “test our Agentforce bot” alone.

Item to name

What the buyer supplies

Why it changes the test

Entry channel

Employee interface, authenticated site, messaging channel or another approved connection

The execution identity and evidence differ by channel

Agent and version

Legacy Builder or new Agentforce Builder; agent version under test

Routing and action configuration may differ

Action target

Apex, Flow, prompt template or a connected application

Each target has its own permission and validation boundary

Sensitive operation

Read, update, cancel, approve, send or export

The expected confirmation and record rules become concrete

Test records

Synthetic customer, case and transaction records across allowed and denied owners

A denial can be observed without exposing real customer data

Control owners

Salesforce admin, action developer, API owner and privacy lead

A finding can be assigned to the person who can fix it

This inventory also helps procurement separate an assessment of the customer-owned agent from a broad review of Salesforce's shared platform. The SOW should name only the customer accounts, actions and integration endpoints for which the buyer can authorize testing. Salesforce says customers no longer need prior approval to begin their own security assessments, but they must still follow its Security Assessment Agreement. The agreement separately says a customer may not subcontract, assign or transfer assessment rights or obligations without Salesforce's prior written approval. A buyer using an outside provider should resolve that approval before testing. The agreement also restricts testing to the customer's accounts and sets obligations for third-party testers. Salesforce Help, Security Assessments

Map the identity that actually executes an action

Identity is the first fork in the test plan. Salesforce says employee agents connected to logged-in channels operate in the end user's context. Service agents connected to channels that are not restricted to logged-in users can operate in the context of an assigned agent user. An authenticated customer experience may use the logged-in user's context when configured for that mode. The buyer should verify the actual channel and configuration rather than assume that a chatbot inherits the customer's permissions. Salesforce Help, Common User Access for Standard Agent Actions Salesforce Developers, Apex action guidance

Ask the tester to record the principal that runs each sensitive action, the permission sets and object access relevant to it, and the result on a permitted record and a neighboring denied record. This is a scoped access decision, not a general review of every permission in the Salesforce org. The test should distinguish a denied action because the agent did not expose a tool from a denied action because the Apex, Flow or API independently rejected the record. Both may be useful controls, but they fail for different reasons.

For an unauthenticated channel, a dedicated agent user can be intentionally capable of carrying out some service tasks. The assessment must then show how the conversation's verified customer identity is bound to the record being changed. A typed email address or order number is not proof of ownership by itself. Salesforce's legacy Builder guidance for private service actions recommends identity verification before execution and confirmation of the person's authorization inside the action. Use that principle to test the actual version in scope. Salesforce Help, Maintain Trust with Agentforce Actions in the Legacy Builder

For an employee channel, repeat the same business question with an employee who is allowed to view the record and an employee who is not. Salesforce lists Flow execution and Apex class access among the permissions relevant to standard actions. Those permissions tell you whether an action can run; they do not, by themselves, prove that the action enforces the expected record and field restrictions. The buyer needs evidence from the actual action and data access path. Salesforce Help, Common User Access for Standard Agent Actions

Make the action, not the prompt, enforce access

The model's decision to call a tool is not an authorization decision. Salesforce's Agent Script reference says a defined action can run from deterministic logic or be exposed to the model as a reasoning tool. A test that observes only a friendly answer may miss an action that was available with an excessive scope, or a mandatory action that ran after reasoning. Salesforce Developers, Agent Script Reference: Actions

In a custom Apex action, Salesforce recommends verifying the user before private actions, using with sharing, and running queries and data changes in user mode to enforce object and field permissions. The buyer should ask the provider to inspect these choices in the customer-owned action and then demonstrate the decision using authorized test records. A code review can explain the intended check; an accepted and denied record case shows whether it works along the path the agent actually calls. Salesforce Developers, Apex action guidance

If a Flow or external API is the final actor, apply the same principle at that boundary. Require a positive case where the entitled user can complete the task and a negative case where a user without that entitlement cannot. A refusal spoken by the model is not sufficient if a direct API call or another tool path can still perform the operation. Keep test requests within the named customer account, and use synthetic records and safe transaction types approved in the rules of engagement.

Agentforce action evidence path

Figure 1: The buyer's evidence path from a conversation identity to a record decision. This is an editorial test-planning model based on the cited Salesforce action, permission and testing documentation.

Test confirmation as a separate control

Salesforce documents a require_user_confirmation property for Agent Script actions. In a separate security notice, it says it changed confirmation settings for a set of standard actions and recommends requiring confirmation for custom sensitive actions. Confirmation reduces the chance that untrusted instructions silently trigger a business operation, but it must be tested as an actual user decision in the configured channel. Salesforce Developers, Agent Script Reference: Actions Salesforce Help, Confirmation Required for Agentforce Actions

For each sensitive action, the SOW should state what the user is meant to confirm. Is it the fact of an operation, or also its target, amount, destination and affected record? The tester can use a synthetic transaction to check that the confirmation shown to the user matches the operation executed. The user should be able to decline and leave the record unchanged. A confirmation step that refers to a generic task while the underlying action can operate on a different record gives weak evidence of informed approval.

Confirmation is not a substitute for authorization. A user who confirms a change to another customer's record is still outside the intended boundary. The test should therefore record three independent results: whether the conversation identity was verified where required, whether the target record was authorized for that identity, and whether the user confirmed the precise operation. This separation makes a finding actionable. A developer can fix record filtering without disabling useful agent behavior, and an administrator can change action confirmation without rewriting the entire integration.

Give untrusted content a controlled path to the agent

The most valuable adversarial test starts with content the agent may read but should not obey as an instruction. That could be a synthetic knowledge article, a customer message, a returned case field or a mock API response. The buyer should define which sources the agent is expected to use as facts, which sources are allowed to influence action selection, and which operations require a fresh user instruction or confirmation. Salesforce's own action confirmation notice identifies prompt injection as a reason for increasing confirmation on standard actions. Salesforce Help, Confirmation Required for Agentforce Actions

The tester does not need to publish a working attack string or touch real customer data to answer the business question. Use a benign marker in a customer-owned test record and ask whether the agent attempts an out-of-scope lookup, changes the action target, or proposes an unapproved transaction. Preserve the observed action trace, record result and control that stopped or allowed it. The final report can describe the class of manipulation and a safe reproduction in the customer's private environment, without exposing a reusable public payload.

A useful matrix crosses the source of untrusted text with the action consequence. Test a read-only lookup, then a low-impact synthetic update, then an action that reaches a connected API if that integration is part of scope. Do not assume that a model refusal on one prompt means the action is safe across all retrieval and channel paths. The assessment should explain which input surface reached the agent, which action was available, which guard made the final decision, and whether an unauthorized result occurred.

Boundary

Approved case

Denied case

Evidence to retain

Customer identity

Verified synthetic customer can view own case

Unverified or different customer cannot view it

Verification state, action trace, record result

Employee permissions

Entitled employee can use permitted action

Lower-privilege employee cannot reach restricted record

User context, object and record decision

Action confirmation

User approves the described synthetic change

User declines or changes target before approval

Prompt, approval response, final record state

Retrieved content

Agent summarizes a synthetic document

Document text cannot cause an unauthorized action

Document marker, trace, action and data result

External API

Approved account operation succeeds

Sibling account operation is rejected

API principal, request class, authorization result

These are suggested acceptance cases, not a claim that Salesforce requires this exact matrix. Ask the vendor to adapt it to your action inventory and to distinguish “not tested” from “passed.”

Include the Builder version and migration path

Salesforce says creation of new agents moved to the new Agentforce Builder in the week of July 13, 2026. Legacy agents remain active and editable. Its migration guidance describes a change from a prompt-based reasoning loop to a graph of subagents and transitions, with variables carrying state. That makes the Builder version an assessment input, especially where a team is migrating a customer-facing agent. Salesforce Developers, Builder migration guidance

The buyer should ask for the exact agent version and action inventory in both environments. Do not accept “same prompt, same security” as migration evidence. Salesforce recommends running the same baseline test suite against the legacy and migrated versions before adding new cases. For a security engagement, carry forward the identity, confirmation and denied-record cases as well as conversational quality tests. A change in which subagent or action runs can change the result even when the final answer sounds similar. Salesforce Developers, Builder migration guidance

Salesforce's debugging guide distinguishes Simulate mode, which can test without changing actual data, from Live Test mode, which can exercise real actions. It also describes traces showing routing, variables and action calls. Agree which mode is suitable for each test case. A simulation is useful for broad routing checks; an authorized live test on synthetic records is needed to observe the record and API decision. Export or capture only the trace fields required to explain the finding, and handle them according to the customer's data policy. Salesforce Developers, How to Debug Agent Script

Write a scope that a provider can price

The quote should state the number of agents, versions, channels, sensitive actions and integrations, but should not pretend that those counts alone determine effort. A simple read-only employee assistant and a customer-facing service agent that updates records through Apex and a downstream API present different trust edges. Ask for a fixed list of actions and a small, approved set of adjacent denied cases, then identify what would require a change order. This gives procurement a basis to compare bids without forcing every provider into the same generic “AI pentest” checkbox.

At minimum, request these deliverables:

  • An action inventory and a diagram of identity, action, record and external API boundaries.

  • A test matrix showing expected allowed and denied outcomes for each sensitive action.

  • Evidence of the actual running principal, relevant permissions and record-level results.

  • A separate result for confirmation, including what the customer saw and what executed.

  • Safe prompt injection and retrieved-content cases tied to business operations.

  • A distinction between customer configuration or code findings and any suspected platform issue.

  • A retest of changed controls, with the original denied case repeated.

The rules of engagement should name authorized orgs, agent versions, test channels, synthetic data, rate limits, time windows, monitored contacts, stop conditions and third-party integrations. Salesforce's assessment agreement sets additional conditions for testing its services, including limits on other customers' accounts and prior written approval for subcontracting assessment rights. Have your legal and platform owners resolve the agreement and outside-provider approval before work starts. A provider should document where the customer-owned app ends and where Salesforce's shared service begins, so a test of one is not presented as a certification of the other.

An accepted report should let a developer replay a finding privately and let an executive see the business consequence. State whether the failure allowed a cross-customer read, an unauthorized update, an unconfirmed action, or only an unexpected conversational answer. Keep proof on synthetic records and redact unnecessary identifiers. For each finding, identify the control owner and the exact positive and negative cases to rerun after remediation. The resulting evidence can support the buyer's security and audit program without implying that a penetration test confers a compliance certification.

Where Stingrai fits

Stingrai is a CREST-accredited penetration testing service provider. Its AI and LLM penetration testing service covers applications, models, tool integrations and data layers, with one-time assessments and continuous programs. For Agentforce, a human-led engagement can focus on the customer's agent configuration, Apex or Flow actions, authorization decisions, and the connected web and API layer. The SOW should name the exact channels, actions, records and integrations to be tested, and the report should preserve controlled evidence for remediation and retesting.

This article does not set a standard Agentforce price. The work depends on the buyer's actions, data flows and approved test environment. Use the Get a Quote form to share an action inventory and intended launch or migration date. The same inventory helps decide whether the assessment should stand alone or fit into a broader annual or continuous application testing program.

Frequently Asked Questions

What should an Agentforce penetration test cover?

It should test the identity that runs each sensitive action, access to permitted and denied records, required user confirmation, untrusted content that might redirect an action, and the result at any downstream API. The scope should name the agent version, channel, actions and synthetic test records.

Is Agentforce Testing Center enough to test action authorization?

No single conversational test proves the record decision. Use Salesforce's testing and trace tools to observe routing and action calls, then run authorized positive and negative cases on synthetic records to verify the action's actual access control.

Does an unauthenticated service agent use the customer's permissions?

Not automatically. Salesforce documents that service agents connected to channels without logged-in users can operate under an assigned agent user. The buyer must inspect the configured channel, verification method and action-level record checks.

Should sensitive Agentforce actions require confirmation?

Salesforce recommends confirmation for custom sensitive actions and documents a confirmation setting for Agent Script actions. Confirmation should identify the operation the customer is approving, while authorization must still be enforced at the action and data boundary.

What changes when an agent moves to the new Builder?

Salesforce says the new Builder uses a graph of subagents and transitions rather than the legacy prompt-based loop. Reuse the same identity, action, confirmation and denied-record cases before and after migration so a change in routing or state is visible.

Can an outside provider test our Agentforce deployment?

Salesforce says customers may begin their own assessment without prior notice, but its Security Assessment Agreement says they may not subcontract or transfer assessment rights without prior written approval. Resolve that approval before an outside provider tests the named customer-owned accounts and integrations.

References

  1. Salesforce Developers, Agent Script Reference: Actions.

  2. Salesforce Developers, Best Practices for Building Agentforce Apex Actions.

  3. Salesforce Help, Common User Access for Standard Agent Actions.

  4. Salesforce Help, Maintain Trust with Agentforce Actions in the Legacy Builder.

  5. Salesforce Help, Confirmation Required for Agentforce Actions.

  6. Salesforce Developers, Migrate Legacy Agents to the New Agentforce Builder.

  7. Salesforce Developers, How to Debug Agent Script.

  8. Salesforce Help, Salesforce Security Assessments and Security Assessment Agreement.

Talk to Stingrai

Share the action inventory and intended rollout with Stingrai through Get a Quote, or book a free discovery call to define the authorized test boundaries.

0 views

0

X

Related reading

Snowflake Cortex Search and Agent Data Access Security Assessment (2026)
LLM SecurityWeb App Security

Snowflake Cortex Search and Agent Data Access Security Assessment (2026)

Scope a Cortex Search and Agent assessment around indexed data, owner rights, caller roles, tool grants, tenant isolation and launch evidence.

19 min read

OSFI E-23 and the AMF AI Guideline (2027): Security Testing Evidence for LLM Applications
LLM SecurityWeb App Security

OSFI E-23 and the AMF AI Guideline (2027): Security Testing Evidence for LLM Applications

Neither OSFI E-23 nor the AMF AI guideline names a penetration test. Map each clause to the LLM security test and evidence to have before 1 May 2027.

16 min read

Microsoft 365 Copilot Connector Permission Testing: A Buyer Matrix (2026)
LLM SecurityWeb App Security

Microsoft 365 Copilot Connector Permission Testing: A Buyer Matrix (2026)

Scope a Copilot connector security test with synthetic users, source ACLs, crawl and revocation checks, and clear report acceptance criteria.

17 min read

Contents

X