Cisco face aux risques de l’IA : la sécurité des modèles devient continue

L’intelligence artificielle ne change pas seulement les outils utilisés par les salariés. Elle change aussi la manière dont une entreprise doit penser sa sécurité. Lorsqu’un assistant accède à des documents internes, répond à des clients ou aide des développeurs à produire du code, il devient un point d’entrée supplémentaire dans le système d’information. Et ce point d’entrée évolue vite, au rythme des modèles, des données et des usages.

C’est le constat défendu par Cisco en janvier 2025. Le groupe, acteur historique des réseaux et de la cybersécurité, met en avant un enjeu central pour les organisations qui adoptent l’IA générative : contrôler un modèle une seule fois avant son déploiement ne suffit pas. La protection doit accompagner toute sa durée de vie, y compris lorsque l’entreprise utilise plusieurs modèles et plusieurs fournisseurs.

L’IA élargit la surface d’attaque des entreprises

Les entreprises emploient déjà l’IA pour automatiser des tâches, analyser de l’information, assister le support client ou accélérer le travail des équipes techniques. Mais intégrer un grand modèle de langage, aussi appelé LLM, ne revient pas à installer un logiciel traditionnel. Son comportement dépend à la fois de ses réglages, des instructions qui lui sont données, des données auxquelles il peut accéder et des requêtes que lui adressent les utilisateurs.

Cette particularité crée des risques à plusieurs niveaux. Un développeur peut mal configurer les droits d’accès d’un assistant. Un utilisateur peut lui soumettre une instruction visant à contourner ses garde-fous. Un fournisseur peut faire évoluer un modèle. Des données inadaptées ou manipulées peuvent aussi influencer son fonctionnement. La sécurité ne concerne donc pas uniquement le modèle lui-même : elle couvre l’application qui l’emploie, les données qu’elle consulte, les personnes qui l’utilisent et les services externes auxquels elle est reliée.

L’Index de préparation à l’IA 2024 de Cisco illustre l’ampleur du décalage entre l’adoption et la protection. D’après ce rapport, 29 % seulement des organisations interrogées se considèrent pleinement équipées pour détecter et empêcher les manipulations non autorisées de technologies liées à l’IA. Ce chiffre ne signifie pas que les autres entreprises sont sans défense. Il souligne toutefois qu’une large majorité ne s’estime pas encore au niveau requis face à des menaces spécifiques, dans un contexte d’automatisation croissante.

Pourquoi un modèle doit-il être validé en continu ?

Pour DJ Sampath, responsable des logiciels et plateformes d’IA chez Cisco, la validation d’un modèle n’est pas un événement unique. C’est un processus qui doit être répété. Cette idée tranche avec une approche classique consistant à tester une solution avant sa mise en production, puis à appliquer seulement des correctifs au fil du temps.

Dans le cas de l’IA, plusieurs changements peuvent modifier l’exposition au risque :

• un ajustement fin du modèle ou de ses paramètres ;
• l’ajout de nouvelles données, de nouveaux documents ou de nouvelles sources ;
• l’ouverture d’un nouvel accès à une base, une application ou un outil interne ;
• l’apparition d’une méthode d’attaque inédite ;
• le remplacement d’un modèle par un autre, y compris au sein d’une même application.

Un modèle peut paraître fiable dans un scénario de test, puis se comporter différemment lorsqu’il reçoit des requêtes inattendues dans des conditions réelles. D’où l’importance d’évaluer régulièrement les entrées reçues, les réponses produites et les autorisations accordées à l’application. La validation continue ne promet pas l’absence totale de faille. Elle vise plutôt à réduire le délai entre l’apparition d’un risque et son identification.

Les équipes de recherche sur les menaces de Cisco étudient les attaques visant l’IA et participent à des travaux de normalisation auprès d’organisations comme MITRE, OWASP et NIST. Cette dimension est importante : les risques propres aux LLM ne sont pas figés, et les définitions comme les bonnes pratiques se structurent encore. Partager des méthodes de description des attaques permet aux éditeurs, aux entreprises et aux spécialistes de la sécurité de parler des mêmes problèmes et de concevoir des protections comparables.

Injections, jailbreaks et données contaminées : les risques à connaître

Les mots employés dans le domaine de la sécurité de l’IA peuvent sembler techniques. Pourtant, ils renvoient à des situations concrètes pour une entreprise qui branche un assistant sur ses outils et ses informations.

L’injection de requêtes, souvent désignée par l’expression anglaise prompt injection, est particulièrement révélatrice du nouveau paradigme. Dans un logiciel classique, une commande malveillante exploite souvent une faille technique précise. Avec un LLM, l’attaque peut prendre la forme d’un texte qui cherche à persuader le modèle de délaisser ses instructions initiales. Si l’assistant traite des contenus externes, tels que des documents ou des messages, ce contenu peut lui-même contenir des instructions dissimulées.

Le jailbreak poursuit une logique voisine : obtenir du modèle qu’il s’affranchisse des limites posées par son concepteur ou par l’entreprise qui l’emploie. Quant à la contamination des données d’entraînement, elle rappelle que le risque ne se situe pas uniquement au moment où un salarié saisit une requête. Il peut aussi apparaître plus tôt, dans les données servant à bâtir, régler ou enrichir un système.

