“AgentJacking : comment une fausse erreur Sentry peut détourner Claude Code, Cursor et Codex — et ce que cela implique pour l’écosystème MCP”

Introduction : La surface d’attaque que personne n’avait vue venir

Les agents de codage IA ont été adoptés à une vitesse extraordinaire. Claude Code a franchi le cap du million d’utilisateurs actifs quotidiens en quelques semaines seulement après son lancement. Cursor est passé d’un simple fork de VS Code à l’éditeur par défaut de toute une génération de développeurs natifs de l’IA. Codex CLI est devenu la réponse d’OpenAI au paradigme de l’agent dans le terminal. Collectivement, ces outils tournent désormais quotidiennement sur des centaines de milliers de machines de développeurs — avec un accès au système de fichiers, des droits d’exécution shell et (via MCP) des connexions à des services externes comme les bases de données, les API et les plateformes de surveillance.

L’hypothèse de sécurité était simple : ces agents s’exécutent localement, derrière la pile de sécurité existante du développeur — EDR, pare-feu, VPN, WAF, IAM. Si rien de malveillant n’entre dans la machine, rien de malveillant ne se produit.

Tenet Security vient de prouver que cette hypothèse est erronée.

(Source : The Hacker News — AgentJacking Attack Tricks AI Coding Agents Into Running Malicious Code, juin 2026)

Comment fonctionne AgentJacking : La chaîne d’attaque

L’attaque est d’une simplicité élégante. Elle nécessite deux ingrédients :

Une clé DSN Sentry publique. Ces clés sont régulièrement exposées dans le JavaScript côté client, les dépôts publics et la documentation. Les chercheurs ont trouvé 2 388 organisations avec des clés DSN accessibles publiquement.
Une seule requête HTTP POST vers l’API d’ingestion d’événements de Sentry. Aucun exploit, aucune vulnérabilité dans le code de Sentry — juste l’API normale faisant exactement ce pour quoi elle a été conçue : accepter des événements d’erreur.

Voici la chaîne complète, étape par étape :

Étape 1 — Reconnaissance. L’attaquant trouve la clé DSN Sentry d’une organisation cible. C’est souvent un exercice de 30 secondes : chercher sur GitHub, inspecter le bundle d’une application web, ou interroger Shodan pour trouver des endpoints Sentry.

Étape 2 — Confection de la charge utile. L’attaquant construit un faux événement d’erreur Sentry. La charge utile est structurellement identique à une erreur légitime — même enveloppe JSON, mêmes champs. Mais à l’intérieur de la description de l’erreur, une section « Résolution » rendue en markdown contient une instruction que l’attaquant souhaite voir exécuter par l’agent, généralement une commande npx.

Étape 3 — Injection. L’attaquant envoie l’événement via POST https://sentry.io/api/{org_id}/store/. Aucune authentification au-delà de la clé DSN n’est requise — c’est ainsi que l’API publique de Sentry est conçue.

Étape 4 — Le développeur déclenche l’agent. Le développeur, voyant une erreur Sentry dans son tableau de bord (ou ayant configuré son agent pour surveiller Sentry), demande à Claude Code, Cursor ou Codex : « Corrige les erreurs Sentry. »

Étape 5 — MCP transmet la charge utile à l’agent. Le serveur MCP Sentry récupère l’événement d’erreur et le présente à l’agent comme un contexte structuré. Le markdown est rendu — titres, blocs de code, la section de résolution fabriquée — tout est impossible à distinguer d’une véritable erreur Sentry.

Étape 6 — L’agent exécute le code de l’attaquant. L’agent lit les instructions déguisées en markdown, les interprète comme la correction, et exécute la commande npx de l’attaquant sur la machine même du développeur, avec tous les privilèges du développeur. La commande pourrait exfiltrer des clés API, installer un shell inversé, modifier le code source, ou pivoter vers l’infrastructure interne.

(Source : The New Stack — AgentJacking: Sentry MCP Attack, juin 2026)

