Les systèmes d’IA d’entreprise peuvent être corrompus par des données empoisonnées par accident, par des adversaires ou par une mauvaise hygiène. La plupart des organisations n’ont aucune idée de l’ampleur de cette surface d’attaque ni si elles sont déjà exposées.
Alors que les entreprises se précipitent pour déployer des LLM internes, des copilotes d’IA et des agents autonomes, la plupart des conversations sur la sécurité se concentrent sur des menaces familières : injection rapide, jailbreaks, abus de modèles et exfiltration de données. Mais certains responsables de la sécurité affirment qu’un risque plus discret mérite bien plus d’attention : que se passe-t-il lorsque la compréhension de la réalité elle-même par le modèle est corrompue ?
Ce problème est largement décrit comme un empoisonnement des données de l’IA, bien que les experts utilisent un langage différent selon l’endroit où la manipulation a lieu. Parfois, il s’agit d’une modification malveillante des données d’entraînement afin qu’un modèle apprenne de fausses informations. Parfois, cela signifie empoisonner les pipelines de génération augmentée de récupération (RAG) ou d’autres couches contextuelles qui améliorent les sorties LLM, les bases de connaissances internes ou la mémoire des agents. Et parfois, le problème n’est pas du tout malveillant, mais résulte de données d’entreprise obsolètes, conflictuelles ou de mauvaise qualité.
Dans chaque version, la conséquence est la même : le système d’IA prend des décisions basées sur de mauvaises hypothèses, et les organisations font confiance à ces décisions car rien ne semble visiblement défectueux. Aucun fichier n’est crypté. Aucune alarme n’est déclenchée. Le modèle commence à produire des réponses plausibles mais erronées qui peuvent affecter les contrôles d’accès, les décisions d’approvisionnement, les approbations financières, le support client ou les opérations de sécurité.
Chris Cochran, RSSI sur le terrain et vice-président de la sécurité de l’IA au SANS Institute, utilise une analogie simple avec un buffet à volonté pour expliquer pourquoi cette menace est si difficile à identifier : « Vous avez des maux d’estomac, mais vous ne savez pas vraiment ce qui vous a rendu malade. Parce que vous avez mangé tellement de choses différentes, vous ne pouvez pas vraiment identifier exactement de quoi il s’agit. »
C’est ainsi, dit-il, que fonctionne l’empoisonnement par l’IA.
Les modèles absorbent d’énormes volumes d’informations provenant des systèmes internes, des sources Internet publiques, des pipelines de récupération et des interactions des agents. Si même une petite quantité de ces informations est manipulée – ou simplement erronée – le modèle peut produire des résultats nuisibles tout en semblant parfaitement normaux.
Le défi pour les RSSI est que l’empoisonnement ne ressemble souvent pas à une cyberattaque traditionnelle. Il semble que l’entreprise fonctionne normalement, sauf que la compréhension de la vérité par le système a changé. Les attaquants peuvent provoquer ce changement, mais de nombreux experts affirment que le problème le plus immédiat est que les organisations causent elles-mêmes une grande partie des dégâts.
La plupart des entreprises s’empoisonnent déjà
Avant de s’inquiéter d’attaques sophistiquées émanant d’États-nations ou de manipulations adverses très ciblées, les responsables informatiques devraient se confronter à une vérité plus immédiate : la plupart des organisations empoisonnent déjà leurs propres systèmes.
Rob T. Lee, directeur de l’IA et chef de la recherche au SANS Institute, affirme que le problème dominant des entreprises aujourd’hui n’est pas l’empoisonnement malveillant mais une mauvaise hygiène des données. Les organisations extraient des informations des systèmes RH, des anciens dossiers SharePoint, des archives de courrier électronique obsolètes, des manuels obsolètes, des versions préliminaires de documents et des bases de données internes conflictuelles, puis introduisent le tout dans des LLM et attendent des réponses fiables.
« Ils essaient d’utiliser des sources de données dans toute l’organisation qui se trouvent dans 13 emplacements différents », explique Lee. « Les données ne sont pas synchronisées ; vous n’avez pas de point de référence clair. »
Ce n’est pas un empoisonnement, dit-il. C’est de la pollution.
Gary McGraw, fondateur du Berryville Institute of Machine Learning (BIML), propose la distinction la plus claire entre les deux concepts.
« La différence entre la pollution et l’empoisonnement réside simplement dans l’intention », explique McGraw. « Lorsque vous empoisonnez un ensemble de données, vous le faites intentionnellement pour tromper l’apprentissage automatique. Mais parfois, dans l’ensemble de formation, il y a des choses qui ne vont pas, et ce ne sont que des déchets, c’est de la pollution. »
Pour de nombreux RSSI, il est bien plus urgent de s’attaquer à la pollution des données qu’à une hypothétique campagne d’empoisonnement.
« Il n’a jamais été question d’ordinateur », dit Williams. « Il a toujours été question de données. En fin de compte, il faut quand même avoir une bonne cyber-hygiène. »
Il faut étonnamment peu de poison pour corrompre
Les mauvaises données internes constituent le problème immédiat. Mais la chaîne d’approvisionnement externe pourrait être encore plus difficile à contrôler.
Des recherches menées par Anthropic, l’AI Security Institute du Royaume-Uni et l’Institut Alan Turing ont découvert qu’à peine 250 documents rédigés de manière malveillante peuvent empoisonner des LLM de toute taille.
Cela crée un énorme problème de chaîne d’approvisionnement, car les attaquants n’ont pas besoin de pirater le fournisseur LLM lui-même. Il se peut qu’ils n’aient besoin d’influencer ce que lit le modèle qu’avec un nombre relativement restreint de documents.
Cela pourrait signifier planter du contenu manipulé pendant une fenêtre de récupération Wikipédia connue, empoisonner les référentiels GitHub, introduire de la documentation frauduleuse dans des ensembles de données publics ou compromettre la couche de récupération d’un système RAG d’entreprise.
« Si nous savons que les modèles vont supprimer Wikipédia toutes les deux semaines, tout ce que nous avons à faire est d’être dans cette fenêtre », dit-il. « Nous pouvons insérer des données erronées, et nous savons alors qu’elles vont être ingérées dans le modèle. »
La même logique s’applique au sein de l’entreprise. Un robot du service client formé sur la documentation d’assistance manipulée pourrait divulguer discrètement des informations sensibles. Un assistant aux achats pourrait être poussé vers des instructions de paiement frauduleuses. Un agent de flux de travail financier pourrait être amené à faire confiance au mauvais chemin d’approbation parce que l’environnement d’information sous-jacent a été modifié.
Fussell affirme que les attaquants pourraient également cibler le pipeline interne utilisé pour former ou affiner le modèle d’une entreprise. « Si j’étais un attaquant et que j’étais au sein d’une de ces entreprises, je pourrais apporter de petites modifications à ce processus, et le modèle final les comporterait : il serait empoisonné », dit-il.
C’est ce qui rend l’empoisonnement à l’IA difficile à détecter. Cela ne ressemble pas toujours à une violation. Parfois, cela ressemble à un système prenant une décision plausible mais néfaste. La réponse semble raisonnable. Le flux de travail se termine avec succès. Les dégâts peuvent ne devenir visibles que bien plus tard.
Le vrai problème est peut-être le contexte, pas seulement les données
Plusieurs experts affirment que « l’empoisonnement des données » est un terme trop étroit car il implique que la menace n’existe que dans la formation des modèles fondamentaux. Au lieu de cela, la surface d’attaque est beaucoup plus large, affirment-ils.
Cochran de SANS préfère réfléchir à l’empoisonnement du contexte – l’idée selon laquelle des attaques peuvent se produire partout où un modèle interagit avec des informations. Cela inclut les systèmes de récupération, les pipelines RAG, les invites de temps d’inférence, la mémoire des agents et même les conversations entre agents.
« Partout où un modèle interagit avec des données, vous pouvez avoir un empoisonnement des données ou du contexte », dit-il.
Le contexte est important car de nombreuses entreprises ne construisent pas de modèles fondamentaux à partir de zéro. Ils superposent les agents d’IA aux systèmes de connaissances internes et permettent à ces agents de récupérer des informations, de formuler des recommandations et de prendre de plus en plus d’actions. Cela crée une surface d’attaque beaucoup plus large et plus pertinente sur le plan opérationnel que l’empoisonnement classique en formation.
Cochran souligne que les environnements agent à agent et les flux de travail autonomes sont particulièrement préoccupants. Une fois que les systèmes commencent à communiquer entre eux, les possibilités de manipulations subtiles se multiplient, car le modèle ne se contente pas de répondre à des questions : il participe aux décisions.
« Vous pouvez lui faire commencer à faire autre chose parce qu’il s’agit d’un système probabiliste », explique Cochran. « S’il lit quelque chose, il pourrait effectivement agir. »
Cela change fondamentalement la sécurité. La question n’est plus seulement de savoir si le code est sécurisé. Il s’agit de savoir si la compréhension de la réalité par le modèle est sûre. D’où viennent les informations ? À qui appartient-il ? Est-ce exact ? Est-ce empoisonné ?
McGraw du BIML affirme que cela conduit au risque le plus important à long terme : la pollution récursive.
« Vous créez du mal, vous le mangez, vous crachez du mauvais contenu, et c’est encore plus faux, et vous le mettez sur le net », dit-il. « Puis quelque chose arrive et mange ça, et c’est une boucle de rétroaction. »
Exemples dans la nature
Il existe encore très peu d’exemples publics confirmés d’attaques d’empoisonnement à grande échelle en entreprise. Lee de SANS affirme que la plupart des exemples restent des démonstrations de validation de principe plutôt que des compromis opérationnels connus, et Patrick Fussell d’IBM X-Force affirme qu’une grande partie des inquiétudes sont plus fortes dans les études universitaires que dans la réponse publique aux incidents.
Le problème est que la plupart des organisations peuvent détecter des problèmes liés à l’empoisonnement, mais pas la source de ces problèmes. «Si vous aviez une fuite dans votre maison et qu’elle sortait dans votre sous-sol et dans votre placard, votre salle de bain et votre chambre, vous supposez que vous avez 12 fuites», explique Meyers. « Mais il se pourrait qu’un seul tuyau soit à l’origine de toutes ces fuites. »
Ce que les responsables de la sécurité devraient faire
Il n’existe pas de solution miracle contre l’empoisonnement des données de l’IA, et la plupart des RSSI qui en recherchent un se posent la mauvaise question. Le défi immédiat est bien moins glamour : comprendre à quelles données le modèle fait confiance, qui contrôle ces données et si l’entreprise fournit déjà de mauvaises informations à ses propres systèmes.
« Ce que je constate continuellement à ce stade, c’est qu’ils ont du mal à choisir quelles sources de données saisir, lesquelles sont les plus fiables, et comment pouvons-nous les maintenir à jour ? » Dit Lee de SANS.
Cochran de SANS suggère que les RSSI doivent également cesser de penser uniquement au modèle fondamental et commencer à cartographier chaque endroit où l’IA obtient du contexte. « Partout où un modèle interagit avec des données, vous pouvez avoir un empoisonnement des données ou du contexte », dit-il.
Fussell d’IBM X-Force soutient que les RSSI devraient commencer à traiter l’empoisonnement de l’IA comme un problème de chaîne d’approvisionnement ainsi que comme un problème de modèle. « Il s’agit d’une ressource non fiable et nous devons nous assurer que notre infrastructure de sécurité globale est prête à y faire face en cas de violation », dit-il.
McGraw du BIML ajoute que les RSSI devraient se concentrer sur la gouvernance, car jusqu’à ce que quelqu’un puisse répondre « Qui résout ce problème ? Qui est responsable de cela ? L’empoisonnement de l’IA reste autant un échec de gouvernance qu’un échec de sécurité. »
