Agentjacking : de faux bugs Sentry détournent les agents de code via MCP

De quoi s’agit-il ?

Le 9 juin 2026, le Threat Labs de Tenet Security a publié une recherche décrivant l’« agentjacking » : une manière de détourner les agents de code IA en plantant une fausse remontée d’erreur dans un service auquel l’agent fait confiance. La Cloud Security Alliance a publié une note corroborante le 12 juin 2026. L’attaque enchaîne deux choix de conception raisonnables pris isolément — l’ingestion d’événements ouverte et non authentifiée de Sentry, et la confiance implicite qu’un agent de code accorde à la sortie d’un outil exposé via le Model Context Protocol (MCP) — pour relier « n’importe qui sur Internet » à « code arbitraire sur la machine d’un développeur ». Tenet rapporte un taux de réussite de 85 % contre Claude Code, Cursor et Codex, et a identifié au moins 2 388 organisations dont les identifiants sont injectables, dont 71 dans le top un million Tranco. Cet article ne rapporte que les résultats publiés et les défenses ; il ne contient ni payload ni mode opératoire.

Comment ça marche

Sentry est une plateforme de suivi d’erreurs très répandue. Pour recevoir les rapports de crash des navigateurs et applications mobiles, elle émet un DSN — un identifiant public en écriture seule que Sentry documente délibérément comme pouvant être intégré au JavaScript côté client. Par conception, le point d’ingestion n’est pas authentifié : quiconque détient un DSN peut POSTer un événement, qui atterrit dans la file d’attente du projet à côté des vrais crashs.

L’attaque exploite cette propriété. Un attaquant découvre un DSN (présent dans le code source des pages, des dépôts GitHub publics ou des index de scan), puis POSTe un événement façonné dont les champs sont formatés en markdown — une fausse section ## Resolution qui, lorsque le serveur MCP de Sentry la renvoie, s’affiche à l’identique des gabarits de diagnostic de Sentry. Lorsqu’un développeur demande ensuite à son agent de « corriger les erreurs Sentry non résolues », l’agent interroge Sentry via MCP, reçoit l’événement injecté et ne peut distinguer le texte de l’attaquant d’une vraie erreur applicative. Il suit l’instruction plantée — exécutant une commande du type npx [REDACTED-PACKAGE] --diagnose — avec les privilèges du développeur lui-même. Le paquet de démonstration de Tenet était inoffensif et s’identifiait comme un scan de sécurité ; un paquet réel exfiltrerait les variables d’environnement, clés AWS, jetons GitHub/GitLab, identifiants npm et Docker, et jetons Kubernetes.

La faille de fond est celle que l’injection indirecte met en lumière depuis des années : un modèle reçoit données et instructions dans le même flux de jetons et n’a aucun moyen natif de les distinguer. Tenet note que le payload s’est exécuté même lorsque les agents étaient explicitement instruits, via prompts système et skills, d’ignorer les données non fiables — ce n’est donc pas un problème que l’on corrige côté prompt.

Pourquoi c’est important

La nouveauté ici n’est pas la primitive d’exploitation mais l’échelle et l’angle mort. L’attaque a contourné EDR, WAF, IAM, VPN et pare-feu dans les configurations testées, parce que chaque étape est autorisée : un processus de confiance (l’agent) exécute une commande de gestionnaire de paquets normale avec les identifiants du développeur. Aucun binaire déposé, aucune politique violée, aucun seuil d’anomalie franchi. Tenet appelle cela l’« Authorized Intent Chain », et les contrôles classiques sont conçus pour détecter les comportements non autorisés — dont il n’y en a aucun.

Le point le plus important est la généralisation. Sentry n’est pas spécialement défaillant — c’est un exemple. Toute source connectée via MCP qui expose du contenu contrôlable de l’extérieur — gestionnaires de tickets, files de support, commentaires de revue de code, agrégateurs de logs — relève de la même classe d’injection. Auditer les binaires de vos serveurs MCP sans examiner les données qu’ils exposent ne couvre qu’une partie de la surface. Unit 42 et Elastic ont documenté des vecteurs MCP voisins (abus du sampling, invocation d’outil furtive, injection de commande dans une large part des serveurs testés) en 2025-2026 ; l’agentjacking en est la confirmation empirique.

Défenses

Exigez une confirmation humaine avant exécution. Désactivez les modes autonomes (auto-run) pour tout agent connecté à un serveur MCP exposant du contenu externe, afin que les installations de paquets et les commandes shell nécessitent une approbation explicite. Associez-y une sensibilisation des développeurs, les événements injectés étant conçus pour exploiter la lassitude face aux confirmations.

Traitez les données MCP comme des entrées non fiables. Inventoriez les serveurs MCP auxquels vos agents se connectent et ceux qui renvoient des données influençables de l’extérieur. Si l’intégration MCP de Sentry n’est pas opérationnellement nécessaire, désactivez-la ; sinon, contraignez ce que l’agent peut faire de sa sortie.

Réduisez le rayon d’exposition des secrets. Faites tourner les agents dans des environnements isolés à moindre privilège, avec accès fichiers restreint, visibilité limitée des variables d’environnement et sortie réseau contrainte — en bloquant explicitement les points de métadonnées cloud. Remplacez les jetons à longue durée de vie dans les environnements de développement par des secrets éphémères et à portée limitée.

Coupez le point d’entrée. Auditez l’exposition des DSN ; faites tourner les DSN trouvés dans les bundles publics, dépôts ou index de scan ; et envisagez de relayer le reporting côté client par un relais serveur afin que le DSN n’apparaisse jamais dans le code navigateur.

Gouvernez et red-teamez. Appliquez à l’autorisation des serveurs MCP la rigueur d’une revue de dépendances, et ajoutez les scénarios de tool poisoning et d’injection délivrée via MCP à votre red teaming agentique — pas seulement les cas de binaire de serveur compromis.

État

Il s’agit d’une recherche publiée à visée défensive, non d’un CVE produit. Tenet a fait sa divulgation à Sentry le 3 juin 2026 ; Sentry a accusé réception le jour même mais a refusé une correction à la racine, qualifiant la classe de « techniquement indéfendable » au niveau de la plateforme, et a déployé à la place un filtre de contenu contre la chaîne de payload spécifique. Le comportement a été validé contre Claude Code, Cursor et Codex ; tous les tests n’ont utilisé que les API d’ingestion publiques de Sentry, les payloads s’identifiaient comme des scans Tenet, et les données capturées ont été caviardées à la source puis supprimées. Le propriétaire de la plateforme jugeant les correctifs à la source infaisables, le point de contrôle pratique est le runtime de l’agent — l’instant où il décide d’agir. Dates de publication des sources : Tenet Security, 9 juin 2026 ; CSA Labs, 12 juin 2026 ; couverture The Hacker News, juin 2026.

Cet article couvre une recherche de sécurité publiée à visée défensive. Si vos développeurs font tourner des agents de code reliés à des intégrations MCP, traitez chaque source de données influençable de l’extérieur comme un vecteur d’injection potentiel et exigez une approbation humaine avant toute exécution de commande par l’agent.