Sécuriser les agents IA dans le retail : commandes, données clients et opérations métier

Chaque scénario suit la même progression : la situation métier et la valeur attendue, les identités humaines et non humaines concernées, les applications, API, outils et données mobilisés, les actions autorisées et interdites, les risques et contournements possibles, les contrôles techniques et leur point d’application, puis les événements et preuves à conserver.

Un artisan utilise un assistant IA pour préparer les achats de ses chantiers. L’agent consulte son historique, recherche des produits, vérifie les stocks, prépare un panier et organise un retrait en dépôt. La valeur est réelle : moins de saisie, moins d’allers-retours, une commande prête à valider.

La première question est celle des identités. L’artisan est un humain authentifié ; l’assistant possède sa propre identité technique, distincte, avec un propriétaire et un cycle de vie. Si l’assistant est fourni par un tiers externe au distributeur, la donne change : le distributeur ne gouverne ni son code ni ses instructions, et ne peut compter que sur ce qu’il contrôle directement — ses API et ses points d’enforcement.

La seconde question est celle du mandat. L’artisan délègue une mission précise : préparer des achats. Ce mandat doit être vérifié à chaque action, pas seulement à la connexion. Les opérations ne se valent pas :

Lecture

Consulter l’historique, les produits, les stocks : faible effet, mais accès à des données commerciales.

Préparation

Composer un panier, simuler un retrait : aucun effet comptable, mais des données manipulées.

Modification

Changer une quantité ou une adresse de livraison : effet sur des données existantes.

Validation

Confirmer une commande : effet financier, réservé à un humain ou à un périmètre strictement délimité.

Exécution

Déclencher le paiement ou la facturation : effet difficilement réversible, validation humaine systématique.

Les risques suivent cette gradation. Un agent qui prépare un panier ne doit pas pouvoir modifier un prix, confirmer une commande ni accéder au compte d’un autre client professionnel. Le contournement consiste ici à appeler directement l’API de commande avec un token trop large, ou à détourner un outil de lecture pour atteindre les données d’autres clients.

Le contrôle se place devant les API transactionnelles : un point d’enforcement intercepte chaque opération et la soumet à une décision fondée sur l’identité de l’agent, le mandat de l’artisan, l’action, la ressource et le contexte. La mécanique de ces décisions est détaillée dans l’autorisation fine d’un agent IA, et le placement du contrôle devant les API dans sécuriser les API appelées par un agent.

Côté preuves, chaque étape doit être reconstructible : qui a demandé, quel agent a préparé, quelle décision a été prise, par quel composant elle a été appliquée, et ce que l’API a réellement exécuté.

Un distributeur multi-enseignes donne à plusieurs agents l’accès à une base de connaissances commune : stocks, fournisseurs, marges, magasins, commandes. Les agents partagent l’infrastructure, mais pas les droits : un agent d’approvisionnement national et un agent rattaché à un magasin régional ne doivent pas voir les mêmes marges ni les mêmes conditions fournisseurs.

Trois mécanismes distincts sont souvent confondus. Le RAG récupère des documents au moment de la question. La mémoire persistante conserve des informations entre les conversations. Le graphe de connaissances matérialise des relations entre entités. Chacun appelle ses propres contrôles : filtrage des résultats pour le RAG, cloisonnement et expiration pour la mémoire, contrôle d’accès aux relations pour le graphe.

L’isolation porte sur plusieurs axes : enseignes, entités juridiques, zones géographiques. Elle repose sur la classification des données avant indexation et sur des métadonnées conservées jusqu’au niveau le plus fin — document, extrait, champ. Une politique peut alors refuser qu’un extrait classé « négociation fournisseur » soit restitué à un agent rattaché à une autre enseigne. La mécanique de ce filtrage est détaillée dans sécuriser le RAG d’un agent IA.

Les risques propres à ce partage : un contenu injecté dans une source indexée, comme une fausse procédure déposée dans un espace fournisseur ; une mémoire persistante qui fuit d’une enseigne à l’autre ; un agent qui agrège des fragments autorisés pour reconstruire une information interdite. Le contrôle doit donc porter aussi sur ce qui est effectivement restitué à chaque agent, et pas seulement sur ce qui est indexé.

Les preuves attendues : pour chaque réponse, quels documents ou extraits ont été envoyés au modèle, au titre de quelle politique, avec quelle décision. Journaliser la requête sans les éléments restitués ne permet pas de savoir ce que l’agent a réellement vu.

Un agent aide une équipe opérationnelle à diagnostiquer un incident sur une application de magasin : il consulte des journaux, recherche une procédure et propose une correction. La valeur est un diagnostic plus rapide ; le risque est un agent qui répare sans y être autorisé.

Quatre étapes doivent rester distinctes :

Diagnostiquer est une lecture : journaux, métriques, procédures. Préparer un correctif produit un artefact — une commande, un script, un patch — qui n’a encore aucun effet. Exécuter une commande modifie un système. Déployer en production généralise l’effet. Chaque passage d’une étape à la suivante est une décision d’autorisation distincte, et les deux dernières exigent une validation humaine explicite.

Les contrôles se répartissent : l’autorisation décide si l’agent peut exécuter cette commande sur ce système ; la sécurité du code vérifie le correctif proposé avant qu’il ne progresse ; la protection runtime limite ce que le workload de l’agent peut exécuter même si une commande passe. Les outils capables d’exécuter des opérations métier relèvent des contrôles décrits dans sécuriser les MCP d’un agent IA, et la limitation du workload dans sécuriser le runtime des agents.

Le contournement typique : l’agent, bloqué sur la commande prévue, en tente une variante équivalente, ou réutilise un credential présent dans son environnement d’exécution. Les preuves à conserver couvrent le diagnostic (ce que l’agent a lu), la proposition (l’artefact produit), la validation (qui a approuvé quoi) et l’exécution (ce qui a réellement été lancé, avec quel résultat).

Les trois scénarios réutilisent la même architecture : identités gouvernées, credentials hors de portée de l’agent, décision d’autorisation externalisée, enforcement sur un chemin obligatoire, protection du runtime et preuves corrélées. Le guide architecture de sécurité d’un agent IA décrit cette chaîne couche par couche.