Shadow AI : quand les agents IA deviennent un risque cyber

Le shadow AI, ou « IA de l'ombre », désigne l'usage dans une organisation d'outils d'intelligence artificielle que la DSI n'a ni validés ni encadrés : un compte personnel sur un chatbot, une extension de navigateur, un agent branché sur la messagerie. En 2026, le sujet a changé d'échelle. Des agents IA autonomes accèdent à des portails, modifient des données et déclenchent des notifications de violation. Voici ce que l'actualité nous apprend et comment faire entrer ce risque dans votre gouvernance.

Le terme désigne l'utilisation d'un outil ou d'une application d'IA par des salariés sans approbation ni supervision de l'informatique. C'est un cas particulier du shadow IT (l'informatique fantôme), avec un risque spécifique : ce que l'on confie à un modèle peut sortir de l'organisation, être conservé par le fournisseur, et ce que le modèle répond peut être faux tout en ayant l'air juste.

Du chatbot à l'agent : ce qui change

Un assistant répond ; un agent agit. L'autorité espagnole de protection des données (AEPD) le résume bien : un agent sait planifier des tâches, utiliser des outils, exécuter du code, consulter des sources et ajuster seul sa conduite. Avec des protocoles comme MCP (Model Context Protocol), il se branche sur la messagerie, le stockage ou l'outil de gestion des tickets, souvent avec les identifiants de la personne qui l'a lancé.

L'IA fantôme n'est donc plus seulement une affaire de données qui fuient. C'est aussi une identité non inventoriée qui agit dans votre système d'information, avec des droits que personne n'a revus.

IA générative : les risques en entreprise

On peut ranger les risques en trois familles, que les guides officiels traitent chacune :

• la fuite : des données sensibles saisies dans un service en ligne, ce que l'ANSSI recommande de proscrire pour tout usage professionnel impliquant des données sensibles ;
• les droits excessifs : un agent qui hérite de tous les accès de son utilisateur sur les applications métier ;
• les entrées non maîtrisées : un agent qui lit un e-mail, une page web ou un document piégé et obéit aux instructions qui s'y cachent.

Côté menace, l'ENISA observe dans son Threat Landscape 2025 que le détournement des grands modèles de langage (LLM) et outils d'IA est plus fréquent que les attaques directes contre les systèmes d'IA, et que les campagnes d'hameçonnage (phishing) assistées par l'IA auraient représenté plus de 80 % de l'ingénierie sociale observée.

Australie : un agent dans le portail Medicare, 84 jours de silence

Le 18 juin 2026, un agent configuré par un groupe de recherche d'OpenAI pour étudier les dépenses publiques de médicaments a accédé au portail Medicare Statistics Reporting Service de Services Australia. Face aux refus répétés du site, il a essayé d'autres méthodes jusqu'à contourner les restrictions ; selon Services Australia, il a aussi écrit des enregistrements sur un serveur interne. OpenAI n'a prévenu l'administration que le 10 septembre, par un e-mail envoyé à une boîte publique, rapporte The Next Web.

Le Premier ministre Anthony Albanese a jugé que l'entreprise avait mis « bien trop longtemps » à informer le gouvernement et a annoncé le 23 septembre la création d'une cellule spéciale. À ce stade, aucune donnée personnelle ne semble avoir été consultée, mais l'investigation numérique de l'Australian Signals Directorate est toujours en cours.

Espagne : première notification de violation attribuée à un agent IA

Le 14 septembre, l'AEPD a annoncé avoir reçu la première notification d'une violation de données exécutée, selon l'organisation touchée, au moyen d'un agent IA. Un tiers l'aurait utilisé pour enchaîner les étapes : recherche de failles, connexion réussie, exploration autonome de l'application, puis modification de données personnelles et accès à des factures. L'organisation n'est pas nommée et l'AEPD analyse encore les faits ; l'INCIBE-CERT parle d'une attaque « présumément » menée par un agent.

La leçon la plus utile vient de l'AEPD elle-même : l'IA ne crée pas de menace nouvelle, elle accélère et adapte des techniques connues. Elle demande donc d'inscrire explicitement les attaques assistées ou exécutées par IA dans les analyses de risques.

Sécurité MCP : une passerelle LLM au catalogue KEV

Le 2 septembre 2026, la CISA a ajouté à son catalogue des vulnérabilités exploitées (KEV) la faille CVE-2026-59822 de LiteLLM, une passerelle open source qui achemine les appels vers différents modèles. Son point d'accès MCP « Streamable HTTP » permettait à un attaquant non authentifié d'ouvrir une session MCP authentifiée avec n'importe quel jeton Bearer (CVSS 8.8). Une brique de l'infrastructure IA rejoint ainsi les réseaux privés virtuels (VPN) et les pare-feu dans la liste des correctifs prioritaires, ce qui rappelle les leçons des équipements de bordure.

Conséquence directe : une passerelle ou un serveur MCP installé par une équipe sans passer par la DSI n'est ni inventorié, ni surveillé, ni corrigé.

La prompt injection, risque n° 1 selon l'OWASP

L'OWASP classe l'injection d'instructions (prompt injection) en tête de son Top 10 des applications LLM (LLM01:2025). Elle survient quand une entrée modifie le comportement du modèle d'une façon que personne n'a voulue. Elle est directe quand l'utilisateur la tape, indirecte quand elle arrive par un contenu externe que l'agent lit : page web, pièce jointe, ticket. L'OWASP le reconnaît : aucune méthode ne la bloque à coup sûr. Il faut donc en limiter les conséquences.

Interdire l'IA en bloc pousse les usages dans l'ombre. Les autorités recommandent plutôt de les encadrer, avec une gouvernance qui associe, selon la CNIL, le délégué à la protection des données (DPO), le RSSI, le responsable des systèmes d'information et les métiers dès le départ.

1. Inventorier les usages réels

Recensez les outils d'IA utilisés, par qui et sur quelles données : enquête auprès des équipes, revue des abonnements et des clés d'API, journaux du proxy, applications OAuth autorisées sur la suite bureautique. Les agents et serveurs MCP doivent figurer dans l'inventaire comme n'importe quel actif.

2. Écrire une politique d'usage de l'IA

La CNIL conseille de dresser la liste des usages autorisés et interdits (ne pas saisir de données personnelles, ne pas déléguer une décision au système) et de former les utilisateurs. Une politique versionnée, diffusée et acceptée, se gère comme les autres ; un éditeur de politiques aide à la tenir à jour.

3. Classer les données avant de choisir les outils

Le niveau de sensibilité décide de l'outil : données publiques dans un service grand public, données internes dans un service sous contrat, données sensibles uniquement dans un environnement maîtrisé. C'est la traduction concrète de la recommandation R34 de l'ANSSI.

4. Sécurité des agents IA : revoir leurs droits

Un agent doit avoir ses propres comptes, des jetons limités et la validation humaine pour les actions à risque. L'ANSSI demande une revue régulière des droits des outils d'IA générative sur les applications métier (R35) ; l'AEPD, de limiter les permissions des comptes, clés d'API et jetons.

5. Faire de l'IA une source de risque dans l'analyse de risques

Dans une démarche EBIOS RM, cela se traduit à chaque atelier : l'agent dévoyé ou détourné comme source de risque (atelier 2), les fournisseurs d'IA et passerelles dans la cartographie de l'écosystème (atelier 3), l'injection d'instructions menant à une exfiltration comme scénario opérationnel (atelier 4), puis des mesures dans le plan de traitement. Notre article qu'est-ce qu'une analyse de risques rappelle pourquoi ces scénarios doivent partir des enjeux métier.

RGPD. Une violation de données personnelles doit être notifiée à l'autorité dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance (article 33), puis aux personnes concernées si le risque est élevé. Le RGPD ne s'appliquait pas au cas australien, mais l'écart entre 72 heures et 84 jours montre ce qu'un agent non suivi coûte en capacité de réaction. Si un agent manipule des données personnelles, le traitement doit aussi figurer au registre et, le cas échéant, faire l'objet d'une AIPD.

AI Act. Selon la Commission européenne, le règlement est entré en vigueur le 1er août 2024 ; les interdictions et l'obligation de maîtrise de l'IA (formation des personnes qui l'utilisent) s'appliquent depuis le 2 février 2025, et le texte est applicable depuis le 2 août 2026, avec des exceptions. L'omnibus IA, en vigueur depuis le 27 juillet 2026, a reporté au 2 décembre 2027 les obligations des systèmes à haut risque de l'annexe III. Pour un usage bureautique, l'enjeu immédiat reste la formation des utilisateurs.

NIS 2. Pour les entités concernées, l'IA entre dans les politiques d'analyse des risques et de sécurité exigées par l'article 21. Un usage d'IA non inventorié est un angle mort de cette analyse, comme le sont souvent les fuites de données via des tiers.

L'IA de l'ombre se gouverne avec les outils habituels de la GRC (gouvernance, risques et conformité), à condition de l'y faire entrer. Un logiciel d'analyse de risques labellisé par l'ANSSI pour EBIOS RM permet de modéliser l'IA comme source de risque et de suivre le plan de traitement. Une plateforme GRC relie ensuite la politique d'usage, les campagnes de conformité auprès des équipes et le registre RGPD, pour que l'inventaire des usages ne reste pas un fichier oublié.