Shadow AI, détecter les assistants IA publics non déclarés

Le shadow AI désigne l’usage d’assistants d’IA (intelligence artificielle) générative publics, comme ChatGPT, Gemini, Claude ou Copilot, sur des comptes personnels et hors de tout contrat de l’organisation. Le problème de sécurité n’est pas l’outil, c’est l’absence de visibilité : des documents internes partent vers un tiers sans identité d’entreprise, sans journal exploitable et sans possibilité de suppression. La position défendue ici : mesurer d’abord, fournir une voie autorisée ensuite, bloquer seulement ce qui reste.

→ Lire l’explication complète de la marmotte

Pourquoi l’interdiction aveugle du shadow AI échoue

Bloquer une liste de domaines d’assistants sur le proxy donne un tableau de bord rassurant et un usage réel inchangé. Le salarié bascule sur son téléphone en 5G, hors de tout contrôle réseau, et colle le même tableau client dans la même fenêtre, cette fois sans aucune trace. Le blocage seul transforme un flux observable en flux invisible : c’est une perte nette de détection.

Le compromis central tient en une phrase : chaque blocage sans alternative achète de la conformité apparente et paie en visibilité. La recommandation qui en découle est tranchée : pas de blocage généralisé tant qu’une offre sous contrat (espace entreprise d’un assistant, ou accès par API, Application Programming Interface, derrière une passerelle interne) n’est pas disponible. Une fois cette offre en place, bloquer les variantes grand public devient défendable, parce qu’il existe une voie légitime vers laquelle rediriger.

La condition de validité de cette position : l’offre autorisée doit être réellement utilisable. Un assistant d’entreprise bridé au point d’être inutile recrée le shadow AI en une semaine, avec en prime la conviction que la direction ne comprend rien. Vingt ans de sécurité apprennent que le contournement le plus efficace est toujours celui qu’on a rendu nécessaire.

Sources de détection du shadow AI sur le réseau

Trois sources de données, par ordre de valeur.

Le proxy HTTPS (HyperText Transfer Protocol Secure) sortant. Même sans déchiffrement, une requête CONNECT expose le nom d’hôte et l’identité authentifiée de l’utilisateur. C’est la meilleure source : elle relie un domaine à une personne, pas seulement à une adresse IP (Internet Protocol). Avec inspection TLS (Transport Layer Security), on voit aussi les chemins d’URL (Uniform Resource Locator), mais l’inspection soulève des questions de proportionnalité à traiter avec le juridique et les représentants du personnel avant d’y toucher.

Les journaux DNS (Domain Name System) des résolveurs internes. Ils couvrent les postes qui contournent le proxy, mais ne donnent qu’une adresse source. Sur un parc en DHCP (Dynamic Host Configuration Protocol), il faut corréler avec les baux pour retrouver le poste. Le DNS chiffré configuré dans le navigateur (DoH, DNS over HTTPS) échappe à cette source si la stratégie de navigateur ne le désactive pas.

Le CASB (Cloud Access Security Broker). Il classe les applications SaaS (Software as a Service) par catégorie et produit l’inventaire sans maintenir de liste à la main. Sa valeur dépend de la fraîcheur de son catalogue.

Un angle mort structurel : les postes nomades hors VPN (Virtual Private Network) et les terminaux personnels. Aucune de ces trois sources ne les voit. Un agent de sécurité sur le poste, ou un proxy cloud forcé, comble le premier trou ; le second relève de la politique d’usage, traitée dans une page dédiée de la rubrique IA.

Exemple : inventaire du shadow AI dans les journaux Squid

Le fichier de motifs suivant couvre les interfaces grand public et les points d’accès API des principaux fournisseurs. Il se maintient à la main, ou s’alimente depuis la catégorie correspondante du CASB.

# domaines-ia.txt : un motif par ligne (expressions régulières étendues)
# Interfaces de chat grand public
cat > domaines-ia.txt <<'EOF'
(^|[ .])chatgpt\.com
(^|[ .])chat\.openai\.com
(^|[ .])gemini\.google\.com
(^|[ .])claude\.ai
(^|[ .])copilot\.microsoft\.com
(^|[ .])chat\.mistral\.ai
(^|[ .])perplexity\.ai
# Points d'accès API : un poste qui les appelle directement porte souvent une clé personnelle
(^|[ .])api\.openai\.com
(^|[ .])api\.anthropic\.com
(^|[ .])generativelanguage\.googleapis\.com
EOF

# Journal Squid au format natif : champ 7 = URL (hote:443 pour CONNECT, URL complète sinon), champ 8 = utilisateur authentifié
# awk réduit le champ 7 au seul nom d'hôte
# Sortie : nombre de requêtes, utilisateur, domaine ; les plus gros consommateurs en tête
grep -v '^#' domaines-ia.txt > motifs.tmp
awk '{u=$7; sub(/^[a-z]+:\/\//, "", u); sub(/[:\/].*$/, "", u); print $8, u}' /var/log/squid/access.log \
  | grep -E -f motifs.tmp \
  | sort | uniq -c | sort -rn | head -30

