GhostJacking révèle les lacunes de la gouvernance des identités des agents d’IA

Google News a mis en lumière GhostJacking après que des chercheurs ont montré comment un seul rapport d’erreur empoisonné pouvait orienter un agent d’IA autorisé vers du code contrôlé par un attaquant. L’attaque réussit malgré les défenses périmétriques, car l’agent effectue chaque étape à l’aide d’outils légitimes et des autorisations du développeur.

Cette distinction change le débat sur la sécurité. Les identifiants de l’agent ne sont pas nécessairement volés et son logiciel n’est pas nécessairement compromis. En revanche, des données opérationnelles non fiables modifient l’intention de l’agent alors que son identité authentifiée reste valide.

La recherche sous-jacente appelle cette technique plus large « Agentjacking », tandis que l’appellation GhostJacking souligne le caractère presque invisible de la prise de contrôle. Un agent continue d’opérer sous son identité habituelle, laissant les défenseurs distinguer une automatisation légitime d’une intention hostile.

Il ne s’agit pas simplement d’une nouvelle histoire d’injection de prompts. Elle révèle une collision entre les modèles de langage, la télémétrie de confiance, les intégrations Model Context Protocol et les systèmes d’identité conçus pour des utilisateurs prévisibles.

Le conflit central est clair. Les entreprises veulent que des agents enquêtent sur les incidents et exécutent des réparations sans supervision constante. Cependant, les autorisations qui rendent ces agents utiles rendent également les décisions manipulées dangereuses sur le plan opérationnel.

Le rapport GhostJacking transforme une file de bugs en vecteur d’attaque

GhostJacking transforme des informations auxquelles un agent est censé faire confiance en instructions qu’il pourrait exécuter.

L’attaque décrite dans le rapport GhostJacking commence par une fausse erreur logicielle. Un attaquant place un texte conçu à cet effet dans des données de télémétrie qu’un agent de développement récupère ensuite lorsqu’il enquête sur des problèmes non résolus.

La télémétrie désigne les journaux, erreurs, traces et enregistrements de diagnostic générés par les logiciels. Les équipes de développement considèrent généralement ces éléments comme des preuves du comportement du système, et non comme un canal de commande actif.

Cette hypothèse s’effondre lorsqu’un modèle de langage lit ces éléments. Le modèle reçoit dans le même flux de texte des faits de diagnostic, des commentaires, du formatage et d’éventuelles instructions.

Les Threat Labs de Tenet Security ont démontré ce schéma en utilisant Sentry, une plateforme de surveillance des erreurs qui accepte des événements d’application. Sentry utilise un Data Source Name, ou DSN, afin que les applications puissent envoyer ces événements au bon projet.

Une application web a souvent besoin de ce DSN dans son code côté client. Le posséder peut donc permettre à quelqu’un de soumettre un événement sans compromettre au préalable le réseau interne de l’organisation.

L’événement de l’attaquant contient une description d’erreur convaincante et des indications de correction apparemment légitimes. Lorsqu’un agent récupère l’événement via une intégration, les instructions malveillantes arrivent aux côtés de données de diagnostic légitimes.

Le modèle est alors confronté à un problème de classification. Il doit déterminer si le texte décrit une erreur, cite une partie externe ou ordonne à l’agent d’effectuer une action corrective.

Selon la recherche contrôlée, les agents testés ont parfois interprété le contenu implanté comme des étapes de résolution valides. Ils ont ensuite exécuté un package contrôlé par les chercheurs avec les privilèges locaux du développeur.

Tenet indique que son package de validation a été conçu pour des tests contrôlés plutôt que pour une activité nuisible. L’entreprise affirme également que les informations collectées ont été expurgées et traitées selon son processus de divulgation.

La conséquence en matière de sécurité dépasse toutefois le package bénin. Une commande hostile exécutée sous un compte de développeur pourrait accéder à des variables d’environnement, des dépôts de code source, des identifiants cloud ou des outils de développement authentifiés.

Tenet a indiqué avoir identifié 2 388 organisations disposant d’identifiants Sentry potentiellement injectables. L’entreprise a également rapporté avoir observé plus de 100 agents agir sur des erreurs injectées lors de tests contrôlés.

