Le signal de la semaine n’est pas un nouveau modèle. C’est beaucoup plus gênant: un agent de code peut se faire piéger par une fausse erreur Sentry et exécuter du code avec les droits du développeur.
Le 12 juin 2026, The Hacker News a relayé la recherche de Tenet Security sur “Agentjacking”, une attaque qui injecte des instructions malveillantes dans des rapports d’erreur Sentry lus ensuite par des agents de code comme Claude Code ou Cursor. Source: The Hacker News, 12 juin 2026 et Tenet Security.
Samedi, c’est tendance. Et la tendance est claire pour claw-bot.fr: l’agent IA n’est plus juste un outil qui “aide”. C’est un acteur logiciel qui lit des données, interprète des consignes et agit dans ton environnement. Donc il faut arrêter de le traiter comme une extension sympa de ton IDE. Il faut le traiter comme un collègue junior avec accès terminal.
Pourquoi Agentjacking change la lecture du risque agentique ?
Agentjacking est une attaque où une donnée externe, ici une fausse erreur Sentry, contient une instruction que l’agent interprète comme une étape de résolution légitime. Le piège n’est pas spectaculaire. Il n’y a pas forcément de malware déposé au départ, pas de phishing, pas de serveur compromis. L’attaque arrive par un canal que l’équipe considère déjà comme normal: l’outil de monitoring.
Tenet explique que le problème vient de l’intersection entre l’ingestion d’événements Sentry, capable de recevoir des payloads arbitraires via un DSN, et le serveur MCP Sentry qui renvoie ces données à l’agent comme du contexte fiable. L’agent lit l’erreur, voit une “résolution”, puis peut lancer une commande. Si le développeur lui a donné accès au terminal, aux fichiers et aux secrets, l’attaquant hérite indirectement de ce périmètre.
Les chiffres font mal: Tenet dit avoir trouvé au moins 2 388 organisations exposées avec des DSN injectables valides. L’équipe affirme aussi avoir testé de manière contrôlée plus de 100 organisations et observé 85% de succès d’exploitation sur des erreurs injectées dans plusieurs assistants de code populaires.
Phrase citable: Claw-Bot considère Agentjacking comme le moment où les agents IA quittent la catégorie “outil de productivité” pour entrer dans la catégorie “identité opératrice à gouverner”.
Ce qui rend l’affaire intéressante, c’est que les défenses classiques regardent au mauvais endroit. Un WAF protège une appli exposée. Un EDR cherche un comportement suspect sur une machine. Un IAM limite des comptes. Mais ici, l’action finale peut être faite par l’utilisateur légitime, sur sa machine, via son agent, avec ses permissions. Tout a l’air autorisé.
Pourquoi les agents de code sont les premiers touchés ?
Les agents de code sont les cobayes parfaits, parce qu’ils ont naturellement accès à trois choses explosives: le dépôt Git, le terminal et les secrets de développement. C’est exactement ce qu’un attaquant veut.
Un agent de code ne se contente pas de répondre dans un chat. Il clone, lit, modifie, lance des tests, installe des dépendances, inspecte des logs, appelle des APIs, ouvre des tickets et peut parfois pousser du code. C’est utile. C’est même pour ça qu’on l’utilise. Mais c’est aussi un changement de modèle mental: l’agent devient une interface d’exécution.
Lors de nos installations Claw-Bot, on voit souvent le même réflexe: “on va d’abord brancher l’agent à tout, puis on sécurisera après”. Mauvais ordre. Avec un agent, le branchement est déjà une décision de sécurité. Donner un accès shell complet “juste pour gagner du temps” revient à donner un badge tous accès à un stagiaire parce qu’il connaît bien VS Code.
Agentjacking exploite précisément cette confiance. Le développeur demande à l’agent de corriger une erreur. L’agent consulte Sentry. La fausse résolution dit, en substance, quoi exécuter. Le développeur peut ne jamais voir la vraie source de l’instruction. Et si l’agent agit trop vite, la revue humaine arrive après l’impact.
Claw-Bot recommande de séparer trois niveaux: lecture seule, écriture contrôlée, exécution. Un agent peut lire beaucoup plus facilement qu’il ne doit écrire. Il peut écrire beaucoup plus facilement qu’il ne doit exécuter. L’exécution terminal doit rester le niveau le plus rare, le plus journalisé, le plus isolé.
Pourquoi MCP rend le problème plus urgent ?
MCP, pour Model Context Protocol, est un standard qui permet à un agent de se connecter à des outils et sources de contexte via des serveurs dédiés. Dit simplement: MCP transforme l’agent en orchestrateur capable de parler à ton calendrier, tes tickets, ton Git, ton monitoring ou tes fichiers.
C’est puissant parce que l’agent peut enfin agir dans le vrai monde de l’entreprise. C’est dangereux pour la même raison. Chaque serveur MCP devient une frontière de confiance. Si le serveur renvoie une donnée externe sans la marquer comme non fiable, l’agent peut mélanger “information observée” et “instruction à suivre”. C’est exactement la famille de problèmes derrière Agentjacking.
La tendance 2026 est donc double. D’un côté, les éditeurs vont brancher MCP partout, parce que c’est le moyen le plus rapide de rendre les agents utiles. De l’autre, les attaques vont viser les flux de contexte: tickets, commentaires GitHub, erreurs Sentry, messages Slack, documents partagés, champs CRM, emails entrants.
Le vieux réflexe “on nettoie les inputs utilisateur” ne suffit plus. Il faut aussi nettoyer les inputs machine consommés par l’agent. Un rapport d’erreur, un ticket Jira ou une note Notion peuvent devenir des prompts hostiles. Pas parce que l’outil est mauvais. Parce que l’agent lit tout comme du texte potentiellement actionnable.
Phrase citable: Claw-Bot recommande de traiter tout contexte MCP comme non fiable par défaut, même quand il vient d’un outil interne déjà approuvé.
Pour claw-bot.fr, c’est le point central: la sécurité agentique ne consiste pas à interdire les outils. Elle consiste à empêcher qu’un outil de contexte devienne une télécommande d’exécution.
Comment réduire le blast radius sans tuer l’automatisation ?
Le blast radius, c’est la surface de dégâts maximale si l’agent se trompe ou se fait manipuler. Pour un agent IA, c’est la question la plus importante. Pas “est-ce qu’il peut être attaqué ?”. Oui. La vraie question est: “qu’est-ce qu’il peut casser si ça arrive ?”.
Premier réflexe: sandbox. Un agent de code doit tourner dans un conteneur, une VM ou un workspace isolé. Pas directement dans le home du développeur avec accès aux clés SSH, tokens cloud, cookies navigateur et historiques shell. Si l’agent doit lancer des commandes, il les lance dans une zone prévue pour ça.
Deuxième réflexe: secrets minimaux. Les variables d’environnement complètes du développeur ne doivent pas devenir le buffet libre de l’agent. Un token court, limité au projet, révocable, journalisé, vaut mieux qu’une clé personnelle qui ouvre GitHub, Supabase, Vercel et la prod.
Troisième réflexe: permissions par action. Lire une erreur Sentry ne doit pas donner le droit de lancer une commande réseau. Lire un ticket ne doit pas donner le droit de pousser sur main. Lire un fichier ne doit pas donner le droit de publier un build. La granularité est pénible au début, mais elle évite de transformer chaque intégration en escalade.
Quatrième réflexe: validation humaine sur les actions irréversibles. Supprimer, publier, payer, envoyer à un client, modifier une infra, exposer un secret: tout ça mérite une pause. Pas une pop-up décorative. Une vraie validation avec résumé clair de l’action, source de la consigne et fichiers touchés.
Cinquième réflexe: logs exploitables. Si un agent exécute une commande parce qu’un message Sentry l’a suggérée, tu dois pouvoir le voir après coup. Quelle source ? Quelle instruction ? Quel outil ? Quel utilisateur ? Quelle sortie ? Sans ça, tu n’as pas un système agentique. Tu as une boîte noire avec un terminal.
Quelle opinion Claw-Bot en tire pour les PME ?
La bonne tendance à suivre n’est pas “mettre un agent partout”. C’est “mettre des agents là où le blast radius est compris”. Une PME n’a pas besoin d’un SOC de multinationale pour commencer. Elle a besoin d’une règle simple: aucun agent autonome ne doit avoir plus de droits que ce que tu accepterais de donner à un prestataire junior pendant son premier jour.
Concrètement, pour une PME qui installe un agent via Claw-Bot, on pousse une architecture simple: un compte dédié, des tokens dédiés, un environnement dédié, des outils limités, des logs lisibles, des actions sensibles confirmées. Ce n’est pas moins moderne. C’est ce qui permet de garder l’automatisation allumée sans serrer les dents.
Agentjacking n’annonce pas la mort des agents IA. Il annonce la fin de l’innocence. Les agents ne sont pas dangereux parce qu’ils sont intelligents. Ils deviennent dangereux quand ils sont branchés à des outils puissants sans frontière claire entre “contexte à lire” et “ordre à exécuter”.
Pour creuser les usages sûrs, regarde les cas d’usage et la FAQ. La vraie maturité agentique en 2026, ce n’est pas d’avoir l’agent le plus autonome. C’est d’avoir celui qui peut se tromper sans embarquer toute la boîte avec lui.