Pourquoi les agents augmentent la surface de risque
Un chatbot classique reçoit un message et produit une réponse. Un agent IA peut en plus appeler des APIs, lire des fichiers, interroger une base, envoyer un email ou déclencher une action.
Cette capacité transforme une erreur de prompt en risque opérationnel réel. Le problème n’est plus seulement une mauvaise réponse, mais une lecture ou une transmission de données non autorisée.
La sécurité doit donc être conçue au niveau des outils, des permissions et des données, pas uniquement au niveau du prompt système.
Le prompt injection peut provoquer une fuite de données
Un contenu externe peut contenir des instructions conçues pour détourner l’agent : document, email, page web, ticket support ou donnée issue d’un RAG.
Si l’agent traite ces instructions comme fiables, il peut être amené à révéler des informations, utiliser un outil non prévu ou contourner la tâche demandée.
Il faut considérer tout contenu récupéré comme non fiable, séparer instructions système et données, et limiter strictement les outils disponibles.
Appliquer le principe du moindre privilège aux outils
Un agent qui doit lire le statut d’une commande n’a pas besoin d’un accès générique en écriture à toute la base de données.
Chaque outil doit exposer une opération métier précise, avec des paramètres limités, des contrôles d’autorisation et des validations côté serveur.
Les credentials utilisés par l’agent doivent avoir moins de droits que ceux d’un administrateur humain, jamais plus.
Empêcher les fuites entre tenants dans un RAG
Dans un SaaS multi-tenant, le filtre d’organisation doit être appliqué avant la recherche vectorielle et non après la récupération des documents.
Un embedding proche sémantiquement ne doit jamais suffire à rendre un document accessible. Les droits métier restent prioritaires sur la similarité.
Les tests doivent inclure des scénarios de fuite inter-tenant, car une erreur de filtre peut exposer des données sans provoquer d’exception technique.
Ne pas envoyer les secrets au modèle
Tokens OAuth, clés API, mots de passe, chaînes de connexion et secrets techniques ne doivent jamais être placés dans le contexte du modèle.
Les outils doivent utiliser leurs propres credentials côté serveur et retourner uniquement le résultat métier nécessaire.
Lorsqu’un agent doit agir au nom d’un utilisateur, un mécanisme d’autorisation déléguée et limitée dans le temps est préférable à l’exposition directe d’un secret.
Journaliser sans recréer une fuite dans les logs
Les logs sont essentiels pour comprendre ce qu’un agent a fait, mais ils peuvent eux-mêmes devenir une source de fuite si chaque prompt et chaque réponse sont conservés en clair.
Il faut privilégier les identifiants de corrélation, métadonnées, décisions, noms d’outils et statuts, avec masquage des données personnelles ou sensibles.
Les logs contenant réellement du contenu doivent avoir une politique de rétention courte et des contrôles d’accès plus stricts.
Mettre un humain dans la boucle pour les actions sensibles
Suppression de données, transfert financier, changement de droits, envoi massif ou transmission de documents sensibles ne devraient pas être exécutés automatiquement sur la seule décision du modèle.
L’agent peut préparer l’action, expliquer ce qu’il va faire et demander une confirmation explicite avant l’exécution.
Cette validation réduit fortement l’impact d’une hallucination, d’un prompt injection ou d’un mauvais contexte.
