La sécurité de l'IA n'est pas défaillante, nous défendons simplement les mauvaises choses.

Le secteur de la cybersécurité a une fâcheuse tendance : dès qu’une nouvelle technologie émerge, on se met immédiatement à la protéger. On l’a fait avec le cloud, avec les conteneurs, et maintenant avec l’IA, sauf que cette fois-ci, les barrières que nous érigeons sont complètement mal placées.

Participez aujourd'hui à n'importe quel audit de sécurité d'entreprise, et vous entendrez les mêmes priorités : sécuriser les modèles d'IA, protection des données d'entraînementL’IA doit valider les résultats et déployer des copilotes dotés d’IA. Les fournisseurs se précipitent pour vendre des outils de « sécurité IA » axés exclusivement sur les contrôles au niveau du modèle, tels que les garde-fous, les protections contre les injections de code et les plateformes de surveillance des modèles.

Mais les attaquants utilisent vos intégrations d'IA comme des autoroutes vers tout le reste.

La véritable surface d'attaque que personne ne surveille

Un phénomène récurrent dans les environnements d'entreprise est préoccupant : les équipes de sécurité investissent massivement dans la sécurisation de leurs environnements de développement d'IA (contrôles d'accès aux modèles, cadres de gouvernance des données, outils de sécurité MLOps), ce qui leur donne une fausse impression de sécurité quant à la protection de leur IA.

Mais lorsqu'on cartographie la surface d'attaque réelle, on constate que les chatbots IA possèdent souvent des jetons OAuth pour des dizaines de plateformes SaaS, des clés API avec des autorisations cloud excessives et des relations de confiance d'identité qui peuvent créer des failles directes, d'une simple injection de code malveillant à l'infrastructure de production. Les modèles eux-mêmes sont peut-être sécurisés, mais les écosystèmes dans lesquels ils évoluent sont souvent très vulnérables, et il ne s'agit pas d'un cas isolé.

Les entreprises utilisent aujourd'hui en moyenne plus de 130 applications SaaS, intégrant l'IA à travers leurs fournisseurs d'identité, leur infrastructure cloud, leurs bases de données et leurs systèmes critiques. Chaque intégration représente une faille de sécurité potentielle, et chaque connexion API une limite de confiance que les attaquants testent activement.

Le problème n'est pas que nos outils de sécurité IA soient défaillants. C'est que nous sécurisons des composants individuels alors que les attaquants exploitent les liens entre eux.

Pourquoi la sécurité centrée sur les modèles passe à côté de l'essentiel

L'approche actuelle de la sécurité de l'IA repose sur une incompréhension fondamentale du fonctionnement des attaques modernes. Nous considérons l'IA comme une ressource isolée nécessitant une protection, à l'instar d'une base de données ou d'une application web. Or, en production, l'IA n'est pas un système isolé. Elle s'inscrit dans un réseau complexe d'identités, d'autorisations, d'API et de flux de données.

Prenons l'exemple d'un déploiement d'IA en entreprise classique. Un agent IA accède à votre espace de travail Google. Il est connecté à Salesforce via des API et intégré à Slack pour les notifications. Il extrait des données des compartiments AWS S3 et s'authentifie via Okta ou Azure AD. Enfin, il déclenche des workflows dans ServiceNow.

La sécurité traditionnelle de l'IA se concentre sur le modèle lui-même : son niveau de sécurité, la validation rapide et la sécurité des résultats. Mais les attaquants s'intéressent aux intégrations : ce qu'ils peuvent atteindre via des comptes de service compromis, où ils peuvent s'infiltrer grâce à des manipulations d'API, et quelles limites de confiance ils peuvent franchir grâce à des intégrations exploitées.

L'attaque ne commence ni ne se termine avec le modèle d'IA. Ce dernier n'est que le point d'entrée.

Les vecteurs d'attaque ne tiennent pas compte des limites du produit.

C’est là que la plupart des organisations rencontrent des difficultés. Elles ont déployé des outils de sécurité qui offrent chacun une visibilité sur un seul domaine. Un outil surveille les autorisations cloud. Un autre suit les configurations SaaS. Un troisième gère la gouvernance des identités. Un quatrième prend en charge la gestion des vulnérabilités.

Chaque outil vous montre sa pièce du puzzle. Aucun ne vous montre comment les pièces s'assemblent.

Selon GartnerLes organisations utilisent aujourd'hui en moyenne plus de 45 outils de sécurité. Pourtant, malgré cet investissement massif, les attaquants parviennent à exploiter les erreurs de configuration dans ces différents domaines, car aucun outil ne permet de visualiser l'intégralité du parcours d'attaque.

Un attaquant n'a pas besoin de trouver une vulnérabilité critique dans votre modèle d'IA. Il lui suffit de trouver une chaîne d'attaques. Il peut s'agir d'un rôle IAM mal configuré, associé à votre service d'IA, qui dispose d'autorisations d'accès à un compartiment S3 contenant des identifiants pour une application SaaS ayant un accès administrateur à votre environnement de production.

Chaque erreur de configuration prise individuellement peut être classée comme « moyenne » ou « faible » par vos outils de sécurité. Mais cumulées ? Cela représente une vulnérabilité critique. Et elle est totalement invisible si vous examinez chaque domaine de sécurité séparément.

L'impératif de gestion de l'exposition

C’est pourquoi le débat doit passer de la « sécurité de l’IA » à la gestion continue de l’exposition aux menaces dans les environnements intégrant l’IA.

Il ne suffit pas de se demander si nos modèles d'IA sont sécurisés. Les équipes de sécurité doivent comprendre ce qu'un attaquant peut réellement atteindre s'il compromet un compte de service d'IA. Elles doivent avoir une visibilité sur la manière dont les erreurs de configuration au sein des systèmes cloud, SaaS et d'identité peuvent s'enchaîner. Elles doivent savoir comment les intégrations d'IA modifient leur surface d'attaque en temps réel. Et elles doivent hiérarchiser les risques en fonction de leur vulnérabilité réelle, et non pas seulement de leur niveau de gravité.

La plupart des programmes de sécurité continuent de prioriser les risques de manière isolée, en utilisant des scores CVSS et des listes de contrôle de conformité qui ignorent complètement si une vulnérabilité est réellement exploitable dans votre environnement spécifique.

Cet écart est encore plus marqué avec les systèmes d'IA, car ils évoluent constamment. De nouvelles intégrations sont ajoutées chaque semaine. Les autorisations évoluent. Les connexions API changent. Votre surface d'attaque du mois dernier n'est plus la même aujourd'hui, mais votre évaluation de sécurité, elle, l'est probablement toujours.

À quoi ressemble réellement une sécurité prenant en compte les chemins d'attaque ?

Sécuriser l'IA en production exige une approche fondamentalement différente, qui se résume à quatre changements de mentalité clés.

Tout d'abord, il vous faut une visibilité unifiée sur l'ensemble des domaines de sécurité. Cessez d'exiger de chaque outil de sécurité qu'il fonctionne en vase clos. Vos outils de sécurité cloud, de gestion des identités, de gestion SaaS et d'analyse des vulnérabilités détiennent tous des pièces du puzzle du parcours d'attaque. Ils doivent partager des données en temps réel afin que vous puissiez observer comment les erreurs de configuration s'enchaînent.

Deuxièmement, privilégiez la simulation continue des parcours d'attaque. N'attendez pas les tests d'intrusion ou les exercices d'équipe rouge pour découvrir les failles exploitables. Testez en permanence la façon dont un attaquant pourrait se déplacer dans votre environnement, en vous concentrant sur l'exploitabilité réelle plutôt que sur des scores de gravité théoriques.

Troisièmement, hiérarchisez les priorités en fonction du contexte. Un compartiment S3 mal configuré n'est pas critique simplement parce qu'il est public. Il l'est s'il est public, contient des identifiants disposant de privilèges d'accès et est accessible depuis une ressource exposée sur Internet. Le contexte prime sur toute note individuelle.

Quatrièmement, privilégiez la remédiation préventive. Lorsqu'une alerte est traitée par votre équipe SOC, un temps précieux est déjà perdu. Une défense moderne exige de pouvoir neutraliser les failles exploitables avant qu'elles ne soient utilisées à des fins malveillantes, et non après un incident.

L'avertissement que nous ne pouvons ignorer

À mesure que l'IA s'intègre à tous les niveaux de l'infrastructure d'entreprise, la surface d'attaque s'étend plus vite que les équipes de sécurité ne peuvent l'analyser manuellement. Nous ajoutons des intégrations d'IA dix fois plus vite que nous ne les sécurisons.

Si vous sécurisez l'IA de manière isolée, en protégeant le modèle sans tenir compte de l'écosystème dans lequel il évolue, vous êtes déjà en retard. Les attaquants ne raisonnent pas en termes d'outils, mais en termes de schémas d'attaque. Ils n'exploitent pas des vulnérabilités isolées ; ils enchaînent les erreurs de configuration dans l'ensemble de votre environnement.

Les entreprises qui réussiront à sécuriser l'IA ne seront pas celles qui possèdent le plus d'outils de sécurité dédiés. Ce seront celles qui comprendront que la sécurité de l'IA est indissociable de la gestion de l'exposition sur l'ensemble de leur surface d'attaque.

La sécurité des modèles est un prérequis. L'essentiel est de comprendre ce qu'un attaquant peut atteindre lorsqu'il compromet une intégration d'IA. Tant que les équipes de sécurité ne pourront pas répondre à cette question en continu, en temps réel et sur l'ensemble de leur environnement, elles ne sécurisent pas l'IA. Elles espèrent simplement que leurs mesures de sécurité sont bien placées.