Les garde-fous IA sont censés protéger votre entreprise : ils bloquent les requêtes dangereuses et refusent de produire du contenu malveillant. Mais une recherche publiée par Cisco Talos rappelle une vérité inconfortable : chaque refus est une information. En observant précisément ce que votre assistant refuse, un attaquant apprend ce qu’il sait, ce qu’il protège et où se situe la frontière. Pour une PME-ETI qui déploie un copilote interne, c’est un angle mort rarement testé.
Pourquoi les garde-fous IA fuient de l’information
Un modèle de langage n’a pas de mécanisme d’autorisation. Il produit du texte, et le refus est du texte comme un autre. Quand un assistant répond « je ne peux pas vous aider avec cela », il vient de révéler que la requête a touché une zone sensible — donc qu’il existe une zone sensible, et qu’elle est atteignable.
Le mécanisme s’appelle un oracle de refus. L’attaquant ne cherche pas à obtenir la réponse interdite du premier coup : il envoie des dizaines de variantes et note lesquelles passent, lesquelles bloquent. Le signal binaire refus/réponse suffit à cartographier :
- les sujets couverts par le filtrage — donc les sujets jugés critiques par l’entreprise ;
- la formulation exacte qui déclenche le blocage, et celle qui l’esquive ;
- l’existence de documents internes, quand le refus change de ton selon que la donnée existe ou non ;
- la présence d’outils connectés (bases, API, tickets), révélée par des messages d’erreur trop bavards.
Ce dernier point est le plus coûteux : un assistant branché sur votre base documentaire qui répond « ce document est confidentiel » au lieu de « je n’ai pas trouvé » vient de confirmer l’existence du document. La différence semble anodine. Elle ne l’est pas.
Le refus comme canal auxiliaire
C’est la logique classique du side-channel appliquée à l’IA. En cryptographie, on mesure le temps de calcul pour deviner une clé. Ici, on mesure le comportement du filtre pour deviner le contenu. La différence : aucun exploit, aucune CVE, aucun correctif à appliquer. L’attaquant utilise le produit exactement comme prévu.
Ce que ça change pour une PME-ETI
La plupart des déploiements que nous voyons partagent le même schéma : un assistant interne, connecté au SharePoint ou au CRM, accessible à tous les salariés, parfois exposé à des partenaires. Trois conséquences directes :
- La surface n’est pas le modèle, c’est l’accès. Le fournisseur sécurise le modèle ; c’est vous qui décidez ce qu’il peut lire.
- Le prompt système n’est pas un secret. Il finit toujours par fuir, par accumulation de refus et de reformulations. Ne pas y mettre de règle métier confidentielle ni de nom d’infrastructure.
- Le sondage est indétectable par défaut. Cent requêtes refusées ressemblent à un utilisateur maladroit, sauf si vous journalisez et corrélez.
Le sujet rejoint celui de l’injection de prompt dans les assistants IA internes : dans les deux cas, la faille n’est pas dans le modèle mais dans le périmètre qu’on lui a confié.
Durcir vos garde-fous IA : cinq mesures concrètes
Réduire la fuite ne consiste pas à ajouter des filtres, mais à rendre les garde-fous IA moins bavards et l’accès plus strict.
- Uniformiser les refus. Un seul message générique pour tous les cas de blocage. Jamais de motif, jamais de mention du document ou de la règle déclenchée.
- Supprimer la distinction « existe mais interdit » / « n’existe pas ». Les deux doivent produire la même réponse, mot pour mot.
- Filtrer en amont, pas dans le prompt. L’assistant ne doit indexer que les documents autorisés à l’utilisateur qui pose la question. Un filtrage post-génération arrive trop tard.
- Journaliser le taux de refus par utilisateur. Un pic de blocages sur un même compte en quelques minutes est un signal de reconnaissance, au même titre qu’un scan de ports. Cette télémétrie doit remonter dans le SOC.
- Limiter le débit et tester régulièrement. Le sondage exige du volume : un plafond de requêtes par utilisateur casse l’attaque. Complétez par un test d’intrusion applicatif ciblé sur l’assistant.
Ces contrôles supposent une visibilité côté détection. C’est exactement le rôle d’un SOC capable de trier le signal IA sans se noyer dans le bruit : sans corrélation, une campagne de sondage reste invisible.
Et si vous hébergez le modèle vous-même ?
L’auto-hébergement ne supprime pas le problème, il le déplace. Vous contrôlez les journaux et les filtres, mais vous héritez aussi de la sécurité de l’inférence — un sujet que nous avons traité côté empoisonnement des modèles IA locaux. Dans les deux cas, la règle tient en une phrase : l’assistant ne doit jamais pouvoir lire ce que son interlocuteur n’a pas le droit de lire.
Ce qu’il faut retenir
Un garde-fou IA n’est pas un mur, c’est un indicateur. Il signale à l’attaquant qu’il approche de quelque chose de sensible, et la granularité de ce signal détermine la vitesse à laquelle il cartographie votre système. La bonne posture n’est pas de refuser plus, mais de refuser de la même façon, en journalisant tout et en donnant à l’assistant le strict minimum d’accès. Chez ucyber.ai, nous auditons ces déploiements avec une approche Agentic SOC : la détection du sondage vaut mieux que la promesse d’un filtre parfait.