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

Le principal risque des LLM agentifs aujourd'hui n'est pas qu'ils se trompent parfois sur les paramètres de fonction, mais qu'avec une architecture défaillante ils peuvent invoquer un outil qui ne leur a jamais été formellement accordé. Si une telle fonction existe dans l'environnement, le modèle est capable de deviner son nom, d'inventer des arguments et d'obtenir un effet secondaire réel : lire un secret, écrire un message, accéder à l'API de quelqu'un d'autre. Sur le papier, les droits d'accès semblent limités, mais en pratique la frontière entre autorisé et interdit devient probabiliste.

Pour les systèmes où le modèle travaille avec des données, des courriels, des documents ou des intégrations d'entreprise, ce n'est plus une curiosité mais un risque de sécurité. Le problème se manifeste dans la combinaison d'un modèle agentif et d'un environnement client, où la liste des outils autorisés et l'espace de noms réel divergent. Dans une démonstration, le modèle n'a reçu que read_url, mais dans l'environnement existait une fonction read_secret.

Après un indice comme from dialoghelper import *, le modèle a décidé qu'il avait accès à read_secret et a tenté d'invoquer cet outil. Si la bibliothèque ou l'API ne vérifie que le format de l'appel et ne compare pas strictement le nom de la fonction au schéma émis, la requête passe outre. L'auteur a montré un comportement similaire non seulement chez Anthropic, mais dans des scénarios spécifiques aussi chez Gemini, Grok et via des enveloppes multi-fournisseurs.

En d'autres termes, la vulnérabilité ne naît pas chez une marque, mais à l'intersection du modèle, du SDK et de l'échafaudage agentif. Le danger augmente considérablement lorsqu'un tel système se retrouve dans la soi-disant triade mortelle : le modèle a accès à des outils externes, à du contenu non fiable et à des données privées. Alors l'injection de prompt cesse d'être simplement une caractéristique désagréable et devient un canal de fuite.

Il suffit qu'un attaquant intègre une instruction dans un courriel, une page web ou un document, et le modèle, confiant d'avoir un outil caché, lui-même accède au secret et l'envoie vers l'extérieur. Particulièrement désagréable est le fait que la séparation architecturale sur laquelle comptent les développeurs peut donner une fausse sensation de sécurité : un outil sensible semble ne pas être inclus dans l'ensemble, mais se trouve physiquement à proximité dans l'environnement et devient accessible via un appel non autorisé. Détecter une telle défaillance est difficile.

Dans de nombreux cas, le modèle se comporte correctement et refuse l'appel interdit, puis échoue soudainement en raison d'une bagatelle dans le contexte : la formulation d'un indice, l'historique des messages ou même le nom d'un module. L'article fournit un exemple instructif où la même action est parfois bloquée, parfois passe après une mention inoffensive de dialoghelper. Le décodage structuré réduit partiellement le risque en forçant le modèle à s'adapter à un schéma, mais il y a aussi des compromis : augmentation de la latence, limites strictes sur le nombre de strict-tools et dégradation des performances sur de grands ensembles de fonctions.

Par conséquent, compter uniquement sur le comportement intelligent du modèle est impossible. La vérification du nom de l'outil doit se faire du côté du fournisseur et dans le code client avant l'exécution réelle. 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 supplémentaires de la description et d'espérer la discipline du modèle.

Vous devez valider strictement chaque appel d'outil, séparer les opérations sensibles du contenu non fiable et maintenir l'espace d'exécution plus étroit que la visibilité du LLM. Sinon, un seul read_secret ou add_msg deviné transforme une architecture agentive soignée en un système où les droits d'accès n'existent que jusqu'à la première hallucination réussie. La bonne nouvelle est que la correction ne semble pas compliquée : il suffit de rejeter tout appel dont le nom est absent du schéma autorisé avant de le transmettre au runtime.

Quelques lignes de code défensif dans une bibliothèque ou une passerelle peuvent fermer une classe de problèmes qui autrement seraient masqués comme une hallucination rare, mais qui en réalité brise le modèle de confiance de tout le système.