Détecter le Shadow AI : repérer l'usage d'IA non autorisée dans vos logs

Un ingénieur colle une stack trace — avec des identifiants clients et un nom d'hôte interne — dans ChatGPT pour déboguer plus vite. Un commercial dépose le pipeline du trimestre dans un prompt « résume-moi ça ». Quelqu'un installe une extension de navigateur qui envoie chaque page lue à un LLM « pour la productivité ». Rien de tout ça n'est passé par la DSI. Rien n'est journalisé là où l'équipe sécurité regarde. C'est le Shadow AI, et le temps que la plupart des PME pensent à une charte, les données sont déjà parties.

Tous les articles sur le Shadow AI finissent pareil : « rédigez une charte, formez vos équipes, sensibilisez ». Utile, mais ça suppose que vous voyez le problème. On ne gouverne pas ce qu'on ne détecte pas. Ce guide traite de la moitié détection — celle à laquelle vos logs peuvent réellement répondre.

Le Shadow AI, c'est quoi exactement

Le Shadow AI, c'est l'usage d'outils et de services d'IA au sein d'une organisation sans que la DSI et la sécurité en aient connaissance, l'approuvent ou le supervisent. C'est le descendant direct du Shadow IT (l'appli SaaS non validée, le Dropbox perso), avec deux différences qui l'aggravent :

• Il fuite les données par conception. Une appli Shadow IT stocke vos fichiers ; un prompt Shadow AI envoie vos données au modèle d'un tiers dès qu'on appuie sur Entrée. L'exfiltration est la fonctionnalité.
• Il se répand plus vite. Pas d'installation, pas de droit admin, pas d'achat. Un onglet de navigateur et un copier-coller suffisent — l'adoption va plus vite que n'importe quel cycle de gouvernance.

La catégorie est large, volontairement : assistants conversationnels publics (ChatGPT, Claude, Gemini, Copilot), fonctions IA ajoutées en silence à des outils que vous utilisez déjà, extensions de navigateur, bots « preneurs de notes IA » qui rejoignent vos réunions, assistants de code qui tirent — et poussent — vers des modèles externes.

Pourquoi c'est un vrai risque (pas juste une case de conformité)

• Fuite de données. Code source, données personnelles clients, contrats, identifiants collés dans un prompt peuvent être retenus, réutilisés pour l'entraînement, ou exposés. Pour une PME, ce sont les bijoux de famille, pas un fragment.
• Exposition conformité. Sous le RGPD, et pour les entités dans le périmètre NIS2, envoyer des données personnelles ou sensibles à un sous-traitant non évalué est un écart signalable. « On ne savait pas que les employés le faisaient » n'est pas une défense — c'est le constat.
• Une nouvelle surface d'attaque. Les outils Shadow AI sont eux-mêmes des cibles : injection de prompt, extensions empoisonnées, fausses applis « IA » qui sont en réalité des siphons de données. L'outil non autorisé n'est pas surveillé, donc une compromission y est invisible.
• Aucune piste d'audit. Quand un incident touche des données traitées par IA, vous ne pouvez pas répondre à « qu'est-ce qui est parti, vers qui, quand » — parce que rien ne l'a enregistré.

Le risque n'est pas que l'IA soit utilisée. C'est qu'elle le soit invisiblement. Ce qui transforme tout le problème en problème de détection.

Le cœur : comment détecter le Shadow AI

On détecte le Shadow AI comme n'importe quelle sortie non autorisée — vous avez déjà la télémétrie, il suffit de la pointer vers les bonnes destinations. Trois couches, de la moins chère à la plus riche.

1. La couche DNS / réseau (signal le plus fort, coût le plus faible)

Chaque service d'IA générative se joint via une poignée de noms d'hôtes connus. Si vous journalisez les requêtes DNS (et vous devriez — c'est le log de sécurité le plus rentable qu'une PME puisse garder), l'usage d'IA non autorisée apparaît comme des résolutions vers ces domaines depuis des postes qui n'ont rien à y faire.

Une liste de départ, non exhaustive, d'endpoints à surveiller :

api.openai.com          chatgpt.com            openai.com
api.anthropic.com       claude.ai
gemini.google.com       generativelanguage.googleapis.com
copilot.microsoft.com   api.githubcopilot.com
perplexity.ai           api.mistral.ai           huggingface.co

La même liste fonctionne au niveau pare-feu/NIDS (Suricata, Zeek) et dans votre proxy web ou filtre DNS (pfSense, Pi-hole, une passerelle web sécurisée). Le but n'est pas de bloquer d'abord — c'est de voir d'abord.

2. Une règle Sigma prête à l'emploi

