GhostSplice révèle les failles des IA face au contrôle d'accès
Une seule phrase divisée en deux parties anodines peut manipuler les grands modèles de langage pour qu’ils exécutent des commandes interdites—à chaque essai. Des chercheurs en sécurité ont démontré GhostSplice, une technique qui fragmente une instruction malveillante en morceaux parmi des descriptions d’outils inoffensives, empêchant le modèle de percevoir la demande complète et donc de la rejeter. Cette faille a fonctionné jusqu’à 100 % du temps sur certains modèles, révélant un problème plus profond : les mesures de sécurité actuelles supposent que la requête entière est visible d’un coup, une hypothèse que les attaquants peuvent facilement briser.
Le défaut d’architecture derrière l’astuce
L’injection de requêtes via des sorties d’outils non fiables n’est pas nouvelle ; quiconque teste des systèmes agents en conditions réelles alerte depuis longtemps sur le risque d’ingestion de texte externe avant l’exécution d’outils privilégiés, créant une porte dérobée pour l’injection. GhostSplice rappelle que les défenses basées sur le refus des requêtes complètes luttent contre une guerre dépassée. En divisant une demande malveillante en deux ou trois morceaux, le modèle reconstitue l’intention en interne sans jamais être confronté à un segment déclenchant ses garde-fous. Le protocole MCP (Model Context Protocol) formalise cette relation de confiance risquée en standardisant la façon dont les agents récupèrent les descriptions et résultats d’outils depuis des serveurs qu’ils ne contrôlent pas entièrement, avant d’agir avec accès au système de fichiers, clés SSH ou exécution de commandes.
Pourquoi nommer la technique est hors sujet
Qualifier GhostSplice de vulnérabilité distincte lui accorde plus de novation qu’elle n’en mérite. Son efficacité ne réside pas dans un code ingénieux, mais dans un écart structurel : l’ingestion de contenu non fiable combinée à des agents capables d’appeler des outils dotés de réelles capacités équivaut à un contournement prévisible. Le taux de réussite « jusqu’à 100 % » sur plusieurs modèles n’est pas un risque marginal ; c’est une quasi-certitude dès lors que les attaquants découvrent le fonctionnement des filtres. Une formation renforcée au refus des requêtes ou des listes de blocage actualisées ne suffiront pas à corriger ce problème : la solution doit s’appliquer au niveau des capacités. Si l’agent peut, par défaut, lire des clés SSH ou effectuer des appels réseau arbitraires, aucun refus de requête ne pourra limiter les dégâts.
Où doivent migrer les filets de sécurité
Pour les équipes intégrant des agents de codage IA à des serveurs MCP qu’elles ne maîtrisent pas entièrement, le filet de sécurité ne peut plus reposer sur la couche de refus des requêtes. Les contrôles doivent migrer vers le niveau des capacités : restreindre les fichiers accessibles, les hôtes joignables et les identifiants utilisables par l’agent. Les politiques par défaut de refus et les vérifications dynamiques des capacités sont les seules méthodes fiables pour contenir un attaquant capable de fragmenter ses instructions pour échapper aux défenses actuelles.
Pourquoi c’est important
GhostSplice compte car elle balaye l’illusion selon laquelle les LLM pourraient imposer un contrôle d’accès fiable via des refus de requêtes. Elle démontre que lorsque du contenu non fiable rencontre des outils puissants, des lacunes systémiques apparaissent, que les conventions de nommage ou les cycles de correctifs ne peuvent combler. Les organisations déployant des systèmes agents doivent repenser leur posture de sécurité autour de restrictions de capacités plutôt que de motifs de requêtes, sous peine de découvrir ces failles à leurs dépens lors d’un rapport d’incident dans dix-huit mois.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.