Pourquoi la sécurité traditionnelle ne la détecte pas

L’attaque est invisible pour chaque couche de la pile de sécurité moderne :

EDR voit un développeur exécutant npx — une commande légitime utilisée des milliers de fois par jour
WAF voit une requête HTTP POST normale vers l’API de Sentry — ce que font les clients Sentry
Pare-feu/VPN voient du trafic sortant vers sentry.io — un domaine autorisé dans la plupart des organisations
IAM n’est pas impliqué — la clé DSN est un jeton public, pas un identifiant utilisateur

Comme l’a déclaré Tenet Security dans sa divulgation : « L’attaque contourne l’EDR, le WAF, l’IAM, le VPN, Cloudflare et les pare-feux — car il n’y a rien de malveillant à détecter. »

(Source : The Hacker News — AgentJacking, juin 2026)

Les chiffres : 85 % de réussite, 2 388 organisations exposées

Les recherches de Tenet Security, menées par Ron Bobrov, Barak Sternberg et Nevo Poran, n’étaient pas théoriques. Ils ont testé l’attaque contre plus de 100 organisations consentantes dans des environnements contrôlés.

Les résultats :

Métrique	Valeur
Taux de réussite (l’agent exécute le code de l’attaquant)	85 %
Organisations avec des clés DSN Sentry publiques	2 388
Agents de codage IA concernés	Claude Code, Cursor, Codex CLI
Complexité de l’attaque	Une seule requête HTTP POST
Détection par EDR/WAF/Pare-feu	0 %
Raison de l’échec dans 15 % des cas	L’agent a demandé une confirmation avant d’exécuter une commande `npx` inconnue

Les 15 % qui ont résisté ne l’ont pas fait grâce à un contrôle de sécurité — l’agent a simplement demandé « êtes-vous sûr de vouloir exécuter cette commande ? » et le développeur, s’il était attentif, a refusé. Mais même cette défense est mince : les agents sont de plus en plus configurés pour fonctionner de manière autonome avec un minimum d’invites de confirmation afin d’améliorer la vélocité des développeurs. L’orientation produit globale des outils de codage IA va vers moins de confirmations, pas plus.

(Source : Infosecurity Magazine — New AgentJacking Attacks Could Hijack AI Coding Agents, juin 2026)

La réponse de Sentry : « Techniquement indéfendable »

L’élément le plus controversé de la divulgation d’AgentJacking est la réponse de Sentry.

Sentry a reconnu le problème le 3 juin 2026 — neuf jours avant la divulgation publique — mais a refusé de mettre en œuvre une correction à la racine du problème. Selon l’évaluation de Sentry, filtrer le contenu malveillant des événements au niveau de la plateforme est « techniquement indéfendable » — un attaquant peut toujours trouver une charge utile qui échappe à un filtre de contenu. Sentry a activé un filtre global bloquant une chaîne de charge utile spécifique, une mesure provisoire traitant le symptôme plutôt que la cause.

(Source : CSA Research Note — AgentJacking: MCP Injection Hijacks AI Coding Agents, juin 2026)

La position de Sentry est défendable d’un point de vue produit étroit : le travail de Sentry est d’ingérer des erreurs, pas de contrôler leur contenu. La plateforme ne peut pas faire la distinction entre une véritable erreur Sentry contenant des instructions npx et une erreur malveillante — les deux sont des charges utiles API valides. Le filtrage de contenu à l’échelle de l’ingestion est une bataille perdue d’avance.

Mais d’un point de vue plus large de l’écosystème, cette réponse met en évidence une lacune structurelle : les serveurs MCP sont des limites de confiance, mais personne ne les traite comme telles. Le protocole MCP suppose que les données renvoyées par un serveur sont dignes de confiance. Lorsqu’un serveur MCP Sentry transmet un événement d’erreur à Claude Code, l’agent n’a aucun moyen de distinguer entre « cet événement a été généré par un vrai crash » et « cet événement a été injecté par un attaquant via la même API exacte ».

