Alexandre Nguyen
Pourquoi les agents IA changent la donne en sécurité
Quand une IA ne se contente plus de répondre et commence à agir, le niveau de risque change. Un agent IA peut lire un document, consulter un outil interne, déclencher une action ou manipuler des données. Cette autonomie apporte de l’efficacité, mais elle crée aussi une surface d’attaque plus large et plus mouvante, surtout lorsqu’il est branché aux systèmes métiers.
Les cadres de référence publiés par l’OWASP placent l’injection de prompt et la fuite de données parmi les vulnérabilités les plus critiques des applications LLM¹. Pour une entreprise, le sujet n’est donc pas théorique. Il touche à la confidentialité, à l’intégrité des actions et à la gouvernance des accès.
Injection de prompt, directe ou indirecte
Deux chemins d’attaque à surveiller
L’injection de prompt consiste à pousser un modèle à ignorer ses consignes initiales pour adopter celles de l’attaquant. La version directe est la plus intuitive: une instruction malveillante est insérée dans la requête. La version indirecte est plus sournoise. L’agent lit un contenu externe, puis traite ce texte comme s’il s’agissait d’une instruction légitime.
Dans un environnement d’entreprise, cela peut arriver via un email, une page web, un ticket support ou un document partagé. Si l’agent a accès à des outils internes, l’impact peut dépasser la simple réponse erronée. On peut alors voir surgir une divulgation d’informations sensibles, voire l’exécution d’actions non souhaitées.
Le risque est connu. Des cas publics ont déjà montré qu’un chatbot pouvait révéler des instructions système lorsqu’il était poussé dans ses retranchements. Ce type d’incident rappelle une chose simple: un agent ne doit jamais être traité comme une boîte noire de confiance.
Fuites de données et exfiltration
Ce que l’agent peut révéler ou déplacer
Les risques de fuite de données prennent plusieurs formes. Un modèle peut accidentellement exposer des éléments qu’il a vus pendant son entraînement. Un agent compromis peut aussi aller plus loin: lire un fichier sensible, copier une donnée confidentielle ou déclencher une transaction non autorisée.
Le sujet n’est pas seulement technique. Il est aussi économique. Une fuite liée à un agent IA peut toucher les secrets d’affaires, les données clients, les identifiants d’accès ou des workflows financiers. C’est précisément pour cette raison que des entreprises placent désormais la question de la sécurité des agents au même niveau que celle des accès humains.
Pour garder une lecture utile, nous pouvons rapprocher ce sujet des risques déjà bien connus en cybersécurité. Notre article sur le shadow IT montre déjà comment un usage non cadré d’outils peut ouvrir une brèche. Les agents IA ajoutent une couche d’automatisation à ce vieux problème.
Permissions, identité et excès d’autonomie
Le point de bascule se situe souvent dans les permissions. Si l’agent hérite des droits de l’utilisateur qu’il assiste, il peut accéder à trop de ressources. Si son identité est usurpée, l’attaquant récupère le même périmètre d’action. Dans les deux cas, le mouvement latéral devient plus simple et l’exfiltration plus crédible.
L’OWASP alerte aussi sur l’« excessive agency », quand un modèle prend des décisions trop larges sans validation humaine. Le bon réflexe consiste à réserver aux agents des droits strictement bornés, avec des garde-fous adaptés à chaque cas d’usage¹.
- Moindre privilège: n’accorder que les accès utiles à la tâche.
- Validation humaine: exiger un contrôle pour toute action sensible.
- Segmentation: isoler les agents des systèmes les plus critiques.
- Secrets protégés: éviter que l’agent puisse manipuler des identifiants en clair.
Journalisation: la preuve avant tout
Sans journalisation solide, on perd la trace de ce que l’agent a lu, décidé et exécuté. C’est un angle mort trop fréquent. Les recommandations de plusieurs acteurs convergent sur un point: il faut pouvoir auditer l’activité d’un agent comme on audite celle d’un compte privilégié.
Microsoft recommande une gouvernance centralisée des agents, alignée sur les pratiques existantes en identité, données et sécurité. La logique est saine: pas d’agent hors cadre, pas d’outillage parallèle, pas de zone grise sur les droits ou les logs.
Une journalisation complète aide aussi à repérer les signaux faibles: requête inhabituelle, accès anormal, chaîne d’actions trop longue, tentative de contourner une validation. Sans ces traces, l’incident se transforme vite en enquête à l’aveugle.
| Risque | Effet possible | Parade prioritaire |
|---|---|---|
| Injection de prompt | Instructions détournées, divulgation | Filtrage des entrées et sorties |
| Fuite de données | Exposition de secrets, PII, fichiers | Moindre privilège, contrôle des accès |
| Excessive agency | Action non validée | Validation humaine sur actions critiques |
| Usurpation d’identité | Mouvement latéral, exfiltration | Gestion stricte des identités et journaux |
Ce que recommandent l’ANSSI et l’OWASP
L’ANSSI a publié des recommandations sur la sécurité des systèmes d’IA générative, avec un angle très concret: analyse de risque dédiée, approche DevSecOps, Security by Design, contrôle des accès à privilèges et filtrage rigoureux des entrées comme des sorties². L’agence insiste aussi sur un point simple à appliquer: pas d’action critique automatisée sans validation humaine².
De son côté, l’OWASP fournit un référentiel utile pour classer les menaces les plus courantes sur les applications LLM. Pour une équipe produit ou sécurité, ce cadre sert de base de discussion entre développeurs, RSSI et métiers¹.
- Évaluer le cas d’usage avant toute mise en production.
- Limiter les droits de chaque agent au strict nécessaire.
- Contrôler les entrées et les sorties pour repérer les consignes malveillantes.
- Journaliser chaque action avec une traçabilité exploitable.
- Conserver une validation humaine pour les opérations sensibles.
Nous retrouvons ici la même logique que dans toute stratégie de sécurité sérieuse: défense en profondeur, surveillance continue et capacité à couper rapidement un comportement anormal. Les agents IA ne demandent pas moins de rigueur que les autres briques du SI. Ils en demandent souvent davantage.
Pour aller plus loin sur les usages métier et leurs limites, notre dossier sur l’automatisation par IA en gestion de projet offre un bon point d’appui. Le sujet n’est pas de freiner l’adoption. Le sujet est de la rendre gouvernable.
Sources
1. Cloudflare, page de synthèse sur les risques OWASP des applications LLM.
2. cyber.gouv.fr, recommandations de l’ANSSI pour un système d’IA générative.