La sortie mesure une fréquence de connexions, pas un volume envoyé : sur un tunnel CONNECT, le champ des octets additionne montant et descendant.

Encadrer le shadow AI : offre autorisée, redirection, résidu bloqué

L’ordre d’exécution compte plus que chaque mesure prise isolément.

Mesurer pendant quelques semaines sans bloquer. L’inventaire révèle les métiers consommateurs et les outils réellement utilisés. Une campagne perçue comme punitive pousse l’usage vers les téléphones.
Ouvrir l’offre autorisée. Un espace entreprise avec authentification fédérée, ou une passerelle API interne adossée à l’annuaire, rattache chaque usage à une identité gérée. Le détail du provisionnement et de l’audit relève de la gouvernance des identités.
Rediriger plutôt que refuser. Le proxy renvoie les domaines grand public vers une page interne qui explique où se trouve l’outil autorisé.
Restreindre les connexions aux comptes de l’organisation. Certains fournisseurs acceptent un en-tête injecté par le proxy qui limite la connexion aux espaces de l’organisation. La disponibilité et le nom de cet en-tête varient selon l’éditeur et l’offre : à vérifier dans la documentation en vigueur avant de le promettre à qui que ce soit.
Suivre la dérive. Un nouvel assistant grand public sort chaque mois. Le fichier de motifs non révisé détecte parfaitement les usages de l’an dernier.

Ce que la détection du shadow AI ne garantit pas

La détection réseau voit une connexion, pas un contenu. Elle ne dit pas si le salarié a demandé une recette de cuisine ou collé un contrat : la prévention sur le contenu relève d’autres contrôles, décrits dans la page consacrée aux secrets dans les prompts. Elle ne couvre pas non plus les assistants intégrés à des outils déjà autorisés : une fonction d’IA activée par défaut dans un logiciel de bureautique ou un éditeur de code passe par les domaines de l’éditeur, déjà sur liste blanche, et reste invisible pour un filtrage par nom d’hôte. L’inventaire doit donc inclure une revue des fonctions d’IA embarquées dans les SaaS existants.

Enfin, la détection ne rétroagit pas. Ce qui a été envoyé avant la mise en place de l’offre autorisée reste chez le fournisseur, sous les conditions du compte personnel utilisé : aucun levier contractuel de l’organisation ne s’y applique.

🐝 Ce qui arrive si on s’en passe

Sans inventaire ni offre autorisée, un incident impliquant un assistant public ne peut pas être instruit : aucun journal ne relie un salarié à un service ni à une période, donc impossible de dire quels documents ont pu sortir, ni vers quel fournisseur adresser une demande. Les comptes personnels échappent aussi au départ des salariés : l’historique des conversations reste accessible à l’ancien employé après la révocation de son compte d’annuaire, puisqu’aucune identité d’entreprise n’y est rattachée. L’organisation perd enfin toute capacité à exercer ou relayer une demande de suppression au titre du RGPD (Règlement général sur la protection des données) pour des données de tiers qui ont transité par ces comptes.

🦫 Explication de la marmotte 🍫

Beaucoup de salariés utilisent des assistants de conversation disponibles sur Internet pour écrire, résumer ou traduire. Quand ils le font avec un compte personnel, l’entreprise ne sait pas quels textes ont été envoyés, ni à quelle société. Ces textes peuvent contenir des informations sur des clients ou des contrats, et ils sont stockés chez le fournisseur sans que l’entreprise puisse demander leur effacement. Pour s’en rendre compte, l’équipe de sécurité regarde les journaux du serveur par lequel passent les connexions à Internet. Ces journaux indiquent quel utilisateur a contacté quel site, sans montrer le contenu échangé. On compte ainsi les visites vers les sites d’assistants connus. Ensuite, l’entreprise met à disposition un assistant officiel, relié aux comptes de travail, avec des règles écrites. Seulement après, elle bloque les versions grand public et affiche une page qui indique où trouver l’outil autorisé. Si on bloque tout sans rien proposer, les salariés utilisent leur téléphone personnel : l’usage continue, mais plus personne ne le voit. Cette surveillance a des limites : elle ne voit ni ce qui est écrit dans l’assistant, ni les connexions faites depuis un appareil personnel, ni les fonctions d’assistant cachées dans des logiciels déjà autorisés. Il faut aussi mettre à jour la liste des sites, car de nouveaux assistants apparaissent sans cesse.

Pages voisines

La citent

Shadow AI, détecter les assistants IA publics non déclarés

Elle cite

: les deux pages se citent l’une l’autre.

Shadow AI, détecter les assistants IA publics non déclarés

Shadow AI, détecter les assistants IA publics non déclarés

Pourquoi l’interdiction aveugle du shadow AI échoue

Sources de détection du shadow AI sur le réseau

Exemple : inventaire du shadow AI dans les journaux Squid

Encadrer le shadow AI : offre autorisée, redirection, résidu bloqué

Ce que la détection du shadow AI ne garantit pas

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines