Security review AppExchange des applications agentiques : ce qui change

Réponse courte : les applications agentiques passent la même security review AppExchange que n'importe quel managed package. Ce qui change, c'est la surface couverte. Salesforce délimite ses tests en suivant la donnée, et dans une application adossée à un modèle de langage la donnée client entre désormais dans un prompt, sort souvent de l'org vers un modèle, et revient sous forme de texte capable de déclencher une action. Préparez trois réponses avant de soumettre : ce qui entre dans le prompt, ce qui quitte l'org, et ce que l'agent a le droit de faire au nom d'un utilisateur.

Qu'est-ce qui change vraiment quand le package est agentique ?

Pour la review, une application agentique est tout package qui livre des agent actions, des topics ou des prompt templates, ou qui appelle un modèle de langage depuis Apex ou Flow. Les guidelines n'ont pas été réécrites pour l'occasion (Salesforce Developers). C'est le périmètre qui a grandi, puisque Salesforce décide de ce qu'il teste en suivant la donnée, et il y a bien plus de mouvements de données à suivre que dans un package CRM classique.

Dans un managed package classique, les chemins risqués étaient finis : SOQL, sharing, quelques callouts, un peu de sortie Visualforce. Une application agentique, elle, construit en plus des prompts à partir des enregistrements clients, les envoie quelque part, puis agit sur la réponse. Chacun de ces sauts est un endroit que le relecteur ira regarder.

Que demandent les relecteurs sur la gestion des prompts ?

Vous devez pouvoir montrer, dans l'org Developer Edition que vous soumettez, d'où vient exactement le texte du prompt et ce qui l'encadre. En pratique, cinq points :

• Intégrité des instructions. Le texte saisi par l'utilisateur ne doit jamais pouvoir réécrire vos instructions système. Traitez tout champ libre qui atteint un prompt comme une entrée hostile.
• Le grounding respecte les droits. Les enregistrements qui alimentent un prompt doivent être lus dans le contexte de l'utilisateur courant, sharing et sécurité au niveau des champs appliqués. Un agent qui résume un enregistrement que l'utilisateur ne peut pas ouvrir reste une violation de sharing, simplement plus polie.
• La sortie du modèle n'est pas de confiance. Ne l'injectez jamais brute dans du markup et ne la concaténez jamais dans une requête. Les vieilles règles anti-injection valent aussi pour le texte généré.
• Le minimum de données dans le prompt. Envoyez les champs nécessaires à la tâche, pas l'enregistrement entier.
• Discipline de journalisation. Si vous conservez prompts et réponses pour déboguer, vous conservez de la donnée client. Dites-le, limitez-le, et laissez l'administrateur le désactiver.

Que faut-il prouver sur la sortie des données ?

C'est la question que les packages classiques n'avaient presque jamais à traiter sérieusement, et c'est là que les soumissions agentiques perdent des semaines. Si un composant vit hors de Salesforce, la soumission exige les URL et identifiants de connexion de ces composants externes, un rapport de scan Checkmarx et un rapport de test dynamique de sécurité applicative (Salesforce Developers). À cela, d'expérience, votre relecteur voudra ajouter :

• La liste explicite des objets et champs qui peuvent quitter l'org, fonctionnalité par fonctionnalité.
• Un named credential pour chaque endpoint de modèle, afin que l'endpoint et son authentification ne se trouvent jamais dans le code Apex (Salesforce Help).
• Qui détient le credential : la clé du client, ou la vôtre pour son compte. Dites laquelle, et pourquoi.
• Ce que le fournisseur du modèle conserve, combien de temps, et dans quelle région.
• Si un administrateur peut couper l'appel externe tout en gardant une application fonctionnelle.

Et les appels à des modèles tiers ?

L'endroit où vous placez la frontière de confiance décide de la part de review qui vous revient. Utilisez les services d'IA de la plateforme et cette frontière appartient largement à Salesforce. Appelez un modèle externe directement depuis votre package et tout devient à votre charge : l'endpoint, l'authentification, le comportement quand le fournisseur tombe ou renvoie n'importe quoi, et l'isolation entre abonnés. Donnez aux relecteurs un accès de test fonctionnel à ce composant externe, pas une description.

Que l'agent a-t-il le droit de faire au nom de l'utilisateur ?

Dès qu'une action écrit, supprime, envoie ou paie, la review cesse de porter sur le code et porte sur l'autorité. Accordez le permission set le plus étroit possible, exécutez en contexte utilisateur, exigez une confirmation humaine pour tout ce qui est irréversible, et enregistrez ce que l'agent a fait et pour le compte de qui. Salesforce a formulé la norme sans détour en ouvrant sa marketplace d'agents aux partenaires :

Il faut pouvoir faire confiance à l'IA. Cela veut dire que nous devons comprendre les permissions et respecter les garde-fous, et que nos clients grands comptes doivent rester conformes avec leurs solutions. (Alice Steinglass, EVP et GM, Salesforce Platform, diginomica)

Que préparer avant de soumettre ?

1. Un package managed et released. Les packages unmanaged et beta sont refusés.
2. Une org Developer Edition avec la solution installée, des données d'exemple propres, des identifiants et un mode d'emploi.
3. La documentation des faux positifs éventuels de vos scans.
4. Les rapports de scan et les identifiants de chaque composant externe, y compris votre passerelle vers le modèle.
5. Une description de flux de données d'une page par fonctionnalité d'IA : déclencheur, champs envoyés, destination, rétention et interrupteur administrateur.

Les quatre premiers points sont les matériaux de soumission documentés. Le cinquième n'y figure pas, et c'est celui qui transforme une review en plusieurs tours en une review en un seul passage, parce qu'il répond aux questions de suivi de la donnée avant qu'un relecteur ait à les poser.

AgentExchange est-il une review différente ?

AgentExchange a ouvert lors du TDX 2025 avec plus de 200 partenaires publiant quatre types de composants : actions, prompt templates, topics et agent templates, qui selon Salesforce ont tous passé la security review (diginomica). Voyez-y la même exigence appliquée à des unités plus petites. Une action isolée porte les trois mêmes questions qu'une application complète, avec moins de code derrière lequel s'abriter.

Tekunda est PDO Salesforce et a fait passer la security review à des packages dans la santé, la logistique et l'industrie, dont le managed package Syntilio CareHub qui sert aujourd'hui 12 organisations de soins ou plus sur l'AppExchange. Si vous packagez une application agentique, parlons-en avant votre première soumission plutôt qu'après votre premier refus.

FAQ

Une fonctionnalité d'IA impose-t-elle une security review séparée ?

Non. Elle est évaluée avec votre package, mais elle élargit le périmètre testé, parce que le chemin de la donnée quitte les objets et passe par un prompt.

Puis-je livrer ma propre clé d'API de modèle dans le package ?

Les deux architectures sont possibles, mais soyez explicite sur votre choix. Une clé partagée fait de l'isolation entre abonnés et du consentement client votre charge de preuve.

Dois-je appliquer le sharing aux données utilisées pour le grounding ?

Oui. Le grounding est une lecture. Les règles habituelles de sharing et de sécurité au niveau des champs s'appliquent, et un résumé qui fuite un champ masqué échoue comme une requête brute.

Quelle est la cause la plus fréquente de retour d'une soumission agentique ?

Une sortie de données non documentée. Le code est souvent correct ; ce qui manque, c'est l'énoncé clair des données clients qui quittent l'org, de leur destination et de leur durée de conservation.