AgentExchange Security Review: How to Pass It the First Time

The AgentExchange security review is Salesforce’s mandatory assessment of every managed package before it can be listed. It checks your code and configuration against a published set of requirements: access-control enforcement, injection safety, secret storage, and secure external calls. You pass the first time by building to those requirements from the first line of code, not retrofitting the week before submission.

We have taken our own packages through this process. FTS and Smarter Files are both live on AgentExchange, so the guidance below is what we do on our own products, not a summary of the docs. The docs tell you the rules. This tells you where teams lose weeks and how to avoid it.

What does the AgentExchange security review check?

The review checks that your package enforces access control (CRUD and FLS) on every object and field it touches, prevents SOQL, SOSL, and DML injection, stores no hardcoded secrets, uses secure external endpoints over HTTPS, respects sharing, and ships no debug or backdoor access. It combines an automated scan with a manual reviewer pass.

The automated layer runs Salesforce Code Analyzer (which wraps PMD, ESLint, and other engines) against your source. It flags the mechanical issues: unenforced FLS, string-concatenated queries, System.debug leaks, insecure LWC patterns. The manual layer is a human reviewer working through your app in a test org, probing the things a scanner cannot see: privilege escalation through a poorly scoped without sharing class, a REST endpoint that trusts client input, a stored credential that should live in a Named Credential.

Both layers reference the same document: the ISVforce security requirements checklist. Treat that checklist as your specification, not your final exam. Every requirement in it maps to a decision you make while building, not a fix you apply after.

How long does the AgentExchange security review take?

Timelines vary with queue depth, package size, and how clean your first submission is. A clean first pass moves faster than an app that triggers a back-and-forth of findings and re-review. Budget the review as a phase with its own calendar slot, not a formality you bolt onto the end of the build.

The variable you control is the number of round trips. Each rejection restarts a review cycle, and the queue does not prioritize resubmissions. One team we advised had budgeted two weeks and spent nine, because the first submission failed on FLS enforcement that ran through hundreds of Apex methods. Fixing it after the fact meant re-testing the entire package. Building it in from the start would have cost days, not weeks.

The failure patterns reviewers see most

The rejections cluster into a short list of categories. None of them are exotic. They are the same requirements applied inconsistently across a codebase that grew faster than its standards.

Missing CRUD and FLS enforcement. The most common failure. A query reads a field, or a DML statement writes one, without checking whether the running user has permission. In older Apex this meant manual Schema.sObjectType and isAccessible() checks everywhere. Modern Apex gives you USER_MODE on database operations and Security.stripInaccessible() for sanitizing records. Use them uniformly.

Injection through dynamic queries. Any SOQL or SOSL built by concatenating a variable into a string is a finding. Bind variables instead, or pass through String.escapeSingleQuotes() where binding is impossible. The same applies to dynamic DML and to any Apex that builds a query from user-supplied filter input.

Hardcoded secrets. API keys, passwords, and endpoints written into Apex, into metadata that ships in the package, or into LWC source. Credentials belong in Named Credentials and Protected Custom Settings or Protected Custom Metadata, never in code the reviewer can read.

Insecure external communication. Callouts over HTTP instead of HTTPS, endpoints that skip certificate validation, or integrations that pass data to a third party without documenting where it goes. Reviewers want every external service named and justified.

Sharing and privilege escalation. A without sharing class that exposes records the running user should not see, or an @AuraEnabled method that performs privileged work without re-checking permission. Default to with sharing and justify every exception in your submission notes.

Building review-ready beats retrofitting

The teams that pass first time do not have a secret. They wrote the code to the standard as they went, so the review confirms what they already know. The teams that fail treat security as a pre-submission project, discover the debt is spread across every class, and pay compound interest to remove it.

The practical difference is a set of habits you adopt on day one. Run Code Analyzer in your local build and in CI, so a violation fails the pipeline the day it is introduced. Default every Apex class to with sharing. Use USER_MODE on database operations by default. Keep a running document of every external endpoint and every stored secret, updated as you add them, so your submission package writes itself.

