Vous avez demandé à votre agent de corriger les erreurs. L'une d'elles avait été écrite par un attaquant.

Un développeur ouvre son agent de code IA et saisit la demande la plus ordinaire qui soit : « regarde les erreurs Sentry non résolues et corrige-les. » L'agent récupère la liste des erreurs via son connecteur Sentry, lit le premier incident, suit les étapes de remédiation écrites noir sur blanc dans le rapport, et les exécute. Une demi-minute plus tard, il a exécuté le code d'un attaquant sur la machine du développeur, avec les pleins privilèges de ce dernier, et personne n'a rien fait de travers.

C'est l'Agentjacking, révélé ce mois-ci par Tenet Security, et il a fonctionné 85 % du temps contre les trois agents de code les plus populaires du marché : Claude Code, Cursor et Codex [1][2].

Ce qui s'est réellement passé

D'abord, ce qu'est Sentry : l'un des services de surveillance d'erreurs les plus utilisés dans le logiciel. Quand votre application génère une erreur ou plante, Sentry la capture et classe le rapport que vos développeurs trient — il se trouve au sein d'une part énorme des applications que vous utilisez chaque jour. Pour lui envoyer ces rapports, chaque application intègre une DSN : une clé côté client qui figure volontairement dans le code source de votre site, pour que le navigateur puisse renvoyer les erreurs. N'importe qui peut la lire. Et n'importe qui la détenant peut envoyer un événement d'erreur dans votre projet Sentry par requête POST.

C'est là toute la clé de l'attaque. Tenet a fabriqué un faux événement d'erreur dont le champ de message était formaté pour ressembler trait pour trait aux propres conseils de remédiation de Sentry : un markdown soigné, une « correction recommandée », une commande à exécuter. Ils l'ont soumis avec la DSN publique. Puis ils ont attendu le geste le plus naturel d'un développeur — demander à l'agent de vider la file d'erreurs.

L'agent interroge Sentry via son connecteur MCP. Le connecteur lui renvoie l'erreur comme sortie système de confiance. L'agent ne peut pas distinguer un vrai rapport Sentry d'un rapport falsifié ; ils ont exactement la même forme, octet par octet. Il fait donc ce qu'on lui demande et exécute la « correction », généralement un appel npx vers un paquet de l'attaquant. À partir de là, il a tout ce que le développeur a : variables d'environnement, identifiants Git, URL de dépôts privés, clés cloud dans ~/.aws/.

Tenet a trouvé 2 388 organisations avec des DSN injectables, des développeurs indépendants jusqu'au Fortune 100. Dans ses tests contrôlés, des agents ont réellement exécuté les instructions injectées dans de vraies entreprises — y compris, selon Tenet, une entreprise technologique du Fortune 100 valorisée 250 milliards de dollars dont l'agent IA a lu le faux rapport de bug et exécuté le code de Tenet sur deux de ses machines d'entreprise [1][3]. Révélée à Sentry le 3 juin, l'attaque a été reconnue par l'entreprise le jour même, qui a refusé de la corriger à la racine, jugeant le problème « techniquement non défendable ». Elle a livré un filtre de contenu bloquant une chaîne de charge utile précise [4].

Il ne s'agit pas d'une négligence de Sentry

Voici la partie inconfortable : rien dans cette chaîne n'était un bug. La DSN est censée être publique. Le serveur MCP est censé renvoyer vos données d'erreur. L'agent est censé agir sur les diagnostics que vous lui avez demandé de corriger. Chaque étape était autorisée, et c'est précisément pour cela qu'aucun pare-feu, aucun EDR, aucun prompt système ne l'a détectée.

La faille est structurelle, et elle n'est pas propre à Sentry. Tout outil qui fournit à un agent un texte qu'un tiers peut influencer — un traqueur d'erreurs, une file d'incidents, une page web collectée, un document partagé — est un canal d'injection, et l'agent traite l'ensemble comme un flux d'instructions indifférencié. L'injection de prompt, deux ans après l'ère des agents, reste non résolue : on ne peut pas empêcher de manière fiable qu'un texte hostile pénètre le raisonnement d'un modèle. Partez du principe que vous n'y parviendrez pas.

L'injection n'est pas la catastrophe

Voici la partie sur laquelle il vaut la peine de s'arrêter. Si l'Agentjacking est une alerte maximale, ce n'est pas parce que l'agent s'est laissé tromper. C'est ce à quoi l'agent trompé pouvait accéder. Il a fonctionné avec l'accès permanent du développeur dans toute son étendue : chaque clé dans l'environnement, chaque fichier d'identifiants sur le disque, tout le trousseau de clés à une commande de distance.

Ce rayon d'impact n'est pas une loi de la nature. C'est une configuration. L'agent avait un accès permanent à tout cela parce que c'est ainsi que les identifiants sont stockés aujourd'hui — ambiants, sur la machine, lisibles par tout ce qui s'y exécute. Retirez cela, et le même détournement se heurte à un mur.

Conçu pour cela, délibérément

Un identifiant Clavitor ne se trouve jamais dans l'environnement où l'agent s'exécute. Il n'y a pas de ~/.aws/credentials à lire, pas de clé API dans une variable d'environnement à exfiltrer, car la valeur secrète n'atterrit jamais là où le code s'exécute — l'agent obtient le résultat de l'utilisation d'un identifiant, pas l'identifiant lui-même. Il ne peut atteindre que la seule ressource pour laquelle il a été nommé, et ne peut donc pas énumérer le coffre pour découvrir ce qui s'y trouve d'autre. Et l'autorisation est limitée dans son périmètre et révocable : une session qui se met à se comporter comme un attaquant peut être coupée en pleine action.

Voici la limite, en toute honnêteté : cela ne stoppe pas l'injection, et n'empêche pas un agent détourné d'exécuter une commande. L'injection de prompt est non résolue et nous ne prétendons pas la résoudre. Ce qui change, c'est la rentabilité. Le code de l'attaquant s'exécute toujours — et trouve un environnement où rien ne traîne qui vaille la peine d'être volé. Le détournement réussit et le casse échoue.

Nous avons consigné les règles qu'un système d'identifiants doit respecter une fois que l'agent lui-même peut se retourner contre vous, en commençant par le secret qui ne vit jamais là où le code s'exécute, et un agent qui n'atteint que ce pour quoi il a été nommé. Mesurez le vôtre à cette aune : clavitor.ai/rules.

La leçon n'est pas « corrigez Sentry »

Sentry ne peut pas corriger cela, et l'a dit. Et le prochain outil empoisonné ne sera pas Sentry. Tant que vos agents transportent des identifiants ambiants et permanents, chaque outil de confiance qu'ils lisent est une arme chargée, et l'injection de prompt est la détente que vous ne pouvez pas verrouiller.

Vous n'empêcherez pas le texte malveillant d'entrer. Alors cessez de laisser les identifiants à portée de l'agent qui le lit.

Clavitor (@clavitorai) est le coffre d'identifiants conçu pour les agents IA, et contre eux. clavitor.ai

Sources

[1] Tenet Security — « Agentjacking: hijacking coding agents with fake Sentry errors » (85 % de réussite ; 2 388 organisations ; mécanisme) : https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/

[2] The Hacker News — « Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code » : https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

[3] The New Stack — « A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex » : https://thenewstack.io/agentjacking-sentry-mcp-attack/

[4] Infosecurity Magazine — « New 'Agentjacking' Attacks Could Hijack AI Coding Agents » (la réponse de Sentry) : https://www.infosecurity-magazine.com/news/agentjacking-attacks-hijack-ai/