Ces chiffres proviennent du fournisseur de sécurité et n’ont pas été reproduits de manière indépendante sur l’ensemble de la population signalée. Ils doivent mesurer l’exposition observée par l’étude, et non des compromissions confirmées par des criminels.

Le changement important est architectural. Les journaux étaient autrefois des preuves passives pour les personnes et les logiciels déterministes. Les flux de travail agentiques peuvent transformer ces mêmes journaux en contexte exécutable.

Cela crée une boucle de rétroaction inhabituelle. Un contrôle de sécurité bloque un trafic suspect, enregistre la requête bloquée et stocke le texte de l’attaquant dans une plateforme de surveillance de confiance.

Plus tard, un agent d’IA lit l’enregistrement stocké pour diagnostiquer l’incident. Le blocage réussi devient alors la voie d’acheminement de l’étape suivante.

Pourquoi l’attention de Google News compte au-delà d’une démonstration de sécurité

La visibilité sur Google News importe parce que GhostJacking relie un risque abstrait lié à l’IA à un flux de travail de développement ordinaire.

L’injection indirecte de prompts est documentée depuis des années. Elle survient lorsque des instructions malveillantes sont intégrées à des données qu’un système d’IA traite tout en accomplissant une autre tâche.

L’attaquant n’a pas besoin de placer ses instructions dans le prompt direct de l’utilisateur. La charge utile peut apparaître dans une page web, un e-mail, un document, un ticket d’assistance, un commentaire de code ou un enregistrement de base de données récupéré.

GhostJacking applique cette faiblesse connue à des preuves opérationnelles. La cible n’est pas un chatbot répondant à une question inoffensive. C’est un agent chargé de diagnostiquer un logiciel et potentiellement d’exécuter des commandes correctives.

Cette différence augmente les enjeux. Un chatbot peut générer une réponse trompeuse, tandis qu’un agent de développement doté de pouvoirs peut modifier des fichiers, invoquer un shell ou accéder à des services authentifiés.

L’événement intervient également pendant l’adoption rapide d’agents connectés à des outils. Model Context Protocol, couramment appelé MCP, offre aux modèles un moyen standard de communiquer avec des outils externes et des sources de données.

MCP peut réduire le travail nécessaire pour connecter un agent à des gestionnaires de tickets, des bases de données, des dépôts, des plateformes de surveillance et des outils de développement locaux. Il ne rend pas automatiquement fiables les contenus provenant de ces systèmes.

Un outil peut être authentique tout en renvoyant des données contrôlées par un attaquant. Cette distinction est centrale dans l’attaque GhostJacking.

La sécurité applicative traditionnelle demande souvent si un appelant peut accéder à une ressource. Ici, l’agent authentifié est autorisé à accéder à la ressource et à exécuter l’action qui en résulte.

La question manquante est de savoir si l’action reflète l’intention de l’utilisateur. L’authentification répond à la question de savoir qui agit, mais elle ne prouve pas pourquoi l’action a été choisie.

NIST décrit le détournement d’agents comme une forme d’injection indirecte de prompts causée par une faible séparation entre les instructions de confiance et les données externes non fiables. Ses évaluations sur le détournement comprenaient des scénarios d’exécution de code à distance, d’exfiltration de données et de hameçonnage automatisé.

Les chercheurs du NIST ont constaté que les attaques adaptatives avaient une grande importance. Dans une évaluation, la plus forte attaque de référence a atteint un taux de réussite de 11 % contre un modèle mis à jour.

Une attaque nouvellement développée a atteint 81 % dans le même environnement de test rapporté. Ce résultat ne fournit pas un taux d’échec universel des modèles, mais il remet en question les affirmations statiques sur la résistance à l’injection de prompts.

Un modèle peut bien fonctionner face à une suite de tests connue et échouer malgré tout face à une attaque adaptée à son comportement. Les équipes de sécurité ne peuvent donc pas considérer un seul benchmark comme une garantie durable.

La couverture de Google News peut contribuer à faire sortir ce constat des cercles spécialisés dans la sécurité de l’IA. Le flux de travail concerné ressemble à ce que les équipes de développement souhaitent déjà confier aux agents : examiner un problème, en identifier la cause et appliquer une correction.