Ces menaces ne doivent pas conduire à renoncer aux usages de l’IA. Elles imposent en revanche de définir précisément ce que chaque assistant est autorisé à consulter, à faire et à transmettre. Un outil chargé de résumer des documents internes n’a pas nécessairement besoin d’accéder à toutes les données de l’entreprise. Le principe est simple : limiter les accès au strict nécessaire réduit les conséquences potentielles d’un comportement inattendu.

Des architectures plus complexes que le cloud traditionnel

Frank Dickson, vice-président groupe pour la sécurité et la confiance chez IDC, replace cette évolution dans une histoire plus large de l’informatique d’entreprise. Le passage des systèmes hébergés sur site au cloud a déjà bouleversé les pratiques de cybersécurité. L’adoption des architectures en microservices a ensuite ajouté de nouveaux composants, de nouvelles communications et de nouveaux points de contrôle.

L’arrivée des LLM accroît encore cette complexité. Une application d’IA peut reposer sur un fournisseur de cloud comme AWS, Azure ou GCP, sur un ou plusieurs modèles, sur des bases de données internes et sur des interfaces destinées à des utilisateurs variés. Les développeurs, les utilisateurs finaux et les fournisseurs sont tous concernés par la gestion des vulnérabilités.

Une application cloud établie peut conserver durablement sa configuration et son environnement technique. Un environnement de modèles, à l’inverse, est susceptible d’être modifié plus fréquemment : changement de version, ajustement de paramètres, ajout d’outils connectés ou adoption d’un second modèle pour une tâche spécifique. Or chaque modèle possède ses propres capacités, limites et vecteurs de menace.

Cisco mise sur des contrôles adaptés au multi-modèle

C’est dans ce contexte que Cisco présente AI Defense, une solution pensée pour appliquer des contrôles de sécurité dans des environnements qui utilisent plusieurs modèles. L’enjeu du multi-modèle dépasse la seule question technique. Une entreprise peut choisir un modèle pour la rédaction, un autre pour l’analyse, et un troisième intégré à une application fournie par un partenaire. Elle doit alors conserver une vision cohérente des règles et des risques, sans supposer que les garanties d’un modèle s’appliquent automatiquement aux autres.

Selon Cisco, AI Defense s’optimise automatiquement à partir des menaces identifiées par ses systèmes internes. L’objectif affiché est d’apporter des contrôles qui tiennent compte des spécificités des modèles utilisés. Cette approche répond à une difficulté concrète : une politique de sécurité trop générale peut manquer les particularités d’un modèle, tandis qu’une gestion entièrement manuelle devient difficile à maintenir lorsque les usages se multiplient.

Le point essentiel est que la sécurité de l’IA ne doit pas être isolée du reste de la cybersécurité. Elle doit s’articuler avec les règles d’identité, de gestion des accès, de protection des données et de supervision des applications. En pratique, un assistant sûr dépend autant de ce qu’il est capable de générer que de ce qu’il a le droit de lire, d’appeler ou de déclencher.

L’adoption rapide ne doit pas banaliser les risques

Pour Jeetu Patel, vice-président exécutif et responsable produit chez Cisco, les grandes avancées technologiques commencent souvent par sembler révolutionnaires avant de devenir rapidement ordinaires. Il cite notamment l’expérience des véhicules autonomes Waymo pour illustrer cette normalisation progressive : ce qui surprend initialement peut devenir familier, au point de faire oublier les implications techniques et organisationnelles qui l’accompagnent.

L’IA générative suit ce chemin. Des outils comme ChatGPT ont rendu l’interaction avec un modèle particulièrement simple : il suffit de formuler une demande en langage courant. Cette facilité peut encourager une adoption très rapide dans les équipes, parfois avant que les règles de sécurité, les processus d’autorisation et les responsabilités soient clairement établis.

La réponse ne consiste pas à transformer chaque usage en parcours administratif. Elle consiste à intégrer les exigences de protection dès la conception des projets. Une entreprise peut notamment distinguer les usages sans données sensibles de ceux qui nécessitent un accès à des informations internes, définir qui peut connecter un modèle à quels outils, et prévoir des contrôles adaptés avant que l’usage ne se généralise.

Ce qu’il faut surveiller

En janvier 2025, la question n’est plus de savoir si l’IA atteindra les entreprises, mais dans quelles conditions elles l’intégreront. La rapidité des évolutions impose de surveiller plusieurs points : l’apparition de nouveaux modes d’attaque, les changements de versions des modèles, la circulation des données entre les applications et les modèles, ainsi que la capacité des équipes à détecter une utilisation anormale.

Le chiffre de 29 % mis en avant par Cisco rappelle surtout qu’une préparation complète reste rare parmi les organisations sondées. À mesure que les assistants deviennent des interfaces ordinaires de travail, la vigilance devra elle aussi devenir ordinaire. La sécurité ne pourra pas se limiter à une vérification au moment du lancement d’un projet : elle devra suivre les modèles, les usages et les menaces tout au long de leur évolution.