Voici une détection portable à déposer dans n'importe quel SIEM compatible Sigma. Elle se déclenche sur les requêtes DNS vers les endpoints d'IA connus et exclut un sous-réseau en liste blanche — le seul endroit où votre pilote IA approuvé a le droit de tourner — pour faire remonter le shadow, pas le sanctionné.

title: Unsanctioned Generative AI Service Access
id: 6f1c2b8a-4a3d-4c21-9b0e-7c2f5a9d1e44
status: experimental
description: Detects DNS queries to public generative-AI SaaS endpoints from hosts
  that are not on the approved-tool allowlist. Surfaces Shadow AI egress before data leaves.
logsource:
  category: dns_query
detection:
  ai_endpoints:
    QueryName|contains:
      - 'api.openai.com'
      - 'chatgpt.com'
      - 'claude.ai'
      - 'api.anthropic.com'
      - 'gemini.google.com'
      - 'copilot.microsoft.com'
      - 'perplexity.ai'
      - 'api.mistral.ai'
  sanctioned_pilot:
    src_ip:
      - '10.20.10.0/24'   # <-- votre sous-réseau de pilote IA approuvé
  condition: ai_endpoints and not sanctioned_pilot
falsepositives:
  - Outil IA approuvé sur un poste pas encore ajouté à la liste blanche
  - Outillage de sécurité qui résout ces domaines pour sa propre détection
level: medium
tags:
  - attack.exfiltration
  - attack.t1567.002

Le motif se généralise : gardez la liste d'endpoints à jour, gardez la liste blanche honnête, et routez l'alerte vers celui qui possède la gouvernance IA. Une seule règle transforme un comportement invisible en événement triable.

3. Couches proxy et endpoint (pour le comment, pas juste le quoi)

Le DNS vous dit qu'un poste a joint un service d'IA. Pour savoir ce qui est parti, ajoutez :

• Logs proxy web / CASB — taille et fréquence des requêtes vers les endpoints d'IA (un POST de 40 Ko vers une API LLM, c'est un collage de quelque chose de substantiel, pas de la navigation).
• Télémétrie endpoint — extensions de navigateur installées, processus dialoguant avec des SDK d'IA, sessions à fort presse-papier sur un onglet IA connu.

Vous n'avez pas besoin des trois pour commencer. Le DNS seul vous fait passer d'aveugle à conscient en une après-midi.

De la détection à la gouvernance

La détection est ce qui rend la gouvernance réelle. Une fois la règle DNS active, vous pouvez :

1. Mesurer l'usage réel — quelles équipes, quels outils, à quelle fréquence. Vous serez surpris ; tout le monde l'est.
2. Sanctionner le bon, bloquer le reste — approuvez un outil évalué sur un sous-réseau contrôlé (votre liste blanche), et la règle ne se déclenche plus que sur le shadow.
3. Écrire la charte sur des preuves — un cadre appuyé par « voici ce qu'on a vu » porte là où une note générique n'a aucun effet.

C'est exactement là qu'un RSSI à temps partagé gagne sa place : transformer le signal de détection en liste d'outils approuvés, en règle de traitement des données et en consignes qui collent à la façon dont les gens travaillent vraiment — au lieu d'une interdiction que tout le monde contourne.

FAQ

Shadow AI vs Shadow IT — quelle différence ? Le Shadow IT, c'est tout outil ou service non autorisé. Le Shadow AI, c'est le sous-ensemble qui envoie vos données vers un modèle externe. La distinction compte parce que le risque n'est pas le stockage, c'est la transmission et la rétention par un tiers.

Comment détecter l'usage de ChatGPT au travail ? Journalisez les requêtes DNS et alertez sur les résolutions vers chatgpt.com / api.openai.com depuis des postes hors de votre liste blanche IA. La règle Sigma ci-dessus fait exactement cela et s'étend à tous les grands fournisseurs.

Bloquer ces domaines suffit-il ? Bloquer sans détecter est fragile : les utilisateurs passent à l'outil suivant, à un partage de connexion mobile, ou à un poste que vous n'avez pas listé. Détectez d'abord pour savoir quoi bloquer et pour voir quand quelqu'un contourne.

Est-ce que ça nous concerne sous NIS2 ? Si vous êtes dans le périmètre, envoyer des données personnelles ou sensibles à un sous-traitant non évalué est un écart de gouvernance que vous êtes censé maîtriser. Détecter le Shadow AI, c'est démontrer que vous en êtes réellement capable.

Le Shadow AI n'est pas une raison d'interdire l'IA — le gain de productivité est réel. C'est une raison de rendre l'invisible visible, puis de décider délibérément. ThreatClaw livre du contenu de détection exactement comme la règle ci-dessus dans son feed Sigma, et son feed LLM red-team couvre l'autre côté — les outils d'IA que vous approuvez. Commencez par activer la journalisation DNS et surveiller ces endpoints ; on ne gouverne pas ce qu'on ne voit pas.