L’article ne met donc pas en garde contre une superintelligence hypothétique. Il concerne un outil d’automatisation familier opérant avec des identifiants familiers contre des services cloud familiers.

C’est précisément cette familiarité qui rend le risque facile à sous-estimer. Chaque composant peut sembler légitime lorsqu’il est examiné séparément.

Le service Sentry est légitime. L’intégration MCP est légitime. L’agent de développement est légitime et le compte du développeur est authentifié.

L’élément hostile se situe dans la transition entre les données et l’intention. Les contrôles d’identité actuels inspectent rarement cette transition.

La gouvernance des identités des agents d’IA s’arrête à l’authentification

La gouvernance des identités des agents d’IA échoue lorsqu’elle vérifie l’acteur sans pouvoir vérifier l’autorité qui sous-tend chaque décision.

Les systèmes d’identité humains commencent généralement par une personne, un compte et des autorisations attribuées. Les administrateurs peuvent examiner à qui appartient le compte et à quelles ressources il peut accéder.

Les comptes de service étendent ce modèle aux applications. Ils fonctionnent raisonnablement bien lorsque les logiciels suivent un code déterministe et remplissent une fonction étroite et documentée.

Un agent d’IA se comporte différemment. Sa prochaine action dépend d’objectifs formulés en langage naturel, du contexte récupéré, du raisonnement du modèle, des outils disponibles et des étapes précédentes du flux de travail.

Le même agent authentifié peut examiner une erreur, modifier un dépôt, appeler un service de déploiement et envoyer un message à une équipe. Son rôle effectif change à mesure que la tâche évolue.

Les organisations gèrent souvent cette complexité en laissant l’agent hériter des accès existants d’un utilisateur. Cette approche simplifie le déploiement, mais elle affaiblit l’attribution.

Un enregistrement d’audit peut montrer qu’un compte de développeur a lancé un package. Il peut ne pas indiquer si le développeur a demandé ce package précis ou examiné la commande au préalable.

Il peut également omettre quel document récupéré a influencé le modèle. Sans cette provenance, les enquêteurs voient l’action finale, mais pas la chaîne d’autorité qui la sous-tend.

L’enquête sur la sécurité des agents de la Cloud Security Alliance illustre le déficit de préparation. Quarante pour cent des organisations interrogées ont indiqué avoir des agents en production, tandis que 31 % supplémentaires les testaient.

Seules 18 % ont déclaré avoir une grande confiance dans la capacité des systèmes d’identité existants à gérer efficacement les identités des agents. À peine 21 % maintenaient un registre ou un inventaire des agents en temps réel.

L’enquête a également révélé une dépendance persistante aux clés d’API statiques, aux comptes de service partagés et aux combinaisons nom d’utilisateur-mot de passe. Ces mécanismes peuvent authentifier l’accès sans représenter une intention déléguée.

Une identité d’agent utile devrait répondre à davantage de questions que « quel jeton a effectué cette requête ? ». Elle devrait relier la requête à un propriétaire, une tâche, des outils approuvés, un périmètre de données et un point d’expiration.

Cet enregistrement devrait survivre à la délégation. Si un agent principal crée un sous-agent, l’enfant ne devrait pas hériter silencieusement de tous les privilèges disponibles pour son parent.

Chaque identité déléguée ne devrait recevoir que l’autorité nécessaire à l’étape qui lui est attribuée. Le système devrait également préserver la relation entre l’utilisateur, l’agent parent, l’agent enfant et l’action résultante.

GhostJacking révèle ce qui se produit lorsque cette chaîne reste implicite. L’erreur malveillante n’a pas besoin de voler l’identité de l’agent, car elle peut orienter l’identité déjà présente.

Cela ressemble au problème classique de l’adjoint confus. Un programme de confiance utilise mal son autorité après avoir accepté une entrée influencée par un attaquant qu’il ne peut pas classer correctement.

Les modèles de langage rendent le problème plus difficile, car ils interprètent le contenu de manière probabiliste. Une « résolution » habilement formatée peut paraître plus exploitable qu’une instruction utilisateur vague.

La hiérarchie des prompts aide les modèles à hiérarchiser les instructions système et utilisateur. Elle ne crée pas de frontière cryptographique entre les résultats factuels d’outils et les commandes intégrées à ces résultats.

