Sécurité des agents IA : les 10 risques et comment s'en protéger

Un agent IA peut divulguer des données, exécuter une action non souhaitée ou consommer des ressources au-delà du budget prévu. La sécurité d’un agent IA repose sur des droits limités, une exécution isolée, des validations ciblées et une surveillance indépendante du modèle. Ces protections réduisent les conséquences d’une erreur ou d’une attaque, sans garantir leur disparition.

Évaluer le risque à partir des accès réels

Le danger dépend des capacités accordées à l’agent : lire des documents, modifier des fichiers, envoyer des messages, appeler des services ou exécuter du code. Un objectif anodin peut devenir sensible si les outils disponibles ouvrent un accès étendu au système d’information.

L’article Agent IA ou chatbot : quelle différence ? explique pourquoi le passage de la réponse à l’action change les conséquences d’une erreur. Avant de choisir une protection, dressez l’inventaire des données accessibles, des destinations réseau et des opérations possibles.

Périmètre	Données accessibles	Actions possibles	Protection prioritaire
Résumé documentaire	Dossier sélectionné	Lecture et restitution	Limiter les documents et leurs destinataires
Assistant de messagerie	Messages et contacts autorisés	Brouillon, éventuellement envoi	Séparer rédaction et expédition
Agent de développement	Code et environnement de travail	Modification et exécution	Isoler l’exécution et protéger les secrets
Automatisation métier	Données du service connecté	Création ou modification d’enregistrements	Vérifier les droits et les paramètres côté service

Les dix risques ci-dessous constituent une sélection éditoriale, sans classement par fréquence ni reproduction d’un référentiel officiel. Pour examiner votre configuration, le diagnostic de sécurité des agents IA complète cet inventaire.

Risques 1 et 2 : instructions piégées et pouvoirs excessifs

1. L’injection de prompt détourne l’objectif

Une injection de prompt introduit des instructions malveillantes dans ce que le modèle lit. L’attaque peut venir d’un utilisateur, mais aussi d’une page web, d’un courriel ou d’un document consulté pendant une tâche. L’OWASP décrit ce mécanisme et distingue notamment les injections directes et indirectes.

Exemple hypothétique : un agent chargé de résumer une pièce jointe y rencontre une demande de transfert des documents internes vers une adresse externe. Si cette demande est traitée comme une instruction légitime, le contenu analysé prend le contrôle du travail.

Protection : séparez explicitement les consignes autorisées des contenus à analyser, puis limitez les actions possibles après leur lecture. Un filtre de texte peut contribuer à détecter certaines attaques ; il ne doit pas être la seule barrière. Testez notamment le comportement de l’agent lorsqu’un document réclame un changement de destinataire ou de permissions.

2. Des permissions excessives amplifient chaque erreur

Un agent de synthèse documentaire n’a pas besoin de supprimer les documents qu’il consulte. Pourtant, une connexion générale à un compte peut lui donner cette possibilité. L’OWASP rattache l’autonomie excessive à des fonctions, permissions ou capacités de décision trop étendues.

Protection : appliquez le moindre privilège à chaque outil : lecture seule si elle suffit, dossiers désignés, compte dédié et opérations explicitement autorisées. Retirez aussi les connecteurs devenus inutiles.

Les restrictions doivent être imposées par les logiciels et les services connectés. Une phrase demandant au modèle de ne jamais supprimer de fichier laisse subsister le danger si son compte possède toujours le droit de suppression.

Risques 3 et 4 : fuite de données et usurpation des droits

3. Des informations confidentielles sortent du périmètre prévu

Une fuite ne nécessite pas le téléchargement d’une base entière. Un extrait de contrat placé dans une requête, une pièce jointe envoyée au mauvais destinataire ou un secret conservé dans une trace peuvent suffire.

Cartographiez le trajet des informations : source documentaire, modèle sollicité, outils intermédiaires, stockage des conversations et journaux. Distinguez les transferts nécessaires au fonctionnement de ceux qu’une action de l’agent pourrait déclencher. Vérifiez les conditions du service utilisé avant d’y envoyer des données sensibles.

Protection : fournissez seulement les informations utiles à la tâche. Conservez les identifiants techniques dans un gestionnaire de secrets et faites-les utiliser par le connecteur sans les afficher au modèle lorsque l’architecture le permet. Restreignez les destinations réseau, puis masquez les données sensibles dans les traces.

Le cas d’un assistant de messagerie illustre la limite : retirer l’outil d’envoi réduit un canal de fuite, mais un accès réseau général peut en laisser d’autres ouverts.

4. L’agent agit avec les droits de la mauvaise personne

Dans un service partagé, l’agent peut disposer d’un compte technique plus puissant que celui du demandeur. Il devient alors un intermédiaire capable d’obtenir un document ou de modifier un dossier que cette personne ne devrait pas atteindre.

