Salesforce Agentforce : Flow et Email-to-Case, enchaînés, peuvent transmettre à l'agent des messages non fiables.

Dans Salesforce Agentforce, la méthode recommandée pour qu’un agent réagisse à un événement passe par un Flow. Par ailleurs, Email-to-Case et Web-to-Case transforment les messages entrants en dossiers. Ces fonctions sont standard et documentées. En effet, chacune fonctionne comme prévu. Pourtant, leur enchaînement soulève une vraie question de gouvernance.

Comment Salesforce Agentforce réagit aux événements

Le principe est simple. D’abord, un enregistrement est créé, ou un dossier (case) est mis à jour. Un Flow se déclenche alors. Ensuite, il récupère des données et les injecte dans le prompt de l’agent.

Ce modèle est pratique. Ainsi, il permet de brancher un agent sur les processus existants sans développement lourd. Cependant, il crée un lien direct entre des champs de données et les instructions de l’agent.

Autrement dit, ce que contient l’enregistrement finit dans le prompt. La qualité et l’origine de ces données deviennent donc essentielles.

Email-to-Case et Web-to-Case : la porte d’entrée

Email-to-Case et Web-to-Case convertissent les messages de clients en dossiers. C’est ainsi que des compagnies aériennes et des hôtels organisent leur accueil des demandes. Par ailleurs, le dispositif est répandu et éprouvé.

Il repose pourtant sur une réalité simple. N’importe qui peut écrire à une adresse de support. En effet, le contenu d’un e-mail est rédigé par un tiers, sans contrôle de l’entreprise.

Si l’on met bout à bout les deux mécanismes, la chaîne devient claire :

1. un inconnu envoie un message ;
2. le message devient un dossier ;
3. la création du dossier déclenche un Flow ;
4. le Flow transmet le texte au prompt de l’agent.

Ainsi, un texte écrit par un externe peut atteindre un agent qui dispose de droits internes. Il ne s’agit pas d’un bogue au sens classique. En effet, chaque maillon est conçu pour fonctionner de cette façon. Le risque naît de l’assemblage, pas d’un composant défaillant.

Pourquoi la gouvernance logicielle ne suffit plus

Les entreprises disposent de pratiques éprouvées pour les logiciels. Par exemple, elles relisent le code. Elles testent les changements. Elles valident également les mises en production. Or ces contrôles supposent un comportement prévisible.

Un agent fonctionne différemment. Son comportement dépend aussi des données reçues au moment de l’exécution. En outre, il est souvent hérité. Par exemple, un administrateur crée un Flow. Un autre y branche un agent. Un troisième ajoute un canal d’entrée. Pourtant, personne ne revoit la chaîne dans son ensemble.

Par conséquent, chaque équipe peut respecter sa propre procédure sans voir le risque global. Les revues portent sur des composants isolés. Or l’exposition apparaît dans leur combinaison.

Le sujet dépasse donc le périmètre technique. Quand un agent agit au nom de l’entreprise, la question de la responsabilité remonte jusqu’à la direction. Qui possède l’agent ? Qui répond de ses actions ? Qui a validé les sources qui l’alimentent ? Sans réponse claire, la gouvernance reste théorique.

Des agents qui héritent de tout

Un agent récupère souvent les accès, les automatisations et les habitudes de ceux qui l’ont précédé. Cependant, cet héritage est rarement documenté. Il s’accumule discrètement. De plus, il échappe aux inventaires pensés pour les applications classiques.

Sécuriser Salesforce Agentforce : les bonnes pratiques

Aucune mesure ne supprime le risque à elle seule. En revanche, plusieurs réflexes réduisent nettement l’exposition d’un déploiement Salesforce Agentforce.

• Cartographier les chaînes. Recensez les Flows qui alimentent un agent. Identifiez ensuite les canaux d’entrée reliés à ces Flows, notamment Email-to-Case et Web-to-Case.
• Considérer le contenu des dossiers comme non fiable. Un champ rempli par un client reste une donnée externe. Par conséquent, il ne doit pas être traité comme une instruction.
• Limiter les droits de l’agent. Accordez uniquement les accès nécessaires à sa tâche. Évitez également les permissions héritées par défaut.
• Exiger une validation humaine. Les actions sensibles, comme un remboursement ou une modification de réservation, doivent être confirmées.
• Journaliser et surveiller. Conservez la trace des entrées et des actions de l’agent. Ainsi, les enquêtes sont facilitées en cas de comportement anormal.
• Désigner un responsable. Chaque agent doit avoir un propriétaire identifié. Ce dernier est chargé de revoir régulièrement sa configuration.

Ce qu’il faut retenir

Les fonctions décrites ici sont standard et documentées. Le danger vient pourtant de leur combinaison. Un message public peut devenir un dossier, puis une entrée pour l’agent.

La gouvernance pensée pour les logiciels contrôle des composants. En revanche, les agents exigent de contrôler des flux de données et des responsabilités. C’est pourquoi les équipes sécurité doivent examiner les chaînes complètes, de la boîte de réception jusqu’au prompt. Enfin, la direction doit savoir qui répond de chaque agent déployé.

Source : From Email-to-Case to the Boardroom: How Inherited Agents Break Governance Built for Software