Étiqueter une source comme non fiable présente également des limites. Tenet affirme que des agents ont parfois suivi des instructions injectées, même lorsque leur configuration leur indiquait de se méfier des contenus externes.

Cette affirmation nécessite des tests indépendants plus larges, couvrant différents modèles et configurations. Toutefois, les résultats adaptatifs du NIST appuient l’avertissement plus général selon lequel les défenses reposant uniquement sur les instructions se dégradent sous une pression ciblée.

La couche d’identité doit donc partir du principe que le modèle peut prendre une mauvaise décision. La gouvernance doit en limiter les conséquences avant que cette décision ne devienne une action irréversible.

Le compromis central oppose l’accès utile à l’intention vérifiable

Un agent devient plus utile à mesure qu’il obtient des accès, mais chaque permission supplémentaire accroît l’impact d’une intention manipulée.

Un assistant de programmation limité aux suggestions peut tout de même produire du code dangereux. Un agent de programmation disposant d’un accès au terminal peut exécuter ce code avant qu’un développeur ne le lise.

Un agent de réponse aux incidents limité aux résumés peut fausser une enquête. Ce même agent, avec un accès à la production, peut modifier l’infrastructure en suivant un enregistrement de diagnostic empoisonné.

Cela crée un compromis pratique, et non une raison de rejeter toute automatisation agentique. Les organisations doivent relier l’autonomie à des contrôles progressivement plus stricts.

L’accès en lecture seule doit rester la norme pour la découverte et le diagnostic. L’accès en écriture doit être accordé pour des tâches, des ressources et des fenêtres temporelles précises.

L’exécution de commandes mérite une frontière distincte. Un agent capable de récupérer des données de supervision ne devrait pas recevoir automatiquement l’autorisation illimitée d’exécuter tout ce que ces données recommandent.

Les actions à haut risque nécessitent également une autorisation sémantique. Cela signifie évaluer l’objectif et le contexte d’une action, plutôt que de simplement vérifier si l’appelant possède un jeton valide.

Par exemple, une politique peut autoriser un agent à exécuter une commande de test approuvée dans un espace de travail isolé. Cette même politique peut refuser l’installation de paquets, l’accès aux identifiants ou les connexions sortantes.

Ces décisions doivent être prises en dehors du modèle. Demander au même agent potentiellement manipulé de juger sa propre commande ne constitue pas un contrôle indépendant.

L’application des règles à l’exécution offre une séparation plus robuste. Une passerelle peut inspecter chaque appel d’outil demandé, le comparer à une politique et bloquer les actions hors de la tâche approuvée.

La passerelle crée aussi un point d’enregistrement des preuves structurées. Ces preuves peuvent inclure l’identité demandeuse, l’objectif de l’utilisateur, la source récupérée, l’opération demandée, la décision de politique et le résultat.

L’approbation humaine reste utile lorsque l’impact potentiel est élevé. Toutefois, une simple boîte de confirmation générique ne suffit pas.

Le réviseur doit voir ce que fera la commande, aux fichiers ou systèmes auxquels elle peut accéder, et quel contenu externe l’a déclenchée. Sinon, l’approbation devient un simple clic de routine.

Le sandboxing limite les dégâts lorsque l’autorisation échoue. Un agent de programmation peut travailler dans un environnement jetable, sans accès aux identifiants de production ni à des connexions réseau non restreintes.

Des identifiants de courte durée réduisent également l’exposition permanente. L’agent doit obtenir un jeton à portée étroitement définie pour l’opération en cours, puis perdre cette autorité à la fin de la tâche.

Les recherches AutoJack de Microsoft renforcent la même leçon de conception par un mécanisme différent. Du contenu web non fiable a atteint un chemin de contrôle MCP local et pouvait lancer des processus dans une version de développement.

Microsoft a indiqué que la surface concernée avait été renforcée avant d’atteindre la version empaquetée pertinente. Cette conclusion plus large reste importante, car l’agent a dissous une frontière habituellement considérée comme fiable.

Un navigateur humain visitant une page externe ne devient généralement pas le processus d’automatisation local. Un navigateur contrôlé par un agent peut occuper les deux rôles simultanément.