The Next Web a capturé la tension centrale : « Cette impasse est la véritable histoire. Le défaut ne réside pas uniquement dans Sentry. »

(Source : The Next Web — AgentJacking: A Fake Bug Report Hijacks AI Coding Agents, juin 2026)

Le problème de confiance du MCP : Au-delà de Sentry

AgentJacking n’est pas un problème Sentry. C’est un problème d’architecture MCP.

Le Model Context Protocol a été conçu pour l’intégration de données, pas pour la résilience face à des adversaires. Lorsqu’un agent se connecte à un serveur MCP, il fait confiance aux données que ce serveur renvoie. Le protocole ne fournit aucun mécanisme pour :

La provenance des données — « Qui a généré cet événement ? » vs. « Qui a injecté cet événement ? »
L’intégrité du contenu — « Ce rapport d’erreur a-t-il été modifié depuis sa génération ? »
La séparation des instructions — « Ce markdown décrit-il une correction, ou en ordonne-t-il une ? »

Tout serveur MCP qui ingère des données provenant d’une API publique est potentiellement vulnérable à cette classe d’attaque. Sentry est l’exemple le plus visible en raison de son omniprésence, mais le vecteur se généralise aux plateformes de surveillance (Datadog, Grafana), aux services de journalisation, aux gestionnaires de tickets (Jira, Linear), et à tout outil qui fait remonter des données générées par l’utilisateur ou semi-publiques dans la fenêtre de contexte de l’agent.

La spécification MCP, actuellement gérée par Anthropic en tant que standard ouvert, n’inclut pas encore de modèle de confiance pour les données adverses. C’est la lacune qu’AgentJacking expose — et c’est une lacune que l’écosystème s’efforce désormais de combler.

(Source : CSA Research Note — AgentJacking, juin 2026)

La réponse : Trois paris infrastructurels en une semaine

La semaine du 12 au 19 juin 2026 a vu trois réponses infrastructurelles distinctes au problème de sécurité des agents. Elles ne sont pas coordonnées, mais elles sont complémentaires.

1. Tenet Security : 6 millions de dollars pour construire le « Pare-feu pour Agents »

Le 17 juin, Tenet Security — fondée par d’anciens chercheurs de Cisco, dont l’équipe qui a découvert AgentJacking — est sortie de la clandestinité avec un tour de table d’amorçage de 6 millions de dollars. Le produit de l’entreprise est une plateforme de sécurité au niveau des agents qui se situe entre l’agent et ses sources de données, inspectant les invites et les réponses pour détecter les manipulations, les accès non autorisés et l’exfiltration de données.

Tenet décrit sa mission comme la prévention de « l’accès non autorisé, l’exfiltration de données, la manipulation d’agents et une catégorie d’attaques qu’elle appelle AgentJacking — dans lesquelles des instructions malveillantes intégrées dans des e-mails, documents, journaux, bases de données ou autres sources de données modifient le comportement d’un agent. »

(Source : citybiz — Tenet Security Emerges From Stealth With $6 Million Seed Round, juin 2026)

La thèse de l’entreprise est que la sécurité périmétrique traditionnelle — EDR, WAF, SIEM — est architecturalement incapable de protéger les agents car la surface d’attaque est constituée des données que l’agent consomme, et non du trafic réseau qu’il génère. Leur solution opère au niveau de la couche MCP, inspectant chaque élément de contexte qu’un agent reçoit avant qu’il n’influence le comportement de l’agent.

2. Agent Beacon : Télémétrie open source pour l’activité des agents

Le 22 juin, Asymptote Labs a publié Agent Beacon, la première couche de télémétrie open source spécialement conçue pour les agents IA. Agent Beacon capture et normalise l’activité des agents de codage IA locaux — Claude Code, Codex CLI, Cursor et Claude Cowork — et l’exporte via OpenTelemetry vers l’infrastructure de sécurité existante (SIEM, SOAR, lacs de données).

