Le filigrane IA peut affaiblir les garde-fous des LLM

Ce qui s’est passé

Dan Goodin, d’Ars Technica, rapporte une nouvelle étude qui relie deux sujets qui se croisent rarement : le filigrane de texte et la sécurité de l’IA. Selon l’article, les plateformes d’IA adoptent de nouveaux systèmes de filigrane pour les contenus qu’elles produisent, en réponse à une nouvelle loi de l’Union européenne. Anthropic a récemment indiqué que ses futurs modèles Claude utiliseront SynthID-Text, une approche créée par Google et publiée en open source.

La recherche est signée Andrea Siposova, chercheuse en sécurité de l’IA chez Lasso Security. Elle constate que SynthID-Text peut modifier plus que le choix des mots. Il peut aussi changer les outils qu’un modèle invoque, ainsi que la probabilité qu’il respecte ou ignore les garde-fous de sécurité appris à l’entraînement. L’effet peut s’aggraver face à un prompt adversarial, par lequel un attaquant cherche à pousser un modèle à une action nuisible, comme révéler un mot de passe ou d’autres informations sensibles. Dans certains cas, des instructions qu’un modèle refuserait normalement sont exécutées une fois le filigrane déployé. La leçon principale de l’article est que les développeurs doivent tester avec soin le comportement de leurs LLM et de leurs agents lorsque le filigrane est actif.

Les faits essentiels du rapport

• **Pourquoi le filigrane se répand.** L’article rattache ces nouveaux systèmes à une nouvelle loi de l’Union européenne.
• **Ce que fait SynthID-Text.** Il utilise une clé secrète qui modifie subtilement la façon dont un modèle choisit le mot suivant. Là où le meilleur choix serait « cloudy », la clé peut le remplacer par « overcast ». Quiconque connaît la clé peut déterminer si le texte a été généré par la plateforme qui la détient.
• **Ce qui a été testé.** Siposova a utilisé la configuration « non-distortionary » de SynthID-Text via le SynthIDTextWatermarkLogitsProcessor de Hugging Face, non modifié.

Elle a soumis des prompts nuisibles à six modèles à poids ouverts et comparé les réponses avec et sans filigrane.

• **Ce qu’elle a constaté.** Le filigrane a modifié les réponses aux demandes nuisibles, et le changement était plus marqué lorsque ces demandes étaient associées à des techniques d’injection de prompt. Sur plusieurs modèles, le filigrane a rendu le modèle plus enclin à répondre à des demandes nuisibles qu’il aurait sinon refusées.
• **Les agents sont touchés aussi.** Les mêmes jetons échantillonnés peuvent décider quel outil est appelé et quels arguments lui sont transmis. Siposova nomme cet effet comportemental « sampling drift » (dérive d’échantillonnage).
• **La clé compte.** Les réponses des modèles variaient selon la clé secrète employée.

Comment fonctionne SynthID-Text

Le filigrane intègre un signal dans la sortie, de sorte qu’elle puisse plus tard être identifiée comme générée par une IA. C’est ce qu’on appelle la provenance. Un modèle de langage choisit normalement chaque mot suivant en échantillonnant parmi un ensemble de candidats probables. SynthID reprend ce processus d’échantillonnage et lui ajoute un générateur de graine aléatoire, un algorithme d’échantillonnage et une fonction de score. Au lieu d’un générateur de nombres aléatoires quelconque, le processus emploie une clé secrète. Le choix des mots reste aléatoire. Mais les personnes qui connaissent la clé peuvent examiner une suite de mots et déterminer la probabilité que cette clé ait été utilisée.

Une caractéristique centrale est l’échantillonnage par tournoi (tournament sampling). Comme dans une compétition sportive, SynthID évalue un grand nombre de jetons candidats pour le mot suivant. La clé secrète leur attribue des scores de probabilité. Deux jetons s’affrontent à chaque tour, et celui qui a le score caché le plus élevé passe au tour suivant. Le processus se poursuit jusqu’à ce qu’un dernier jeton l’emporte. L’article renvoie à deux liens externes pour en savoir plus sur cet échantillonnage.