L’attaque GhostJacking franchit une frontière sémantique, tandis qu’AutoJack a franchi des frontières entre le web, localhost et le plan de contrôle. Les deux cas montrent que les agents relient des domaines de sécurité que les contrôles précédents maintenaient séparés.

Cette comparaison met simultanément sous pression les fournisseurs d’identité, les fournisseurs de modèles, les développeurs de frameworks d’agents et les équipes de sécurité en entreprise. Aucun ne peut résoudre le problème seul.

Les développeurs de modèles peuvent améliorer la résistance aux instructions malveillantes. Les développeurs de frameworks peuvent étiqueter les données et contraindre les outils.

Les fournisseurs d’identité peuvent émettre des identifiants de charge de travail à portée limitée et préserver la délégation. Les entreprises doivent néanmoins définir les responsabilités, les seuils d’approbation et l’autonomie acceptable.

La bonne conception suppose que chaque couche peut échouer. Un modèle résistant doit tout de même fonctionner avec le principe du moindre privilège, et une identité bien limitée doit tout de même être soumise à des contrôles de politique à l’exécution.

Ce que les preuves sur GhostJacking ne démontrent pas encore

La démonstration révèle une catégorie d’attaque crédible, mais elle ne prouve ni une exploitation criminelle généralisée ni une défaillance universelle des agents.

Les chiffres les plus élevés rapportés proviennent de Tenet Security, qui vend également des protections pour les systèmes agentiques. Cette position commerciale n’invalide pas les résultats, mais rend une réplication indépendante particulièrement importante.

Le chiffre de 2 388 organisations décrit des conditions d’exposition découvertes. Il ne signifie pas que des attaquants ont compromis avec succès chaque organisation ni que chacune reliait activement des données Sentry à un agent doté de pouvoirs étendus.

De même, plus de 100 actions d’agent observées provenaient de recherches contrôlées. Le résultat démontre la faisabilité et l’ampleur dans le cadre du test rapporté, et non un taux de compromission mesuré à l’échelle de l’industrie logicielle.

Les configurations de produits varient également. Certains agents exigent une approbation avant les commandes shell, tandis que d’autres fonctionnent dans des conteneurs ou des espaces de travail cloud restreints.

Différents modèles peuvent interpréter la même charge utile différemment. Leur comportement peut aussi changer après des mises à jour, de nouveaux prompts système ou une modification du formatage des réponses d’outils.

La surface d’attaque dépend des permissions. Un agent disposant d’un accès en lecture seule dans un dépôt isolé présente moins de risques qu’un agent détenant des clés cloud et un accès au terminal sans restriction.

Ces différences rendent trompeur un taux de défaillance unique en titre. Les équipes de sécurité ont besoin de tests fondés sur leurs modèles, outils, identifiants et règles d’approbation réels.

Le nom « GhostJacking » peut également prêter à confusion. Les documents publiés par Tenet utilisent principalement « Agentjacking » pour désigner la technique d’erreur empoisonnée.

GhostJacking est mieux considéré comme une étiquette descriptive pour une prise de contrôle invisible d’agent, et pas nécessairement comme une catégorie de vulnérabilité distincte et normalisée. Le mécanisme central demeure l’injection indirecte de prompt suivie de l’utilisation autorisée d’outils.

Il n’existe pas non plus de correctif universel de plateforme. Filtrer une charge utile connue peut stopper une démonstration sans résoudre le problème général instruction-données.

Bloquer les titres Markdown, les commandes de gestionnaires de paquets ou des expressions précises invite les attaquants à reformater la même intention. Les évaluations adaptatives montrent à maintes reprises pourquoi les défenses fondées uniquement sur des signatures vieillissent rapidement.

À l’inverse, affirmer que le problème est entièrement impossible à résoudre surestimerait les preuves. Un meilleur entraînement des modèles, l’étiquetage des données, l’isolation des outils et l’application des politiques peuvent réduire les risques.

L’objectif réaliste n’est pas une détection parfaite au sein du modèle. Il consiste à empêcher qu’une interprétation erronée ne devienne une exécution sans restriction.