La documentation de sécurité MCP traite notamment des confusions d’autorisation et de la validation des jetons d’accès. Le protocole ne remplace pas les contrôles d’identité des applications.

Protection : rattachez chaque opération à l’utilisateur et à l’organisation concernés. Le service métier doit vérifier leurs droits au moment de l’action, même si la requête arrive par un agent reconnu. Utilisez des identifiants distincts selon les fonctions et prévoyez leur révocation.

Un test utile consiste à demander, depuis un compte de test, un document réservé à un autre compte. Le refus doit venir du système d’autorisation, indépendamment de la réponse du modèle.

Risques 5 et 6 : extensions compromises et exécution dangereuse

5. Un serveur MCP ou une compétence introduit du code malveillant

Ajouter un connecteur, une compétence ou une dépendance étend la chaîne logicielle dont vous dépendez. Un nom rassurant, une description convaincante ou une forte popularité ne prouvent pas que le composant respecte votre périmètre.

Le travail de l’OWASP sur les menaces agentiques inclut les compromissions de la chaîne d’approvisionnement. Cette menace concerne aussi les ressources chargées par l’agent après son installation initiale.

Protection : vérifiez l’identité du mainteneur, le dépôt de référence, les permissions demandées et les dépendances. Examinez particulièrement les scripts exécutés à l’installation et les accès réseau. Dans un environnement sensible, validez une révision déterminée et soumettez les mises à jour à une nouvelle vérification.

Installez d’abord le composant dans un environnement sans données confidentielles. Contrôlez son comportement avant de lui donner accès aux comptes réels. L’article consacré aux serveurs MCP et skills malveillants détaille cette vérification.

6. Du code généré s’exécute hors d’un environnement maîtrisé

Un agent doté d’un terminal peut lancer des programmes, modifier des fichiers et installer des dépendances. Une commande syntaxiquement correcte peut supprimer des données ou transmettre un secret. La lecture du code produit ne suffit donc pas à définir une frontière de sécurité.

Protection : exécutez les tâches dans un bac à sable, avec un compte sans privilèges administratifs, un dossier de travail dédié et des sorties réseau contrôlées. Ne montez que les répertoires nécessaires et évitez d’exposer les identifiants de votre session habituelle.

Anthropic explique dans sa présentation technique du sandboxing pourquoi l’isolation doit couvrir le système de fichiers et le réseau. Vérifiez ce que votre environnement bloque réellement : un conteneur disposant d’accès étendus à la machine hôte peut conserver des capacités dangereuses.

Risques 7 et 8 : mémoire contaminée et actions mal validées

7. Une information piégée devient une mémoire durable

Une instruction rencontrée pendant une tâche peut être enregistrée dans des notes, un profil utilisateur ou une base documentaire. Si elle est réutilisée ensuite, le problème persiste après la disparition du document d’origine.

L’empoisonnement de la mémoire fait partie des menaces étudiées dans le référentiel agentique de l’OWASP mentionné plus haut. Il faut donc examiner ce qui entre en mémoire, mais aussi ce qui en ressort et pour quel utilisateur.

Protection : séparez les préférences explicitement validées, les observations de travail et les contenus externes. Conservez leur provenance et leur date d’enregistrement. Prévoyez une consultation et une suppression ciblées.

Une suggestion provenant d’une page ne devrait pas devenir automatiquement une règle permanente. Lors d’un test, faites enregistrer une information inoffensive mais incorrecte, puis vérifiez que vous pouvez la retrouver, la corriger et empêcher sa réutilisation. Les mémoires partagées doivent aussi respecter les frontières entre utilisateurs.

8. Une sortie plausible déclenche une mauvaise opération

Un nom de client mal interprété, un chemin de fichier incorrect ou un paramètre absent peuvent transformer une réponse convaincante en action dommageable. L’OWASP décrit les risques des sorties insuffisamment validées lorsqu’elles sont transmises à d’autres composants.

Protection : imposez des paramètres structurés et vérifiez les valeurs côté application : destinataire autorisé, montant acceptable, fichier situé dans le dossier prévu et opération compatible avec l’état actuel. Pour une base de données, utilisez des requêtes paramétrées et des droits adaptés.

Avant une action sensible, affichez les paramètres effectifs : contenu envoyé, destinataires, pièces jointes, modification proposée et conséquence attendue. Un résumé rédigé par le modèle ne remplace pas cet aperçu.

L’approbation doit porter sur l’action exécutée. Si les paramètres changent ensuite, demandez une nouvelle validation ; pour les suppressions et les modifications importantes, prévoyez également une restauration vérifiable.

Risques 9 et 10 : dépenses incontrôlées et incidents invisibles