Agent Beacon répond à une lacune fondamentale de visibilité : les outils EDR traditionnels voient un développeur exécuter des commandes, mais ils ne peuvent pas faire la distinction entre « le développeur a tapé cette commande » et « l’agent IA du développeur a généré cette commande pour lui ». En se situant au niveau de la couche d’exécution de l’agent, Beacon fournit la piste d’audit qui rend possible l’investigation post-incident.

(Source : HelpNet Security — Agent Beacon: Open-source telemetry layer for AI agents, juin 2026)

Caractéristiques techniques clés :

Sous licence MIT — libre à déployer, auditer et étendre
Prend en charge les environnements locaux, CI et cloud — l’activité de l’agent est suivie partout où l’agent s’exécute
Export OpenTelemetry — compatible avec les piles d’observabilité existantes
Modes de rétention — configurables, de l’éphémère à la forensique à long terme

Asymptote Labs, la société derrière Agent Beacon, se positionne comme « le harnais de sécurité pour les agents IA » — une couche qui se situe entre l’agent et le système d’exploitation, régissant ce que les agents peuvent faire et enregistrant tout ce qu’ils tentent.

3. Cloudflare Temporary Accounts : Déployer sans OAuth

Le 19 juin, Cloudflare a lancé Temporary Accounts for AI Agents, une fonctionnalité qui permet aux agents IA de provisionner des comptes Cloudflare éphémères (60 minutes) sans OAuth, inscription manuelle ou intervention humaine. Les agents peuvent déployer des Workers, créer des bases de données D1, provisionner des magasins KV, et même acheter des domaines — le tout dans un compte cloisonné et limité dans le temps.

Le flag wrangler deploy --temporary, disponible dans Wrangler 4.102.0, crée un compte qui s’autodétruit automatiquement après 60 minutes. C’est la réponse de Cloudflare au problème que tout développeur d’agent IA rencontre : « Dès qu’un agent a besoin de déployer quelque chose, il se heurte de plein fouet à un mur conçu pour les humains. »

(Source : Cloudflare Blog — Temporary Cloudflare Accounts for AI Agents, juin 2026)

Bien que les Temporary Accounts ne soient pas un outil de sécurité en soi, ils représentent un modèle d’infrastructure crucial : le cloisonnement des actions des agents dans des environnements limités dans le temps et dans leur portée. Si un agent est compromis — via AgentJacking ou tout autre vecteur — le rayon d’explosion est limité à un compte de 60 minutes sans accès aux ressources de production.

Ensemble, ces trois annonces esquissent la pile de sécurité émergente pour les agents :

Couche	Problème	Solution	Fournisseur
Prévention	Données malveillantes influençant le comportement de l’agent	Inspection des invites au niveau MCP	Tenet Security
Visibilité	Absence de piste d’audit pour les actions des agents	Capture d’activité basée sur OpenTelemetry	Agent Beacon (Asymptote)
Confinement	Agent compromis avec accès illimité	Bac à sable limité dans le temps et la portée	Cloudflare Temporary Accounts

Ce que les développeurs peuvent faire dès aujourd’hui

La divulgation d’AgentJacking est un coup de semonce, pas une crise. L’attaque a été démontrée dans des environnements contrôlés, mais il n’y a aucune preuve d’exploitation active dans la nature. Cependant, les conditions structurelles qui la rendent possible ne vont pas disparaître — les agents deviennent plus autonomes, MCP devient la couche d’intégration standard, et les développeurs connectent de plus en plus de services externes à leurs agents chaque semaine.

Mesures pratiques pour les développeurs et les équipes utilisant des agents de codage IA :

