Anthropic et d'autres modèles de langage peuvent appeler des outils cachés sans autorisation

Aujourd'hui, le principal risque des LLM agentiques ne tient pas au fait qu'ils se trompent parfois dans les paramètres d'une fonction. Il tient au fait qu'avec une architecture mal conçue, ils peuvent appeler un outil que personne ne leur a formellement fourni. Si la fonction existe dans l'environnement, le modèle peut deviner son nom, inventer des arguments et produire un effet de bord bien réel : lire un secret, écrire un message, interroger l'API d'un tiers.

Sur le papier, les droits d'accès semblent limités ; en pratique, la frontière entre autorisé et interdit devient probabiliste. Pour les systèmes où le modèle manipule des données, des e-mails, des documents ou des intégrations d'entreprise, ce n'est plus une curiosité, mais un risque de sécurité. Le problème apparaît lorsque le modèle agentique est couplé à un environnement client dans lequel la liste des outils autorisés diverge de l'espace de noms effectif.

Dans la démonstration, le modèle ne disposait que de read_url, mais l'environnement contenait aussi une fonction read_secret. Après une indication du type from dialoghelper import *, le modèle a conclu qu'il avait accès à read_secret et a tenté d'appeler cet outil. Si la bibliothèque ou l'API ne vérifie que le format de l'appel, sans confronter strictement le nom de la fonction au schéma fourni, la requête passe.

L'auteur a observé un comportement similaire non seulement chez Anthropic, mais aussi, dans certains scénarios, chez Gemini, Grok et via des surcouches multifournisseurs. Autrement dit, la vulnérabilité ne relève pas d'une seule marque : elle naît à la jonction du modèle, du SDK et de l'infrastructure agentique. Le danger s'accroît fortement lorsque le système entre dans ce qu'on appelle la triade mortelle : le modèle a accès à des outils externes, à du contenu non fiable et à des données privées.

L'injection de prompt cesse alors d'être un simple désagrément pour devenir un canal de fuite. Il suffit qu'un attaquant glisse une instruction dans un e-mail, une page web ou un document pour que le modèle, persuadé de disposer de l'outil caché, aille lui-même chercher le secret et l'envoie à l'extérieur. Plus gênant encore, la séparation architecturale sur laquelle comptent les développeurs peut procurer un faux sentiment de sécurité : l'outil sensible n'est apparemment pas inclus dans le jeu d'outils, mais il réside physiquement dans le même environnement et devient accessible par un appel non autorisé.

Ce type de défaillance est difficile à détecter. Dans bien des cas, le modèle se comporte correctement et refuse l'appel interdit, puis cède soudain à cause d'un détail du contexte : la formulation de l'indication, l'historique des messages, voire le nom d'un module. L'article cite un exemple révélateur où une même action est tantôt bloquée, tantôt exécutée après une mention anodine de dialoghelper.

Le décodage structuré réduit partiellement le risque, car il contraint le modèle à respecter le schéma, mais il implique des compromis : latence accrue, limites strictes sur le nombre d'outils strict et baisse de performances sur les grands ensembles de fonctions. On ne peut donc pas se reposer uniquement sur l'intelligence du modèle. Le nom de l'outil doit être vérifié côté fournisseur et dans le code client avant toute exécution effective.

La conclusion pratique est simple : si vous construisez un agent sur MCP, Jupyter, des SDK internes ou tout autre environnement dynamique, il ne suffit pas de masquer les fonctions superflues dans la description et de compter sur la discipline du modèle. Il faut valider strictement chaque tool call, séparer les opérations sensibles du contenu non fiable et maintenir un espace d'exécution plus restreint que ce que voit le LLM. Sinon, un seul read_secret ou add_msg deviné transforme une architecture agentique soignée en système où les droits d'accès n'existent que jusqu'à la première hallucination réussie.

La bonne nouvelle, c'est que le correctif ne semble pas complexe : il suffit de rejeter tout appel dont le nom ne figure pas dans le schéma autorisé, avant même sa transmission au runtime. Quelques lignes de code défensif dans une bibliothèque ou une passerelle peuvent éliminer toute une classe de problèmes qui, sinon, se fait passer pour une hallucination rare mais, en réalité, brise le modèle de confiance de l'ensemble du système.