Un agent IA capable de lire votre boîte de réception, de mettre à jour les fiches clients ou d’exécuter du code a besoin de bien plus qu’un ensemble d’instructions bien rédigées. Il a besoin de limites claires quant à ce à quoi il peut accéder, ce qu’il peut modifier et ce qu’il peut partager.
L'intégration de l'IA aux systèmes d'entreprise offre la possibilité de réduire le travail manuel et d'accélérer la prise de décision. Elle ouvre également la voie à des attaquants qui pourraient manipuler ces décisions, voler des informations ou déclencher des actions via des outils légitimes.
Le Top 10 de l’OWASP pour les applications agentiques fournit un cadre permettant de comprendre et d’évaluer les risques de sécurité liés aux agents IA. En nous appuyant sur ces recommandations, nous explorons dix menaces clés et les mesures concrètes que les organisations peuvent prendre pour y faire face.
Un agent IA est un système logiciel qui utilise l’intelligence artificielle pour effectuer des tâches pour le compte d’un utilisateur ou d’une organisation. Il est capable d’interpréter un objectif, de décider des étapes à suivre et d’utiliser les outils connectés pour les mener à bien, avec différents niveaux de supervision humaine.
Un agent connecté à votre boîte de réception, à votre base de données clients ou à votre environnement cloud doit être soumis à des limites claires quant à ce qu’il peut consulter, modifier et partager. Sans ces contrôles, une instruction malveillante ou une décision erronée pourrait entraîner la fuite de données, des transactions non autorisées ou la perturbation des opérations.
La sécurité des agents IA consiste à protéger les systèmes d’IA capables de planifier des tâches, d’utiliser des outils et d’agir pour le compte d’utilisateurs ou d’organisations. Elle couvre l’agent lui-même, ses applications connectées, ses autorisations d’accès et les informations qu’il traite.
Un chatbot dont le rôle se limite à répondre à des questions présente un profil de risque différent de celui d’un agent autorisé à envoyer des e-mails, à modifier des configurations ou à valider des transactions. Lorsque l’IA est capable d’agir, une réponse erronée ou manipulée peut se transformer en incident opérationnel.
L’injection de commandes se produit lorsque des instructions malveillantes influencent le comportement d’un système d’IA. Avec les agents, ces instructions peuvent parvenir indirectement via une page web, un e-mail, un document ou la réponse d’un outil rencontrés au cours d’une tâche légitime.
Par exemple, un agent examinant un document fournisseur pourrait rencontrer des instructions lui demandant de récupérer des informations confidentielles et de les envoyer ailleurs. L’attaquant tente de transformer les éléments que l’agent est censé analyser en commandes qu’il doit exécuter.
Il s’agit d’un défi de sécurité permanent, et les mesures de protection des modèles ne suffisent pas à elles seules à éliminer ce risque.
Comment réduire le risque : considérez le contenu externe comme non fiable. Limitez les outils et les destinations auxquels l’agent a accès, filtrez les entrées suspectes et exigez une validation pour les actions sensibles. Appliquez des restrictions d’accès en dehors du modèle linguistique afin que des instructions manipulées ne puissent pas simplement les contourner.
Un agent devient plus dangereux lorsque ses autorisations dépassent le cadre de sa mission. Un assistant chargé de l’établissement de rapports peut avoir besoin de consulter des documents financiers, mais n’a aucune raison de les modifier ou d’initier des paiements.
Le même principe s’applique à l’autonomie. Même une action autorisée peut nécessiter une validation humaine si elle implique la suppression de données, la modification de paramètres de sécurité ou la prise d’un engagement externe.
L’OWASP identifie les fonctionnalités, autorisations et autonomies excessives comme des causes sous-jacentes d’une autonomie excessive de l’agent.
Comment réduire le risque : définissez l’accès minimal nécessaire pour chaque tâche. Séparez les capacités de lecture et d’écriture, limitez les fonctions disponibles et mettez en place des étapes d’approbation proportionnées à l’impact potentiel. Réexaminez les autorisations chaque fois que les responsabilités d’un agent changent.
Un agent IA peut fonctionner via des comptes de service, des clés API, des jetons d’accès ou des autorisations déléguées par un utilisateur. Si ces identifiants sont volés ou utilisés à mauvais escient, un attaquant peut accéder aux mêmes systèmes connectés.
Le partage d’identités affaiblit également la traçabilité. Si plusieurs agents utilisent un seul compte disposant de droits étendus, il devient plus difficile d’identifier quel agent a effectué une action, qui l’a autorisée et quels droits d’accès doivent être révoqués.
Les travaux du NIST sur l’identité et l’autorisation des agents IA reflètent l’importance d’appliquer des contrôles d’identité à ces systèmes.
Comment réduire le risque : attribuez aux agents des identités distinctes et traçables lorsque cela est possible, avec des propriétaires désignés et des cycles de vie définis. Utilisez des identifiants à durée de vie courte et à portée restreinte, et assurez une gestion sécurisée des secrets. Préservez le lien entre les actions d’un agent et l’utilisateur ou le processus qui les a autorisées.
Les agents peuvent rassembler des informations provenant de plusieurs systèmes d’entreprise. En l’absence de restrictions appropriées, ils peuvent exposer des données à caractère personnel, des documents confidentiels ou des informations commercialement sensibles par le biais de réponses, de messages, de journaux ou de services connectés.
Prenons l’exemple d’un agent du service client qui récupère une note interne relative à un compte et l’inclut dans une réponse externe. Cette divulgation peut résulter de contrôles d’accès insuffisants ou d’une mauvaise décision, sans qu’un attaquant soit impliqué. La divulgation d’informations sensibles est un risque reconnu dans les applications LLM.
Comment réduire ce risque : appliquez une classification des données et des contrôles d’accès avant que les informations ne parviennent à l’agent. Limitez la consultation aux utilisateurs, clients et tâches concernés. Utilisez des contrôles de prévention des pertes de données, restreignez les destinations sortantes et vérifiez comment les fournisseurs et les intégrations gèrent la conservation et la journalisation.
Les agents dépendent de composants allant au-delà du modèle sous-jacent, notamment des bibliothèques logicielles, des plugins, des connecteurs et des services externes. Une dépendance vulnérable ou compromise peut compromettre un déploiement par ailleurs bien contrôlé.
Les serveurs MCP (Model Context Protocol), lorsqu’ils sont utilisés pour connecter les agents aux outils et aux données, font également partie de cette évaluation. Une intégration pratique doit tout de même faire l’objet d’un examen minutieux de ses autorisations, de son comportement et de sa maintenance.
La sécurité de la chaîne d’approvisionnement de l’IA doit donc couvrir les composants entourant le modèle ainsi que le modèle lui-même.
Comment réduire le risque : tenezà jour un inventaire des dépendances et des intégrations approuvées. Vérifiez leur origine, évaluez les autorisations demandées, surveillez les vulnérabilités et examinez les mises à jour. Testez les modifications avant leur déploiement, en particulier lorsqu’une intégration peut exécuter des commandes ou accéder à des informations sensibles.
Les décisions d’un agent dépendent des informations qu’il reçoit et conserve. Les attaquants peuvent altérer les sources de connaissances ou la mémoire stockée afin que du contenu trompeur influence les tâches ultérieures.
Par exemple, une fausse instruction enregistrée comme préférence de confiance pourrait rediriger de manière répétée le comportement d’un agent. Contrairement à une simple invite malveillante, une contamination persistante peut affecter les sessions suivantes. L’OWASP inclut l’empoisonnement de la mémoire et du contexte parmi les risques de sécurité liés aux agents.
Comment réduire le risque : contrôlez qui peut mettre à jour les sources de connaissances et la mémoire de l’agent. Enregistrez la provenance des informations, conservez l’historique des versions et exigez une validation avant qu’un contenu non fiable ne devienne une directive persistante. Permettez la suppression des enregistrements contaminés et la restauration d’un état connu pour être correct.
Les agents qui génèrent du code, des requêtes de base de données ou des commandes présentent un risque lorsque leurs résultats sont directement transmis à l’exécution.
Une requête apparemment raisonnable peut produire une commande non sécurisée ou une requête dont la portée est incorrecte. Des entrées malveillantes peuvent également exploiter une validation insuffisante pour atteindre les systèmes en aval. Les recommandations de l’OWASP sur la gestion inappropriée des résultats décrivent comment un contrôle insuffisant peut permettre des attaques par injection et l’exécution de code.
Comment réduire le risque : Traitez les résultats générés comme des entrées non fiables. Validez les arguments des outils, utilisez des requêtes de base de données paramétrées et limitez l’exécution à des environnements isolés. Privilégiez les opérations étroitement définies plutôt qu’un accès shell illimité, et conservez les secrets de production en dehors des environnements d’exécution, sauf si cela est explicitement requis.
Lorsque plusieurs agents collaborent, une erreur ou une compromission chez l’un d’entre eux peut avoir des répercussions sur les autres. Un agent de recherche peut fournir une conclusion erronée qu’un autre agent accepte comme référence pour mettre à jour un système.
Cela crée un risque de propagation des erreurs à travers un flux de travail, en particulier lorsque les agents partagent de la mémoire, des outils ou des autorisations étendues. Un transfert réussi ne garantit pas que les informations sous-jacentes ou l’action demandée soient fiables.
Comment réduire ce risque : authentifiez les communications entre agents et validez les requêtes à chaque transfert. Conservez les informations relatives aux sources et aux autorisations. N’accordez à chaque agent que l’accès nécessaire à son rôle, et mettez en place des points de contrôle avant qu’une chaîne de décisions n’aboutisse à une action à fort impact.
Les workflows des agents peuvent appeler des modèles, interroger des services ou créer des tâches supplémentaires de manière répétée. Des conditions d’arrêt inadéquates, des entrées inattendues ou des abus délibérés peuvent entraîner une consommation excessive.
Il peut en résulter une escalade des coûts, l’épuisement des quotas d’API et une disponibilité réduite pour les autres utilisateurs. L’OWASP décrit le risque plus général lié à l’utilisation incontrôlée des ressources des modèles comme une « consommation illimitée ».
Comment réduire le risque : fixez des limites contraignantes en matière de dépenses, de durée d’exécution, de tentatives de réessai, de tâches simultanées et d’appels d’outils. Déclenchez des alertes en cas d’activité inhabituelle et interrompez les workflows qui dépassent les seuils convenus. Testez les conditions d’échec, notamment l’indisponibilité des services et les actions infructueuses répétées, avant d’étendre le déploiement.
Un agent peut causer des dommages sans pour autant avoir été compromis. Il peut mal interpréter une requête, travailler à partir d’informations incomplètes ou choisir une action inappropriée. Une confiance excessive transforme ces défaillances en risque opérationnel.
L’approbation humaine n’est utile que lorsque le vérificateur peut voir ce qui va se passer. Un message de confirmation vague est insuffisant pour un paiement, une modification d’accès ou une suppression en masse. La surveillance est tout aussi importante : les équipes doivent déterminer ce que l’agent a réellement fait.
Comment réduire le risque : montrez aux responsables de la validation l’action proposée, les systèmes concernés et les preuves pertinentes. Enregistrez les appels aux outils, les validations et les résultats, tout en protégeant le contenu sensible des journaux. Fournissez aux intervenants des procédures éprouvées pour suspendre les agents, révoquer les identifiants, préserver les preuves et annuler les modifications lorsque cela est possible.
Commencez par les agents qui combinent l’accès à des données sensibles, des outils puissants et la capacité d’agir sans autorisation. Un assistant répondant à des questions à partir de documents publics présente un niveau d’exposition différent de celui d’un agent modifiant des systèmes de production.
Pour chaque déploiement, définissez :
Utilisez ces réponses pour hiérarchiser les tests et les mesures correctives. Réévaluez la situation chaque fois que les modèles, les outils, les autorisations ou les workflows changent, car le périmètre d’accès d’un agent peut s’étendre bien après son autorisation initiale.
Chaque nouvelle connexion élargit le champ d’action d’un agent. Elle peut également aggraver les conséquences d’une erreur ou d’une compromission. Les décisions en matière de sécurité doivent suivre le rythme de cette expansion des accès.
Pour les entreprises qui adoptent l’IA agentique, les priorités sont claires : gérer les identités des agents, protéger les données sensibles, limiter les actions et rendre les activités visibles aux personnes chargées de défendre l’organisation.
Contactez Integrity360 pour sécuriser l’adoption de l’IA au niveau des identités, des données et des opérations métier.
Quelle est la différence entre la sécurité de l'IA et la sécurité des agents IA ?
La sécurité de l’IA couvre la protection des modèles, des données et des applications d’IA. La sécurité des agents IA met particulièrement l’accent sur les systèmes qui utilisent des outils et effectuent des actions, notamment leurs autorisations, les pouvoirs qui leur sont délégués, leurs connexions et leur capacité à influencer d’autres systèmes.
Peut-on empêcher totalement l’injection de prompt ?
Les entreprises ne doivent pas partir du principe que l’injection de prompts peut être éliminée. Les mesures de défense peuvent réduire le nombre d’attaques réussies, mais les déploiements doivent également limiter les actions qu’un agent peut effectuer en cas de manipulation réussie. Restreindre l’accès et contrôler les actions sensibles permet de limiter les dommages potentiels.
Pourquoi la gestion des identités est-elle importante pour les agents d’IA ?
La gestion des identités permet de déterminer quel agent agit, à quoi il a accès et qui en est responsable. Des identités distinctes, des autorisations limitées et des identifiants révocables favorisent la responsabilisation et facilitent la maîtrise des agents compromis ou défaillants.
Les agents IA ont-ils besoin d’une validation humaine pour chaque action ?
L’autorisation doit refléter les conséquences d’une action. Les tâches routinières à faible impact peuvent s’effectuer dans des limites prédéfinies. Les paiements, les divulgations sensibles, les modifications destructrices et les opérations privilégiées justifient des contrôles plus stricts. Ces contrôles doivent être appliqués par l’application ou le système connecté.
Que doivent faire les entreprises avant de déployer un agent IA ?
Définir son objectif, désigner un responsable, cartographier ses accès aux données et aux systèmes, et fixer des limites d’autorisation. Tester l’ensemble du flux de travail face à des scénarios d’utilisation abusive et de défaillance. Mettre en place un suivi, des exigences d’approbation et un moyen pratique d’arrêter l’agent avant de lui accorder l’accès aux systèmes opérationnels de l’entreprise.