Auditez vos connexions MCP. Listez chaque serveur MCP auquel vos agents sont connectés. Pour chacun, demandez-vous : ce serveur ingère-t-il des données provenant d’API publiques ? Si oui, c’est un vecteur d’injection potentiel.
Rotation des clés DSN exposées. Si votre DSN Sentry (ou jeton de surveillance équivalent) se trouve dans du JavaScript côté client, un dépôt public, ou tout emplacement accessible publiquement, faites-le tourner. Les chercheurs ont trouvé 2 388 organisations avec des clés exposées — la vôtre pourrait en faire partie.
Mettez en place une confirmation de commande pour les paquets externes. Les 15 % des tests où AgentJacking a échoué étaient des cas où l’agent demandait avant d’exécuter des commandes npx inconnues. Configurez votre agent pour exiger une confirmation explicite pour toute commande qui installe ou exécute du code provenant d’un registre externe.
Déployez une télémétrie au niveau de l’agent. Agent Beacon est sous licence MIT et disponible sur GitHub. Même un déploiement de base offre une visibilité sur les commandes que vos agents exécutent réellement.
Considérez MCP comme une limite de confiance. Jusqu’à ce que la spécification MCP inclue la gestion des données adverses, supposez que toute données arrivant via un serveur MCP pourrait être contrôlée par un attaquant. Appliquez le même scepticisme aux données MCP que celui que vous appliquez aux entrées utilisateur dans une application web.
Cloisonnez les déploiements des agents. Pour les agents qui déploient de l’infrastructure (Workers, bases de données, etc.), utilisez des jetons d’accès limités dans le temps et des rôles à portée restreinte. Le modèle des Temporary Accounts de Cloudflare est reproductible avec d’autres fournisseurs cloud via des identifiants IAM à courte durée de vie.

FAQ

Q : AgentJacking est-il exploité activement dans la nature en ce moment ?

Il n’y a aucune preuve d’exploitation active au 22 juin 2026. Les recherches ont été menées dans des environnements contrôlés avec des organisations consentantes. Cependant, l’attaque est triviale à reproduire — une seule requête HTTP POST — donc une exploitation post-divulgation est une préoccupation réaliste.

Q : Cela signifie-t-il que MCP est fondamentalement cassé ?

Non. MCP a été conçu pour l’intégration de données, pas pour la résilience face aux adversaires. Le protocole est solide pour son objectif initial. Ce qu’AgentJacking expose, c’est que MCP est utilisé comme une limite de confiance sans les propriétés de sécurité d’une telle limite. Le protocole a besoin d’un modèle de confiance — provenance des données, vérification de l’intégrité, et séparation instructions/données — qu’il ne possède pas actuellement.

Q : Claude Code est-il plus vulnérable que Cursor ou Codex ?

La vulnérabilité réside dans la couche d’intégration MCP, pas dans l’implémentation spécifique du LLM ou de l’utilisation d’outils d’un agent particulier. Les trois outils (Claude Code, Cursor, Codex CLI) ont été affectés car les trois s’intègrent au serveur MCP Sentry. Le taux de réussite de 85 % était cohérent entre les outils.

Q : Ce vecteur d’attaque peut-il être corrigé au niveau du serveur MCP ?

Partiellement. Les serveurs MCP pourraient implémenter un filtrage de contenu, une désinfection des entrées, ou une vérification de l’origine. Mais comme l’a noté Sentry, le filtrage de contenu est « techniquement indéfendable » contre un adversaire déterminé. La correction la plus robuste se situe au niveau du protocole : MCP doit séparer les « données » (les détails de l’erreur) des « instructions » (la correction suggérée) et fournir à l’agent des métadonnées de provenance qu’il peut utiliser pour prendre des décisions de confiance.

Q : Devrais-je arrêter d’utiliser les agents de codage IA ?

Non. Les données sur le retour sur investissement sont accablantes — 96 % des organisations ayant des agents en production déclarent un retour sur investissement conforme ou supérieur aux attentes (Source : GlobeNewswire — SoundHound AI Survey, 18 juin 2026). La bonne réponse n’est pas d’arrêter d’utiliser les agents, mais de les traiter comme la nouvelle surface d’attaque qu’ils sont — avec la même rigueur que vous appliquez à tout autre système de production.

"AgentJacking : comment une fausse erreur Sentry peut détourner Claude Code, Cursor et Codex — et ce que cela implique pour l'écosystème MCP"