Votre nouvel agent IA lit des e-mails, appelle des API, met à jour des enregistrements CRM et envoie des messages au nom de votre entreprise. C’est précisément ce qui le rend utile — et c’est précisément pour cette raison que sa posture de sécurité mérite un examen bien plus rigoureux qu’une intégration SaaS classique.
La sécurité applicative traditionnelle a été conçue pour des systèmes qui répondent à des utilisateurs authentifiés. Les agents IA sont différents : l’agent décide de manière autonome de ce qu’il faut faire, quels outils invoquer et dans quel ordre, en s’appuyant sur des entrées en langage naturel provenant d’utilisateurs, de données externes et même d’autres agents. Cette autonomie crée une surface d’attaque que la plupart des équipes IT n’ont pas encore cartographiée.
Cet article couvre les risques réels des systèmes agentiques en production — prompt injection, abus d’outils et exfiltration de données — ainsi que les mesures d’atténuation pratiques dont disposent aujourd’hui les responsables informatiques.
Pourquoi la sécurité des agents IA requiert son propre cadre
La modélisation des menaces traditionnelle porte sur l’authentification, l’autorisation et les données en transit. Ces contrôles restent essentiels. Mais les systèmes agentiques ajoutent trois propriétés qui créent de nouvelles expositions :
- Ils consomment des contenus non fiables comme instructions. Un agent qui résume un PDF, traite un e-mail entrant ou lit une page web exécute des opérations sur des contenus qu’il n’a pas produits. Ces contenus peuvent contenir des instructions adversariales.
- Ils détiennent des credentials et peuvent effectuer des actions. Un agent connecté à votre agenda, à votre ERP ou à votre file store peut lire, écrire et supprimer — pas seulement consulter.
- Leur raisonnement est opaque. Contrairement à un script déterministe, le chemin d’un agent de l’entrée à l’action n’est pas toujours prévisible, ce qui rend la détection des anomalies plus difficile.
Ces trois propriétés se combinent pour créer des vecteurs d’attaque qui n’ont pas d’équivalent direct dans les logiciels conventionnels.
Les trois vecteurs d’attaque principaux dans la sécurité des agents IA
1. Prompt Injection — le vecteur d’attaque le plus documenté
La prompt injection est le risque le mieux documenté dans les systèmes agentiques déployés en production. Le principe : un attaquant incorpore des instructions adversariales dans des contenus que l’agent va traiter — un document, un message client, une page web. L’agent, incapable de distinguer l’instruction intégrée d’une instruction légitime, l’exécute.
L’injection directe cible le system prompt ou l’interface utilisateur. Un employé qui pose à un agent RH interne une question malveillante dans l’espoir d’extraire les données salariales d’un collègue est un exemple d’injection directe.
L’injection indirecte est plus subtile et plus difficile à contrer. Un client envoie un ticket de support contenant des instructions cachées — peut-être du texte blanc sur fond blanc dans une pièce jointe — ordonnant à l’agent de transférer le résumé de la conversation vers une adresse externe. L’agent lit le document dans le cadre de son workflow et, sans garde-fous appropriés, exécute la commande dissimulée.
Des attaques par injection indirecte ont été démontrées sur des systèmes en production connectés à des e-mails, des navigateurs et des document stores. Parmi les divulgations publiques notables : EchoLeak (CVE-2025-32711, CVSS 9.3) — une injection par e-mail corrigée dans Microsoft 365 Copilot —, la vulnérabilité de fuite de données dans les canaux privés de Slack AI (août 2024) et CVE-2025-53773 pour GitHub Copilot. La taxonomie académique fondatrice de Greshake et al. (2023) a démontré des attaques sur les e-mails, les navigateurs et les document stores.
Mesures d’atténuation pratiques pour ce trimestre :
- Appliquez une validation stricte des entrées/sorties à chaque limite d’outil — traitez les données lues par l’agent comme non fiables, distinctes des instructions qu’il reçoit.
- Utilisez des system prompts séparés qui contraignent explicitement les actions autorisées de l’agent ; maintenez la surface d’instruction aussi étroite que le cas d’usage l’exige.
- Mettez en place un filtrage des sorties pour détecter les patterns de données inattendus (par ex., des adresses e-mail ou des clés API apparaissant dans les réponses de l’agent là où elles ne devraient pas figurer).
2. Abus d’outils — quand le scope creep devient une vulnérabilité
Les agents tirent leur puissance des outils : la capacité d’appeler des API, d’exécuter des requêtes, d’écrire des fichiers, d’envoyer des messages. Cette puissance nécessite des limites de périmètre explicites. Sans elles, une légère manipulation du prompt peut amener l’agent à effectuer des actions jamais prévues.
Imaginez un agent conçu pour répondre aux demandes du helpdesk IT interne. S’il dispose également d’un accès en écriture au système de ticketing, à l’annuaire des utilisateurs et au relay e-mail — parce que c’était pratique lors du développement — une entrée soigneusement construite pourrait lui ordonner de créer des comptes administrateurs, de modifier des permissions ou d’exfiltrer des données de tickets. L’agent n’est pas « hacké » au sens traditionnel ; il reçoit simplement une instruction qu’il n’a aucune raison de refuser.
C’est moins un problème de modèle qu’un problème de conception. La plupart des vulnérabilités d’abus d’outils proviennent d’agents sur-privilégiés.
Mesures d’atténuation pratiques :
- Appliquez le principe du moindre privilège par défaut au niveau des outils. Un agent qui lit des données a rarement besoin d’un accès en écriture ; un agent qui écrit ne devrait presque jamais avoir des permissions de suppression.
- Définissez des listes d’actions autorisées explicites dans la configuration système de votre agent, plutôt que de vous fier au jugement du modèle pour s’auto-restreindre.
- Journalisez chaque appel d’outil avec son contexte complet — l’entrée qui l’a déclenché, l’outil invoqué et la sortie retournée. Vous ne pouvez pas investiguer ce que vous ne pouvez pas tracer.
- Pour les outils à fort impact (écritures financières, gestion des utilisateurs, communications externes), exigez une étape de confirmation humaine avant l’exécution. Ce n’est pas de la bureaucratie ; c’est la différence entre un quasi-incident et un incident réel.
3. Exfiltration de données — le risque silencieux dans les agents RAG
Les agents ayant accès à des bases de connaissance internes, des bases de données ou des document stores introduisent un risque d’exfiltration de données différent d’une compromission de base de données. Il n’y a pas de point d’exploitation unique — l’agent lui-même devient le canal d’exfiltration.
Un attaquant qui peut influencer les entrées de l’agent (via injection, ingénierie sociale ou un compte utilisateur compromis) peut potentiellement le diriger pour récupérer et relayer des contenus sensibles. Comme l’agent est un système autorisé, la récupération n’apparaît pas anomale pour le data store lui-même.
Un risque secondaire d’exfiltration provient des pipelines de training et de logging. Si les journaux de conversation, les documents récupérés ou les sorties d’outils sont envoyés à des services externes à des fins de monitoring, de fine-tuning ou d’analytics sans classification appropriée des données, des contenus sensibles peuvent fuiter par un canal entièrement différent de celui que vous surveillez.
Mesures d’atténuation pratiques :
- Limitez les permissions de récupération par rôle : un agent au service des ventes ne devrait pas pouvoir interroger des documents RH ou financiers, même si le store sous-jacent les contient tous.
- Appliquez la classification des données au niveau du document ou de l’enregistrement, pas seulement au niveau du système. Étiquetez les contenus comme internes, confidentiels ou à accès restreint — et faites respecter ces étiquettes dans la couche de récupération de l’agent.
- Vérifiez ce qui sort de votre environnement. Tout journal ou donnée de conversation envoyé à un service tiers (fournisseur LLM, plateforme de monitoring) doit passer par la même revue de traitement des données que vous appliquez à n’importe quel fournisseur SaaS.
Une checklist de sécurité pratique pour les agents en production
Avant de valider un système agentique pour une utilisation en production, un responsable IT devrait pouvoir répondre oui à chacun de ces points :
- Chaque agent opère-t-il avec un accès aux outils selon le principe du moindre privilège — uniquement ce dont il a besoin pour sa tâche définie ?
- Les system prompts sont-ils explicites sur ce que l’agent est autorisé ou non à faire ?
- Tous les contenus lus par l’agent (documents, e-mails, pages web) sont-ils traités comme des entrées non fiables, avec validation des sorties appliquée ?
- Chaque appel d’outil est-il journalisé avec un contexte suffisant pour reconstruire ce qui s’est passé et pourquoi ?
- Des validations humaines sont-elles en place pour les actions irréversibles ou à fort impact ?
- Les données circulant dans les journaux d’agents et les pipelines de monitoring ont-elles été examinées pour détecter des contenus sensibles ?
- Existe-t-il un processus pour revoir et mettre à jour les permissions lorsque le périmètre de tâches de l’agent change ?
Aucun de ces points ne nécessite un nouveau produit de sécurité. La plupart requièrent des décisions de conception délibérées lors des phases d’architecture et de déploiement — ce qui est le bon moment pour les aborder.
Qui est le plus exposé
Les risques de sécurité augmentent avec les accès. Un agent avec un accès en lecture seule à une base FAQ unique présente un risque minimal. Un agent connecté à votre CRM, à votre système financier, à vos e-mails et à vos données clients — comme beaucoup d’agents en production — présente un risque matériel s’il est déployé sans les contrôles ci-dessus.
Les organisations les plus exposées sont généralement celles qui sont passées rapidement du prototype à la production, en traitant l’agent comme une application autonome plutôt que comme un acteur système privilégié. La fonctionnalité fonctionnait ; la posture de sécurité n’a pas été réexaminée. Cette lacune vaut la peine d’être comblée avant que le parc d’agents ne s’agrandisse.
Pour une vision plus complète de la manière dont la gouvernance, les tests et la sécurité s’articulent dans un programme d’agents déployés, consultez nos guides sur la gouvernance des agents IA pour les PME et le testing des agents IA avec des evals. Si vous évaluez si votre configuration actuelle introduit une exposition RGPD par le biais de la gestion des données des agents, agents IA et RGPD couvre spécifiquement ce sujet.
Comprendre pourquoi les systèmes agentiques sont architecturalement différents de la simple automatisation aide également à cadrer les exigences de sécurité — les workflows agentiques expliqués est un bon point de départ si ce contexte est utile.
L’approche d’Orange ITS en matière de sécurité des agents IA
Chez Orange ITS, la sécurité et la gouvernance sont intégrées dans l’architecture dès la première session de conception — elles ne sont pas ajoutées après la mise en production. Lorsque nous définissons le périmètre d’un projet d’agent avec un client, nous établissons les permissions des outils, les frontières d’accès aux données, les exigences de journalisation et les seuils d’approbation humaine avant d’écrire une seule ligne de code.
Cela fait partie d’une discipline d’ingénierie plus large que nous appliquons à l’ensemble du développement d’agents IA : l’objectif est des agents qui fonctionnent de manière fiable en production, pas des agents qui fonctionnent dans les démos. Pour nos clients suisses et européens, cela signifie également traiter le RGPD, la LPD révisée et les obligations sectorielles de l’AI Act comme des contraintes de premier ordre.
Si vous avez un agent en production — ou êtes sur le point d’en déployer un — et souhaitez une évaluation directe de votre posture de sécurité actuelle, réservez un appel de 30 minutes avec notre équipe. Nous passerons en revue votre architecture, identifierons les lacunes spécifiques et vous fournirons une liste priorisée de mesures sur lesquelles vous pouvez agir. Contactez-nous via notre page de contact.