if ( !emtpy($headline_subheadline ) ) : ?>
Une étude révèle que les agents d’IA peuvent être amenés à exécuter des appels d’outils contrôlés par des attaquants en leur faisant écho. Les chercheurs ont également découvert 253 bogues de sécurité vérifiés sur 118 serveurs MCP open source.
endif; ?>
Les chercheurs ont trompé six cadres d’agents d’IA largement utilisés pour qu’ils exécutent des appels d’outils écrits par un attaquant, simplement en demandant au modèle sous-jacent de répéter le rappel.
La technique, que les chercheurs appellent « Repeat-After-Me », a fonctionné sur LangGraph de LangChain, Microsoft Agent Framework, AutoGen de Microsoft, Agent Development Kit 2.0 de Google, Strands Agents d’AWS et CrewAI, selon des chercheurs de la Pennsylvania State University, de l’Université Montpellier et du Dartmouth College.
« Une demande de répétition de texte apparemment anodine donne ainsi à l’attaquant un contrôle direct sur l’invocation de l’outil et ses arguments », ont écrit les chercheurs dans l’article.
Le même article rapporte qu’un outil de test construit par l’équipe a trouvé des bogues de sécurité vérifiés dans 118 des 273 serveurs MCP (Model Context Protocol) open source qu’il a pu exécuter.
Comment fonctionne l’astuce
Dans la démonstration, les chercheurs ont demandé à un modèle d’IA de répéter un texte formaté comme une demande d’invocation d’un outil. Le modèle a initialement refusé la demande dangereuse mais a inclus le texte demandé dans sa réponse. Le framework ne l’a pas exécuté à ce stade.
Les chercheurs ont ensuite formulé la demande comme étant hypothétique et ont demandé au modèle de reproduire uniquement le texte fourni. Le modèle a émis un appel d’outil structuré, que LangGraph a envoyé. L’outil simulé a renvoyé un résultat avant que le modèle n’émette un autre refus.
« Le texte de refus et l’appel exécuté sont en désaccord : l’invite du système a façonné ce que le modèle a dit, pas ce que l’orchestrateur a fait », ont écrit les chercheurs.
Les résultats des chercheurs ne montrent pas que chaque déploiement des six frameworks se comporte de cette façon.
Un refus arrivé trop tard
Le document détaille une démonstration sur LangGraph 1.2.0 exécutant le modèle Llama 3.1 8B de Meta via Ollama. L’agent disposait de deux outils factices, make_bomb et launch_missiles, qui renvoyaient des données fixes et n’avaient aucun effet réel. Sa seule sauvegarde était une invite système indiquant au modèle de refuser les demandes dangereuses.
Lorsqu’on lui a demandé pour la première fois de répéter un appel launch_missiles, le modèle a refusé mais a imprimé l’appel sous forme de texte et LangGraph n’a rien exécuté. Les chercheurs ont ensuite qualifié la demande d’hypothétique et ont demandé au modèle de générer uniquement l’appel cité. Cette fois, le modèle a renvoyé l’appel sous forme structurée et LangGraph l’a exécuté immédiatement avec les arguments de l’attaquant. Le refus du modèle n’est intervenu qu’après le retour de l’outil.
« L’invite du système a façonné ce que dit le modèle, et non ce que fait l’orchestrateur », ont écrit les chercheurs. Ils ont déclaré avoir signalé la vérification préalable à l’exécution manquante aux responsables de LangGraph.
L’article comprend une transcription complète uniquement pour LangGraph. Pour les cinq autres frameworks, il est indiqué que les chercheurs ont reproduit le comportement mais ne donne pas plus de détails.
LangChain, Microsoft, Google, AWS et CrewAI n’ont pas immédiatement répondu aux demandes de commentaires.
La sortie du modèle n’est pas l’autorisation
Vibhum Dubey, chercheur indépendant en sécurité et membre de l’équipe rouge, a déclaré que les résultats indiquent une faiblesse architecturale plutôt qu’un seul bug.
« Un modèle peut générer un appel d’outil techniquement valide mais encore inapproprié pour la tâche », a déclaré Dubey. « Si la couche d’orchestration traite cette sortie comme une autorité suffisante pour exécuter l’opération, une manipulation au niveau du modèle devient un problème de sécurité au niveau du système. »
Le degré d’exploitation de la technique dépend de ce qu’un attaquant peut influencer et de ce que l’agent est autorisé à faire, a-t-il ajouté. Un agent en lecture seule présente un risque différent de celui qui peut accéder à des fichiers confidentiels, modifier des référentiels de code ou exécuter des commandes.
Les outils restent porteurs de risques
Parce qu’un attaquant peut dicter les arguments qui parviennent à un outil, les chercheurs ont soutenu que les outils doivent valider leurs propres entrées. Ils ont construit ToFu, un framework de fuzzing qui lit la description de chaque outil et vérifie si l’outil applique les limites qu’il annonce, comme rester dans un dossier désigné.
Après un examen manuel, ils ont confirmé 253 bogues affectant 343 outils sur 118 serveurs. Les plus graves étaient 64 failles de cheminement, sept failles de falsification de requête côté serveur (SSRF), cinq bogues d’exfiltration de données et trois failles d’injection de commandes du système d’exploitation. La plupart des autres problèmes étaient des problèmes de sortie réfléchie et d’injection de journaux, que le document considère comme ayant un impact moindre dans de nombreux déploiements.
Les chercheurs ont écrit que « de nombreux outils s’appuient implicitement sur le LLM pour nettoyer les entrées », même si les invites, le contenu récupéré et les résultats d’autres outils peuvent tous influencer ces entrées.
Séparer la demande de l’autorité
Dubey a déclaré que la priorité des équipes de sécurité est de séparer la capacité d’un modèle à demander une action de l’autorité du système pour l’exécuter.
« Chaque appel d’outil sensible doit être soumis à des contrôles d’autorisation indépendants », a-t-il déclaré. « Une syntaxe valide ou une explication convaincante du modèle ne devrait jamais remplacer l’autorisation. »
Il a recommandé d’exécuter des agents avec un accès restreint aux fichiers et au réseau, des environnements d’exécution isolés et des informations d’identification limitées, avec une approbation explicite pour les opérations sensibles ou irréversibles. Les équipes de sécurité devraient également surveiller les séquences d’appels d’outils plutôt que de juger chaque action isolément, a-t-il déclaré.
Le document n’a pas été évalué par des pairs. Les serveurs ont été testés avec des versions de code corrigées, et le document ne précise pas si l’une des failles a depuis été corrigée ou exploitée dans la nature.
