Les assistants et agents d’intelligence artificielle s’ouvrent progressivement aux données internes et au web. Cette extension de leurs capacités introduit une forme de risque encore mal cadrée. Le prompt injection, longtemps cantonné à des démonstrations, apparaît désormais dans des usages réels, sans passer par les mécanismes classiques d’exploitation de vulnérabilités.
Des modèles qui lisent et agissent dans des environnements ouverts
Les usages d’IA en entreprise ne se limitent plus à la génération de contenu. Les modèles sont intégrés dans des outils métiers, accèdent à des documents, interrogent des bases internes et, dans certains cas, déclenchent des actions en passant par des API. Cette évolution les rapproche de systèmes opérationnels classiques, avec une différence notable puisque leur comportement dépend directement des contenus qu’ils traitent.
Un modèle ne fait pas de distinction native entre une instruction fiable et une donnée manipulée. Ce point est identifié de longue date, notamment par l’OWASP, qui classe le prompt injection parmi les principaux risques des applications basées sur les grands modèles de langage. La limite est structurelle car tout contenu ingéré par le modèle peut influencer sa réponse ou ses actions.
Une attaque sans faille technique identifiable
Le prompt injection repose sur un principe simple. Il s’agit d’introduire des instructions malveillantes dans un contenu que le modèle va traiter. Ce contenu peut prendre différentes formes : page web, document partagé, email, ou même extrait de base de connaissances. Le modèle l’interprète comme un élément légitime de son contexte et ajuste son comportement en conséquence.
Des travaux récents, notamment ceux de l’équipe Unit 42 de Palo Alto Networks, montrent que ces scénarios ne relèvent plus uniquement de la recherche. Des instructions cachées dans des pages web peuvent être interprétées par des agents IA qui parcourent ces contenus. Dans certains cas, cela suffit à modifier une réponse, orienter une décision ou déclencher une action non prévue.
Le point clé reste l’absence de vulnérabilité exploitable au sens classique. Aucun code n’est compromis et aucun système n’est pénétré. L’attaque s’appuie uniquement sur la capacité du modèle à suivre des instructions, même lorsqu’elles sont dissimulées dans des données.
Des impacts concrets dans les environnements d’entreprise
Les architectures de type RAG, largement utilisées pour connecter les IA aux données internes, illustrent bien ce risque. Le modèle va chercher de l’information dans des documents pour enrichir ses réponses. Si une source compromise est intégrée à ce corpus, elle peut influencer directement le comportement du système.
Plusieurs démonstrations montrent qu’un document peut inciter un modèle à divulguer des informations sensibles ou à effectuer des requêtes vers des services externes. Le problème ne tient pas uniquement à l’ouverture vers le web. Il concerne aussi la confiance accordée aux contenus internes, souvent moins contrôlés qu’on ne l’imagine.
La situation se complique encore lorsque les agents disposent de droits étendus. Accès aux fichiers, envoi d’emails, interaction avec des outils métiers… Chaque capacité supplémentaire élargit le champ des actions possibles. Alors, une instruction malveillante peut produire des effets en chaîne, sans qu’un mécanisme de sécurité ne s’interpose clairement.
Une visibilité limitée sur ce que fait réellement le modèle
La détection de ce type d’attaque pose un problème particulier. Dans de nombreux cas, l’utilisateur ne voit qu’une partie du contexte traité par le modèle. Les instructions injectées peuvent être intégrées dans des contenus analysés en arrière-plan, sans interaction directe. Cette opacité complique aussi l’analyse des incidents. Les outils de sécurité traditionnels ne sont pas conçus pour repérer ce type de manipulation, qui ne laisse pas de trace évidente. Le comportement du modèle peut sembler cohérent, alors qu’il résulte d’une influence externe difficile à identifier.
Adapter les pratiques plutôt que chercher un correctif unique
La réponse ne passe pas par un correctif simple. Il s’agit davantage de revoir les conditions d’intégration et d’usage des modèles. La gestion des droits devient centrale, de même que le cloisonnement des sources de données et la traçabilité des actions.
Certaines bonnes pratiques commencent à émerger, mais elles restent encore hétérogènes. Les équipes doivent composer avec des outils en évolution rapide, souvent déployés sous la pression des usages métiers. La sécurité se construit au fil des expérimentations, avec un niveau de maturité encore variable.
Le prompt injection ne remplace pas les vulnérabilités classiques. Il introduit une couche supplémentaire, plus diffuse, liée à la manière dont les modèles interprètent leur environnement. Cette dimension oblige à déplacer le regard, en s’intéressant moins au code qu’aux interactions entre systèmes, données et utilisateurs.
