How to Vet AgentExchange Apps for Salesforce Security Before You Install

Most listings on the Salesforce AgentExchange passed a security review exactly once, on the day they were first listed. The vendor added features, shipped new versions, and wired in agent actions in the years since, and none of that went back through review. Matt Meyers put the number at 99 percent of apps during the session, and he was not exaggerating for effect. If your team treats the “passed security review” badge as a guarantee, you are trusting a snapshot that may be five years old.

That is the problem André van Kampen, Salesforce MVP Hall of Fame member, Business Solutions Architect, Data Quality Advocate, and Owner of ISV Forum, set out to fix in this edition of Salesforce Security Office Hours with host Matt Meyers, Salesforce CTA and Founder and CEO of EzProtect. André runs the community where AgentExchange partners talk to each other, so he knows what vendors say to customers and what they leave out. His opening line set the tone for the hour: you are responsible for a lot of the security of the apps, add-ons, and integrations other people built. The good news is that you have more power in that relationship than most teams realize.

The native tag and the review date tell you more than the listing copy does

The word “native” shows up everywhere on AgentExchange listings, sometimes in the title itself. André’s advice is to ignore the copy and look for the actual native app tag, because Salesforce applies that tag and the vendor does not. A package can be built entirely with Lightning Web Components, Apex, and Flows and still send your data to an external service for processing. That is not always a bad thing. An email validation tool has to check addresses against an outside database to do its job. The trouble starts when a listing claims to be purely native and the fine print shows your data leaving the org. More than half of public listings have no customer reviews at all, so the listing’s own dates are often your best evidence. Check when the app was published, when the AppExchange security review last happened, and whether the version you are installing matches the version that was reviewed. If the dates do not line up, you have leverage. Matt’s position is simple: tell the vendor you will not procure until Salesforce reviews and approves the app again. Vendors can request that review, and customers can require it.

A managed package is a black box, so your sandbox is the only place to open it

Managed package code is hidden by design, which means you cannot read what you are installing. André’s answer is to install in a sandbox first and inspect everything the package adds to the org. Read the installation guide the vendor provides when you choose which users get access, because it lists the permissions, the scope, and the components. Then go to Setup and check the remote site settings, named credentials, trusted URLs, and external client apps the install created. Those connections often bypass your sharing and security settings by the way they work, so each one needs an owner and a reason to exist. If you see an endpoint you do not recognize, ask the vendor to explain it. They built it, so they can. The same scrutiny applies to connections your own team built years ago. A “temporary” integration from 2021 is still a data path in 2026, and the Winter ‘27 enforcements make that cleanup urgent rather than optional. Our recent hardening guide for connecting Claude to Salesforce applies the same discipline to an AI integration. André’s rule for anything unused is to switch it off and see who complains.

Agent actions need production-grade test data and a revocation plan

Agents changed the review process because your users got security training and your agent did not. André recommends testing every agent action in a full copy sandbox, or a regular sandbox loaded with data that matches production in both quality and volume. He has watched implementations pass every test on clean sample data and fall over the day they met real records. Test as an admin, then test again under every permission set your users actually hold. Geraint Waters took the same approach in his session on testing AI agents. Once the app is live, give every integration its own integration user with a named owner. When the app is retired or paused, revoke its tokens the same day, the way you would revoke access the moment an employee walks out the door. Our breach response plan explains why resetting a password does not revoke OAuth tokens, and a revocation habit means you never have to learn that under pressure.

Watch the full replay for the vendor question list, the sandbox checklist, and a Q&A that takes on independent pen test reports, Salesforce revoking tokens for suspicious integration activity, and a vendor that pointed a customer at the wrong license for an integration user.