Les organisations devraient commencer par un inventaire. Les équipes ne peuvent pas gouverner les agents dont elles ignorent l’existence, y compris les outils locaux de développement et les intégrations expérimentales.

Chaque agent doit avoir un propriétaire identifié et une finalité documentée. Les équipes de sécurité doivent consigner ses modèles, outils, sources de données, identifiants, environnements d’exécution et chemins de délégation.

Les contenus influencés de l’extérieur nécessitent une classification explicite. Les journaux, tickets, commentaires de dépôts, e-mails et pages web doivent être transmis à l’agent comme des données non fiables.

Les permissions des outils doivent rester indépendantes de la classification du contenu. Une source non fiable ne doit jamais obtenir d’autorité simplement parce qu’un connecteur de confiance l’a récupérée.

Les équipes doivent ensuite tester des chaînes d’attaque réalistes. Les exercices de red teaming doivent inclure une télémétrie empoisonnée, des tickets manipulés, des pages web hostiles, des descriptions d’outils compromises et des textes de remédiation trompeurs.

Les tests doivent mesurer les résultats, et pas seulement vérifier si le modèle répète une phrase malveillante. La question cruciale est de savoir si l’agent demande ou accomplit une action non autorisée.

Ce que les lecteurs de Google News devraient surveiller ensuite

La prochaine étape sera déterminée par les contrôles à l’exécution, les normes d’identité et les preuves issues de déploiements réels.

Le premier signal sera la réplication indépendante. Les chercheurs devraient tester la chaîne de télémétrie empoisonnée sur les versions actuelles des agents de programmation, les modes d’approbation, les sandboxes et les politiques d’entreprise.

Une réplication confirmant des taux d’exécution élevés renforcerait l’argument en faveur d’une application obligatoire des règles à l’exécution. Des taux plus faibles dans des configurations renforcées permettraient d’identifier les contrôles qui fonctionnent déjà.

Le deuxième signal est la séparation, au niveau des produits, entre les données récupérées et les instructions exécutables. Les protocoles d’outils ont besoin de moyens structurés pour décrire la provenance, le niveau de confiance et l’usage autorisé.

Un modèle devrait savoir qu’un texte provient d’un champ d’événement non authentifié. Plus important encore, la couche d’exécution devrait refuser à ce texte l’autorité de demander une commande.

Surveillez si les plateformes d’agents associent une provenance vérifiable aux réponses des outils et la préservent tout au long d’un raisonnement en plusieurs étapes. De simples étiquettes d’avertissement offriront une valeur limitée sans application des règles.

Le troisième signal concerne une infrastructure d’identité conçue pour la délégation. Les entreprises ont besoin d’identifiants d’agent de courte durée, de portées liées aux tâches, d’inventaires en temps réel et de relations parent-enfant auditables.

Les progrès deviendront visibles lorsque les systèmes d’identité pourront répondre à une question précise : quel humain a autorisé cet agent, pour quel objectif et dans quelles limites ?

Ces signaux comptent au-delà de la programmation. Les agents de support client lisent des tickets, les agents financiers traitent des documents et les agents de sécurité enquêtent sur des alertes.

Tout flux de travail combinant du contenu non fiable et des outils privilégiés présente le même risque structurel. Le canal de diffusion précis changera, mais le problème d’autorité demeurera.

L’attention de Google News donne à GhostJacking un nom mémorable. La leçon durable est moins spectaculaire, mais plus importante : l’authentification seule ne peut pas établir une intention fiable.

Les équipes de sécurité devraient désormais cartographier chaque endroit où un agent lit du contenu influencé de l’extérieur avant d’agir. Commencez par les journaux, tickets, e-mails, dépôts et outils web.

Identifiez ensuite les actions capables de modifier des données, d’exécuter du code, d’exposer des secrets ou de contacter des systèmes externes. Placez des contrôles de politique indépendants entre ces entrées et ces résultats.

N’attendez pas la preuve d’une campagne d’exploitation massive. Utilisez l’attaque rapportée comme un avertissement contrôlé et vérifiez si vos agents peuvent la reproduire.

Si un agent ne peut pas expliquer qui a délégué son autorité, quelle source a influencé sa décision et pourquoi un appel d’outil a été autorisé, il n’est pas pleinement gouverné.