Le point à retenir est simple. Le filigrane n’est pas ajouté après l’écriture du texte. Il vit à l’intérieur du choix de chaque jeton. C’est pourquoi il reste invisible pour le lecteur, et aussi pourquoi il peut, en principe, atteindre tout ce qui dépend de ces choix.

Notre analyse : pourquoi un changement d’échantillonnage peut toucher la sécurité

Cette section est notre lecture, pas une affirmation de la source. Un refus n’est pas un interrupteur séparé. Il résulte de la même génération jeton après jeton que n’importe quelle autre réponse. Un modèle refuse une demande nuisible parce que les jetons de refus sont la suite la plus probable. Si une étape d’échantillonnage pousse le processus vers d’autres jetons, l’équilibre peut basculer. Les propres mots de Siposova vont dans ce sens : le filigrane est conçu pour être imperceptible au lecteur, mais modifier quoi que ce soit dans ce que génère un modèle entraîne des compromis, et « cela va se manifester quelque part ».

L’injection de prompt aiguise l’inquiétude. Selon elle, un refus affaibli devient plus lourd de conséquences quand le modèle peut aussi agir par des outils. Un modèle de conversation qui répond à une mauvaise demande produit du texte. Un agent qui y répond peut appeler un outil avec de vrais arguments. L’article indique que les mêmes jetons échantillonnés peuvent déterminer quel outil est appelé et quels arguments sont transmis.

Deux détails de la source méritent l’attention. D’abord, la figure sur les appels d’outils montre que le filigrane a changé quels appels individuels étaient corrects, parfois bien plus que ne le laisse penser le score de précision global. Autrement dit, une précision agrégée peut sembler stable alors que des appels individuels passent du juste au faux et du faux au juste. Une équipe qui ne surveille que l’indicateur global pourrait passer à côté. Ensuite, la figure sur la variation de clé représente chaque clé secrète par un point. Les points à droite de zéro indiquent une plus grande complaisance envers les demandes nuisibles que sans filigrane, ceux de gauche une moindre complaisance. Le texte de l’article ne dit pas combien de points se trouvent de chaque côté. Mais l’existence de ce graphique suggère que l’effet dépend de la clé, et qu’une clé testée une fois ne règle pas la question pour une autre.

Limites de l’étude et questions ouvertes

L’article est clair sur les limites. La recherche ne teste pas la réaction des modèles Claude sous filigrane. Elle teste six modèles à poids ouverts, ce qui donne au chercheur un accès à l’échantillonnage des jetons, activable et désactivable pendant l’échantillonnage par tournoi tandis que les autres réglages restent fixes. Les expériences ont aussi porté sur l’implémentation Hugging Face de l’échantillonnage par tournoi de SynthID-Text, et non sur l’implémentation précise que les modèles Claude utiliseront. De plus, notre source est un article de presse sur l’étude. Son texte ne donne ni tailles d’effet, ni noms de modèles, ni résultats par modèle. Nous n’avons pas lu le rapport d’origine et ne pouvons donc pas dire l’ampleur des effets.

L’article conclut néanmoins qu’au moins certaines formes de filigrane peuvent affecter la sécurité des modèles et des agents. Des questions ouvertes en découlent. Une implémentation de production se comporte-t-elle comme la version open source ? Quel est l’écart sur un grand nombre de clés ? Une plateforme peut-elle choisir des clés ou des réglages qui évitent la dérive ? La source n’y répond pas.

Conseils pratiques

• **Testez filigrane activé.** L’article dit que les développeurs doivent tester à fond le comportement de leurs LLM et de leurs agents lorsque le filigrane est en place.

Une évaluation de sécurité faite sur le modèle sans filigrane peut ne pas décrire le système déployé.

• **Incluez les agents et les outils.** Vérifiez quels outils sont appelés et avec quels arguments, pas seulement si le texte a l’air correct.
• **Essayez plusieurs clés.** Le résultat sur la variation de clé montre que le comportement différait selon la clé.
• **Faites du red teaming sur toute la pile.** L’article estime que les exercices de piratage en red team doivent mettre les plateformes sous contrainte, pour vérifier qu’elles se comportent comme prévu lorsque SynthID est déployé.
• **Lisez la conclusion avec prudence.** Ce sont des indices sur un ensemble de modèles à poids ouverts et sur une seule implémentation. Ce n’est pas un constat sur Claude.