This is where architect-led delivery earns its keep. On our own apps, the security posture is a design input reviewed by a Salesforce Certified Technical Architect (one of fewer than 500 worldwide), not a QA gate at the end. The decisions that are expensive to reverse, sharing model, namespace, packaging, get made once and made right. If you want the full path from package architecture to listing, see our guide on how to build an AgentExchange app.

The pre-submission checklist

Run every item to green before you submit. Each maps to a category reviewers fail apps on.

1. Code Analyzer and PMD are clean. Zero high-severity violations across Apex, LWC, and Aura. Run it as the final gate and keep the report.
2. CRUD and FLS are enforced everywhere. Every read and write uses USER_MODE, WITH SECURITY_ENFORCED, or Security.stripInaccessible(). No object or field access assumes permission.
3. No dynamic query is built by concatenation. All SOQL, SOSL, and DML use bind variables or escaped input. Audit every Database.query and dynamic DML call.
4. No secret is hardcoded. Every credential and endpoint lives in a Named Credential, Protected Custom Setting, or Protected Custom Metadata. Grep the source to confirm.
5. Every external service is documented. A written list of each endpoint, what data leaves the org, and why. HTTPS only, with certificate validation on.
6. Sharing exceptions are justified. Every without sharing class and every privileged @AuraEnabled method has a documented reason and a permission recheck.
7. A false-positive memo is prepared. For each scanner finding you have consciously accepted, write the file, line, and the reason it is safe. Reviewers accept a documented false positive; they reject a silent one.

The submission package that speeds up the manual review

The reviewer needs to reproduce and verify your app quickly. Give them a test environment already configured with sample data and any external integrations connected, a test user for each permission level, and step-by-step instructions to exercise the main flows. A reviewer who can run your app in five minutes finds your app easier to approve.

Attach the false-positive documentation directly. When the scanner flags a pattern you have justified, the memo saves the reviewer from raising it as a finding and saves you a round trip. Name every external service and describe the data that crosses the boundary. Ambiguity about where data goes is a reliable way to trigger questions.

What happens if the review rejects your app

A rejection returns a list of findings, each tied to a requirement and usually a file and line. It is a checklist, not a verdict. Fix every item, re-run your full test suite because security fixes touch shared code paths, update your submission notes to reference the changes, and resubmit. There is no penalty for a resubmission beyond the calendar cost of another cycle.

The mistake is treating the first rejection as the diagnosis and stopping there. Findings often share a root cause. If FLS enforcement is missing in one class, it is usually missing across a pattern, and the reviewer sampled one instance. Fix the pattern, not the single line, or you will resubmit into the same rejection with a different file path.

If you want the review handled as an engineering phase rather than a scramble, that is the AgentExchange Product Development engagement: security-review readiness built into the architecture, run by a team with apps already live on the platform.

Frequently asked questions

What are the AgentExchange security review requirements?

The requirements are published in the ISVforce security review checklist. They cover CRUD and FLS enforcement, injection prevention in SOQL, SOSL, and DML, secure secret storage, HTTPS-only external callouts, correct sharing behavior, and no backdoor or debug access. Your package must satisfy every applicable item before Salesforce lists it.

Is there a fee for the AgentExchange security review?

Salesforce’s fee and listing model has changed over time and depends on your partner agreement and app type. Confirm the current terms in the Partner Community before you plan a budget. Treat any figure you find in older articles as out of date.

How do I prepare for the AgentExchange security review?

Build to the security requirements from day one rather than retrofitting. Run Salesforce Code Analyzer in CI, default Apex classes to with sharing, use USER_MODE on database operations, keep secrets in Named Credentials, and maintain a running list of external endpoints and accepted false positives so your submission package is ready.

Why do AgentExchange apps fail the security review?

The most common causes are missing CRUD and FLS enforcement, SOQL or DML injection through concatenated queries, hardcoded secrets in code, insecure external callouts, and privilege escalation through unscoped sharing. These are the same requirements applied inconsistently across a codebase, which is why building to standard from the start prevents most failures.

Can I resubmit after a rejection?

Yes. A rejection returns a list of findings tied to specific requirements. Fix each one, re-run your full test suite because security changes touch shared code, update your submission notes, and resubmit. There is no penalty beyond another review cycle. Fix the root pattern, not just the single flagged line.