The Decoder→ original

IBM : 92 % des entreprises victimes d'incidents liés à l'IA n'avaient aucun contrôle d'accès de base

IBM a analysé des entreprises victimes de piratages liés à l'IA et relève une faille commune : 92 % d'entre elles ne limitaient pas qui avait accès à leurs systèmes d'IA, ni comment. Le modèle lui-même est rarement à l'origine de l'incident : les attaques passent par des droits excessifs accordés aux utilisateurs et aux comptes de service. La conclusion d'IBM : inutile de pirater l'IA quand on peut simplement y entrer sans aucune restriction.

Traité par IA depuis The Decoder ; édité par Hamidun News
IBM : 92 % des entreprises victimes d'incidents liés à l'IA n'avaient aucun contrôle d'accès de base
Source : The Decoder. Collage: Hamidun News.
◐ Écouter l'article

IBM a étudié des incidents de sécurité touchant des systèmes d'IA en entreprise et met en évidence une constante qui change les priorités de la protection de l'IA : 92 % des entreprises ayant subi un tel incident n'avaient pas de contrôle d'accès de base sur leurs outils d'IA. Dans la plupart des cas recensés, le modèle lui-même (son architecture, ses poids ou son algorithme) n'était pas la cause première du problème.

Où se situe réellement la vulnérabilité

Le chiffre clé de l'étude d'IBM : 92 % des entreprises touchées par des incidents liés à l'IA ne limitaient pas qui pouvait accéder à leurs systèmes d'IA, ni avec quels droits. Contrôle d'accès, audit des droits et surveillance des appels au modèle faisaient défaut, alors que ce sont précisément ces mesures qui devraient constituer la première barrière de protection.

Par ailleurs, les attaquants ne s'en prenaient généralement pas directement au modèle. Ils exploitaient des vecteurs plus simples : compromission d'un compte disposant de droits excessifs, accès à l'interface de l'IA, puis le système lui-même leur fournissait les informations recherchées.

  • 92 % des entreprises victimes d'incidents liés à l'IA n'avaient pas de contrôle d'accès suffisant sur leurs systèmes d'IA
  • Le modèle d'IA était rarement la cause première de la faille de sécurité
  • Principaux vecteurs d'attaque : droits excessifs des utilisateurs et des comptes de service
  • L'absence de surveillance des requêtes anormales adressées au système d'IA a aggravé l'ampleur des incidents

Le contrôle d'accès à un système d'IA ne se résume pas à un identifiant et un mot de passe. En entreprise, il suppose des autorisations granulaires : quelles données et quelles bases de connaissances le modèle peut consulter, et quels employés et prestataires peuvent lui envoyer des requêtes, en quelle quantité.

Pourquoi les systèmes d'IA sont devenus une cible attractive

Les outils d'IA d'entreprise obtiennent de plus en plus souvent un large accès à des données métier critiques : bases clients, documents financiers, correspondance interne et documents stratégiques. C'est ce qui en fait une cible de valeur, non pas à cause de failles du modèle lui-même, mais en raison des données auxquelles on peut accéder par son intermédiaire à l'aide de simples requêtes.

Une installation d'IA d'entreprise typique connecte le modèle aux documents, aux données du CRM, aux messageries de travail et aux bases de connaissances. Si rien ne limite ce que le système peut « voir » et restituer en réponse aux requêtes, l'ampleur d'une fuite potentielle dépend uniquement de l'étendue de l'accès aux données dont disposait le compte compromis.

«

Le modèle lui-même est rarement le problème », ressort de l'étude d'IBM, qui désigne des facteurs organisationnels et de configuration comme la cause principale de la majorité des incidents d'IA recensés.

Pourquoi les mesures de base ne sont toujours pas déployées

Le déploiement accéléré de l'IA en entreprise a créé une situation où les systèmes d'IA sont connectés aux données de production avant que le périmètre de sécurité nécessaire ne soit mis en place autour d'eux. Ces outils sont souvent perçus comme « un SaaS de plus », et non comme une infrastructure ayant accès à des ressources d'entreprise critiques.

Le principe du moindre privilège (least privilege), l'audit régulier des accès, la surveillance des requêtes anormales et la séparation des environnements de test et de production ne sont pas des concepts nouveaux. La sécurité informatique les applique depuis des décennies aux CRM, aux ERP et aux bases de données. Selon IBM, cette étape est systématiquement sautée lors du déploiement des systèmes d'IA.

Ce que cela signifie

L'étude d'IBM déplace le débat sur la sécurité de l'IA des risques algorithmiques vers la maturité organisationnelle. Les discussions publiques sur les menaces liées à l'IA se concentrent souvent sur les vulnérabilités des modèles eux-mêmes : prompt injection, hallucinations, comportement imprévisible. Mais la réalité des incidents est différente, selon IBM : neuf entreprises sur dix confrontées à une faille liée à l'IA auraient pu l'éviter grâce à des mesures que les spécialistes de la sécurité de l'information appliquent depuis des décennies.

Pour les CISO et les équipes IT, c'est l'enseignement essentiel : avant de passer à l'échelle son infrastructure d'IA, il faut s'assurer que les mêmes standards de contrôle d'accès que pour tout autre outil d'entreprise critique s'appliquent bien autour d'elle.

ZK
Hamidun News
Actualités IA sans bruit. Sélection éditoriale quotidienne de plus de 50 sources. Produit de Zhemal Khamidun, Head of AI chez Alpina Digital.
✦ Enterprise AI & Advisory

Executive AI Consulting, Custom Agents & Team Workshops

Work directly with Zhemal Khamidun at hamidun.com — enterprise AI architecture, production RAG & multi-agent systems, and executive training.

Book AI Consultation →Explore NomadNet AI
Qu'en pensez-vous ?
Chargement des commentaires…