AppExchange Security Review for Agentic Apps: What Is Different

Short answer: agentic apps go through the same AppExchange security review as any other managed package. What changes is the surface it covers. Salesforce scopes its testing by following the data, and in an LLM-backed app customer data now travels into a prompt, often out to a model, and back as text that can trigger an action. Prepare three answers before you submit: what goes into the prompt, what leaves the org, and what the agent is allowed to do on a user's behalf.

What actually changes when your package is agentic?

An agentic app, for review purposes, is any package that ships agent actions, topics or prompt templates, or that calls a language model from Apex or Flow. The review guidelines have not been rewritten around it (Salesforce Developers). The scope has simply grown, because Salesforce determines what to test with a follow-the-data approach, and there is far more data movement to follow than in a classic CRM package.

In a classic managed package the risky paths were finite: SOQL, sharing, a couple of callouts, some Visualforce output. In an agentic app the same package also constructs prompts from customer records, sends them somewhere, and then acts on the answer. Every one of those hops is a place a reviewer will look.

What do reviewers ask about prompt handling?

Be ready to show, in the Developer Edition org you submit, exactly where prompt text comes from and what constrains it. In practice that means five things:

• Instruction integrity. User-supplied text must not be able to rewrite your system instructions. Treat every free-text field that reaches a prompt as hostile input.
• Grounding respects permissions. Records used to ground a prompt must be read in the running user's context, with sharing and field-level security enforced. An agent that can summarise a record the user cannot open is a sharing violation with better manners.
• Model output is untrusted. Never render it raw into markup and never concatenate it into a query. The old injection rules apply to generated text too.
• Least data in the prompt. Send the fields the task needs, not the record.
• Log discipline. If you store prompts or completions for debugging, you are storing customer data. Say so, scope it, and let admins turn it off.

What has to be true about data egress?

This is the question classic packages rarely had to answer well, and it is where agentic submissions lose weeks. If any component sits outside Salesforce, the submission requires the URLs and login credentials for those external components, a Checkmarx scan report and a dynamic application security test report (Salesforce Developers). Add to that, from experience, what your reviewer will want spelled out:

• An explicit list of which objects and fields can leave the org, per feature.
• A named credential for every model endpoint, so the endpoint and its authentication never sit inside Apex (Salesforce Help).
• Who holds the credential: the subscriber's own key, or yours on their behalf. Say which, and why.
• What the model provider retains, for how long, and in which region.
• Whether an admin can switch the external call off and keep a working app.

What about calls to third-party models?

Where you place the trust boundary decides how much of the review lands on you. Use the platform's own AI services and the boundary is largely Salesforce's. Call an external model directly from your package and it is entirely yours to evidence: the endpoint, the authentication, the failure behaviour when the provider is down or returns garbage, and the tenant isolation between subscribers. Give reviewers working test access to that external component, not a description of it.

What is the agent allowed to do on a user's behalf?

The moment an action writes, deletes, sends or pays, the review stops being about code and starts being about authority. Grant the narrowest permission set the action needs, run in user context, require a human confirmation for anything irreversible, and write an audit record of what the agent did and on whose behalf. Salesforce framed the standard plainly when it opened its agent marketplace to partners:

You need to be able to trust the AI. That means we need to understand permissions and respect guardrails, and our enterprise customers need to stay compliant with their solutions. (Alice Steinglass, EVP and GM, Salesforce Platform, diginomica)

What should you prepare before you submit?

1. A managed and released package. Unmanaged and beta packages are rejected.
2. A Developer Edition org with the solution installed, clean sample data, credentials and usage instructions.
3. Documentation of any false positives in your scan results.
4. Scan reports and credentials for every external component, including your model gateway.
5. A one-page data-flow description per AI feature: trigger, fields sent, destination, retention, and the admin switch.

The first four are the documented submission materials. The fifth is not, and it is the one that turns a multi-round review into a single pass.

Is AgentExchange a different review?

AgentExchange opened at TDX 2025 with more than 200 partners publishing four component types: actions, prompt templates, topics and agent templates, all of which Salesforce says passed security review (diginomica). Treat it as the same trust bar applied to smaller units. A single action carries the same three questions as a full app, with less code to hide behind.

Tekunda is a Salesforce PDO, and we have taken packages through security review in healthcare, logistics and manufacturing, including the Syntilio CareHub managed package now serving 12 or more care organisations on the AppExchange. If you are packaging an agentic app, talk to us before your first submission rather than after your first rejection.

FAQ

Does an AI feature require a separate security review?

No. It is reviewed with your package, but it widens the scope, because the data path now leaves the objects and travels through a prompt.

Can I ship my own model API key inside the package?

You can architect it either way, but be explicit about which you chose. A shared key makes tenant isolation and per-subscriber consent your responsibility to prove.

Do I need to enforce sharing on data used for grounding?

Yes. Grounding is a read. The usual sharing and field-level security rules apply, and a summary that leaks a hidden field fails the same way a raw query would.

What is the most common reason an agentic submission comes back?

Undocumented egress. The code is often fine; what is missing is a clear statement of which customer data leaves the org, where it goes and how long it stays there.