Agent IA et CRM : risques d’écriture et garde-fous

Quels risques crée un agent IA connecté à un CRM ?

Un CRM concentre des données personnelles, des montants, des historiques d’échanges et des pipelines commerciaux, et il accepte du contenu venu de l’extérieur. Un agent qui l’utilise relie donc une source non fiable (formulaire web, e-mail entrant) à des outils d’écriture. C’est la combinaison que décrivent Greshake et ses coauteurs sous le nom d’injection de prompt indirecte : le modèle lit un contenu rédigé par un tiers et le traite comme une consigne.

Les risques se rangent en cinq familles :

• Écriture involontaire : mise à jour du mauvais enregistrement, écrasement de champs, changement de propriétaire ou d’étape de pipeline.
• Suppression : contacts, sociétés, affaires ou notes supprimés sur la foi d’une instruction mal comprise ou injectée.
• Fuite : export de listes, résumé de comptes envoyé vers l’extérieur.
• Écriture à effet : e-mails ou séquences déclenchés depuis le CRM, avec le nom de l’entreprise.
• Pollution des données : informations fausses insérées dans des fiches, qui seront ensuite relues comme vraies par les commerciaux et par d’autres agents.

L’OWASP rassemble ces cas sous LLM06:2025, Excessive Agency, et en donne trois causes : trop de fonctions, trop de permissions, trop d’autonomie.

Existe-t-il un cas réel sur un CRM ?

Oui : ForcedLeak, découvert par Noma Security dans Salesforce Agentforce. La faille a été notée CVSS 9,4. L’attaquant plaçait des instructions cachées dans le champ Description d’un formulaire Web-to-Lead, qui accepte jusqu’à 42 000 caractères. Quand un employé interrogeait l’IA sur ce prospect, l’agent pouvait exécuter ces instructions sans les distinguer de consignes légitimes. Les données étaient ensuite envoyées vers un domaine, autorisé par la liste blanche de Salesforce, dont l’enregistrement avait expiré et qui pouvait être racheté pour quelques dollars, via une URL d’image.

Salesforce a accusé réception le 31 juillet 2025, déployé l’application des URL de confiance le 8 septembre 2025, et la faille a été rendue publique le 25 septembre 2025. Ce cas montre deux choses utiles pour vos tests : un formulaire public alimente directement le contexte de l’agent, et l’exfiltration peut passer par une simple image.

Comment une suppression se produit-elle sans validation ?

Elle se produit quand l’outil exposé à l’agent est un appel d’API de suppression ou de mise à jour générique, accessible avec le jeton d’une application aux droits larges. L’agent n’a pas besoin d’être « malveillant » : une consigne ambiguë (« nettoie les doublons »), une erreur de rapprochement ou une injection suffisent.

Prenons l’API HubSpot de suppression d’un contact : la documentation indique que le contact supprimé passe dans la corbeille, d’où il peut être restauré dans HubSpot. C’est un filet de sécurité, mais il ne couvre pas tout : la documentation consultée ne précise pas les durées de conservation, ni le sort des données associées. Vérifiez chez votre éditeur ce qui est récupérable, pendant combien de temps et par qui, avant de donner à un agent le droit de supprimer.

Comment tester un agent branché sur un CRM ?

On teste sur un compte bac à sable ou une instance de développement, avec des données fictives. La méthode comporte quatre volets :

1. Inventaire des outils et des droits. Quelle application ou quel jeton l’agent utilise-t-il ? Quels scopes ? Peut-il supprimer, fusionner, exporter, envoyer ? Un écart entre ce qui est nécessaire et ce qui est accordé est déjà un constat.
2. Tests d’écriture sans validation. Demandez des modifications en langage naturel ambigu (« mets à jour le client Martin ») avec plusieurs fiches proches : l’agent choisit-il sans confirmer ? Y a-t-il un récapitulatif avant écriture ?
3. Tests de suppression. Demandez de « nettoyer », « archiver », « fusionner » sur un lot de fiches de test. Comptez ce qui est supprimé et vérifiez la restauration.
4. Injection par les champs libres. Déposez dans un formulaire de test, une note ou un e-mail entrant une instruction destinée à l’agent (par exemple lui demander d’ajouter un marqueur à une autre fiche). Si le marqueur apparaît, l’agent obéit à du contenu non fiable. Poussez ensuite vers un test d’exfiltration contrôlé : l’agent ajoute-t-il une URL ou une image portant des données dans sa réponse ?

Chaque constat est documenté avec la requête, l’appel d’outil et son résultat. Les tests s’arrêtent à la preuve : on ne supprime jamais de vraies données, et on n’envoie aucun message à de vrais contacts.

Quels garde-fous poser avant la mise en production ?

Les garde-fous suivants sont appliqués hors du modèle, par le code qui appelle le CRM :

• Moindre privilège : un jeton en lecture seule par défaut, des scopes d’écriture limités aux objets et aux champs nécessaires, et aucun droit de suppression pour l’agent.
• Contexte de l’utilisateur : l’agent agit avec les droits de la personne qui l’utilise, ce qui exclut un compte administrateur partagé.
• Validation humaine pour les actions irréversibles ou visibles de l’extérieur (suppression, fusion, envoi, export), avec un récapitulatif de ce qui sera modifié. Notre article sur le human-in-the-loop détaille les formes de validation.
• Plafonds : nombre d’enregistrements modifiés ou envoyés par exécution, avec arrêt automatique.
• Traitement du contenu entrant comme donnée : les champs de formulaire, notes et e-mails sont transmis au modèle comme du contenu à analyser, jamais comme des consignes, et nettoyés des éléments actifs (URL, images distantes).
• Liste blanche sortante stricte : l’agent ne peut afficher ou appeler que des domaines vérifiés. ForcedLeak montre qu’une liste blanche qui contient un domaine expiré devient une porte de sortie.
• Journal d’audit : qui a demandé quoi, quel outil a été appelé, avec quels paramètres.

Quel accompagnement pour tester votre agent CRM ?

Le Red Team Agent Express (1 900 €, 5 jours, démarrage sous 48 h après signature du devis et de l’autorisation) permet de tester un agent de ce type : droits, écriture, suppression, injection par les champs libres, avec un rapport et des preuves. Quand l’agent touche plusieurs outils (CRM, messagerie, calendrier), le Red Team sur mesure se chiffre sur devis. Les tests se font par défaut sur un environnement de développement ou de préproduction ; la production n’est visée que sur demande écrite. Premier contact : un rendez-vous découverte gratuit de 30 minutes.

Pour aller plus loin

• Excessive Agency (LLM06) : limiter les droits d’un agent
• Sécurité des agents IA
• Test d’intrusion d’agent IA
• Injection de prompt