9. Une boucle consomme le budget ou sature le service

Un agent peut répéter une tentative, relancer un outil en échec ou déléguer du travail sans progresser. Un attaquant peut aussi exploiter les ressources disponibles. L’OWASP documente la consommation sans limites comme un risque de disponibilité et de coût.

Protection : fixez des plafonds par tâche et par utilisateur : durée, appels, dépenses, taille des entrées et tâches simultanées. Ces plafonds doivent être contrôlés par l’application qui orchestre l’agent.

Définissez un arrêt sur absence de progression ou répétition d’erreurs. Le budget doit inclure les services facturés autour du modèle, par exemple l’exécution distante ou les recherches payantes. Vérifiez aussi si le seuil annoncé par un prestataire bloque les dépenses ou envoie seulement une alerte.

10. L’incident reste invisible et se propage

Sans traces exploitables, vous ne savez pas quel outil a agi, sur quelles données ni avec quelle autorisation. Une automatisation suivante peut reprendre le résultat erroné et prolonger le problème.

Protection : journalisez l’identité du demandeur, les outils appelés, les validations, les résultats et les erreurs. Limitez l’accès aux journaux et évitez d’y recopier intégralement les documents ou les secrets. Leur contenu peut lui-même devenir sensible.

Prévoyez des alertes sur les destinations inhabituelles, les échecs répétés et les changements de permissions. Le guide pour surveiller un agent IA en production approfondit l’organisation de ces contrôles.

Enfin, désignez une personne capable d’interrompre l’agent et de révoquer ses accès. Le bouton d’arrêt doit empêcher de nouvelles actions, y compris celles déjà mises en file d’attente lorsque le système le permet. Testez ce comportement avant de confier une tâche sensible.

Mettre les protections à l’épreuve avant le déploiement

Commencez avec des données fictives et des comptes de test. Décrivez les actions permises, les interdictions et les situations exigeant une validation humaine. Le résultat attendu doit être observable : refus d’accès, opération bloquée ou tâche interrompue.

Soumettez ensuite l’agent à des situations dégradées. Présentez un document contenant une instruction contradictoire, demandez un fichier hors périmètre et faites échouer un outil. Vérifiez que l’agent ne cherche pas un accès plus large pour contourner l’obstacle et que l’application bloque effectivement ce dépassement.

Testez aussi la récupération. Une sauvegarde ne constitue une protection opérationnelle que si la restauration fonctionne. Pour un message envoyé ou une information divulguée, le retour arrière peut être impossible : la prévention et la limitation du périmètre prennent alors davantage de poids.

Consignez les résultats et les limites connues. Reprenez ces vérifications après un changement de modèle, de connecteur ou de permissions, car le comportement du système peut changer même si l’objectif reste identique. Le guide pour sécuriser un agent IA permet de transformer ces principes en configuration détaillée.

Avant l’ouverture aux données réelles :

• Les accès correspondent aux besoins de la tâche et utilisent des comptes dédiés.
• Les actions sensibles montrent leurs paramètres effectifs avant validation.
• L’exécution, les destinations réseau et les dépenses sont limitées techniquement.
• Les mémoires et les journaux sont consultables sans exposer les secrets.
• L’arrêt, la révocation des accès et la restauration ont été vérifiés.

À retenir

• Le risque dépend des outils, des données et des droits accordés à l’agent.
• Une consigne écrite au modèle doit être complétée par des restrictions appliquées dans les systèmes connectés.
• La validation humaine aide lorsqu’elle présente une action concrète et compréhensible.
• Les protections doivent être testées, puis réexaminées lorsque la configuration évolue.

Questions fréquentes

Un agent IA en local est-il forcément sécurisé ?

L'exécution locale réduit certains transferts vers des prestataires, mais ne limite pas automatiquement les accès aux fichiers ou au réseau. Vérifiez aussi les connecteurs, la télémétrie et les services distants sollicités pendant une tâche.

Un antivirus suffit-il pour protéger un agent IA ?

Un antivirus peut détecter certains fichiers malveillants, mais une action dangereuse peut utiliser une API autorisée sans installer de logiciel. Il faut donc également contrôler les identités, les permissions et les opérations permises.

Peut-on laisser un agent IA travailler sans surveillance ?

Cela dépend du périmètre autorisé et des conséquences d'une erreur. Une tâche limitée, réversible et surveillée techniquement peut tolérer davantage d'autonomie qu'une tâche donnant accès à des comptes clients ou à des moyens de paiement.

Comment évaluer la sécurité d'un agent IA avant de l'installer ?

Demandez où les contrôles sont appliqués, quels accès sont nécessaires et comment les révoquer. Une démonstration du refus d'une action interdite apporte davantage d'éléments qu'une simple déclaration de sécurité.