La page web a réécrit la configuration de l'agent

Kiro est l'IDE agentique d'AWS : un agent de code qui lit le web ouvert en votre nom, récupère de la documentation et branche des outils pour vous. Comme la plupart des agents en 2026, il parle le Model Context Protocol, ou MCP : la prise qui permet à un agent de code d'appeler des outils externes et de lire leurs résultats. Kiro conserve sa liste de serveurs MCP, et la commande exacte utilisée pour démarrer chacun d'eux, dans un simple fichier à ~/.kiro/settings/mcp.json. Quand ce fichier change, Kiro le recharge et lance tout ce qu'il décrit désormais.

Cette dernière phrase est toute la vulnérabilité. Le fichier est un lanceur, et l'agent peut y écrire.

Le 21 juillet 2026, Intezer, dans une recherche menée avec Kodem Security, a montré la chaîne qui suit, et The Hacker News l'a couverte le jour même. AWS a attribué CVE-2026-10591, noté 8,8 sur 10. Des éléments antérieurs du même problème avaient été signalés par Johann Rehberger et par Cymulate. Ce qu'Intezer a ajouté, c'est la livraison.

Une page que vous lisez, pas un fichier que vous avez ouvert

Les instructions ne sont pas arrivées dans un dépôt ou une configuration à laquelle le développeur avait choisi de faire confiance. Elles sont arrivées sur une page web. Intezer les a plantées en texte blanc d'un pixel, color:#fff;font-size:1px, sur une page de documentation d'API par ailleurs ordinaire. Dans un navigateur, le paragraphe ne rend rien : un mince ruban vide qu'un humain dépasse en défilant. Pour l'agent, qui ingère le texte de la page plutôt que son image, c'est un paragraphe d'instructions parfaitement clair.

Ces instructions disaient à Kiro d'utiliser fsWrite, son propre outil d'écriture de fichiers, pour écraser ~/.kiro/settings/mcp.json avec une entrée fournie par l'attaquant. Kiro l'a fait sans demander. Son mode Autopilot par défaut a écrit le fichier de lui-même, sans aucune boîte de dialogue ni invite « autoriser cette écriture ? ». Le rechargement s'est déclenché, Kiro a lancé la commande de la nouvelle entrée, et le code de l'attaquant s'est exécuté sur l'hôte avec les privilèges du développeur : de quoi lire des identifiants, copier du code source, installer une persistance, ou se déplacer latéralement vers tout ce que la machine du développeur peut atteindre.

AWS a ajouté une invite. La machine reste le butin.

Le correctif est le bon. AWS marque désormais mcp.json, .vscode/tasks.json, le répertoire .git et d'autres fichiers sensibles à l'exécution comme des chemins protégés : y écrire exige une approbation explicite, aussi bien en mode Autopilot qu'en mode Supervised. L'étape d'approbation qui manquait est maintenant là. Si vous utilisez Kiro, mettez-le à jour.

Ce que le correctif ne change pas, c'est la forme de la pièce. AWS l'a dit en conclusion : un humain dans la boucle ne fonctionne comme contrôle que si on lui montre l'étape qui compte, et si la plateforme tient la ligne même une fois que le modèle a été entièrement convaincu de la franchir. Cela fait deux exigences. L'invite satisfait la première : elle fait apparaître l'écriture. Elle ne peut satisfaire la seconde, car lorsque le code s'exécute, il s'exécute sur la propre machine du développeur, avec sa propre portée. Une approbation que vous validez d'un clic un après-midi de fatigue, ou une approbation que la prochaine page astucieuse apprend à formuler pour qu'elle paraisse routinière, vous mène au même endroit : le code de l'attaquant s'exécutant là où vivent vos clés, vos dépôts et vos sessions cloud.

La forme récurrente ici — une page que l'agent a lue, une configuration qu'il pouvait écrire, un lancement qu'il pouvait déclencher — n'est pas propre à Kiro. C'est à quoi ressemble un agent qui lit le web ouvert et modifie des fichiers sur une machine pleine de secrets. La question durable est de savoir où l'agent s'exécute, et ce qui l'entoure quand l'invite échoue.

Là où Bromure exécute les mêmes étapes

Bromure Agentic Coding n'essaie pas de faire en sorte que l'agent se méfie de la page, refuse l'écriture ou intercepte le clic. Il change la machine sur laquelle toute la séquence s'exécute. L'agent de chaque profil s'exécute à l'intérieur d'une VM Linux jetable sur Apple Silicon, à un hyperviseur de macOS. Exécutez la chaîne exacte de CVE-2026-10591 là-dedans et chaque étape se déclenche quand même, et chaque étape atterrit ailleurs.

La page est lue. L'injection l'emporte. Le substitut de Kiro réécrit mcp.json, le rechargement se déclenche, la commande de l'attaquant se lance « avec les privilèges du développeur ». Sauf qu'à l'intérieur de la VM, le développeur est l'utilisateur ubuntu dans une boîte jetable, et la boîte ne contient rien qui vaille le déplacement. Le code part à la recherche des identifiants qui rendent l'attaque payante — la clé Anthropic, les clés AWS, le jeton GitHub — et trouve des leurres. Dans Bromure, les vrais secrets n'entrent jamais dans la VM ; un courtier d'identifiants sur l'hôte injecte des substituts comme brm_…, un kubeconfig synthétique et une clé SSH jetable, et n'insère la vraie valeur qu'à la frontière réseau, sur les requêtes vers des destinations que vous avez approuvées. Le vol de code source n'atteint que les dossiers que vous avez choisi de monter. Le « mouvement latéral vers les systèmes internes » atteint le pare-feu de la VM propre à chaque profil.

Il y a ensuite la moitié sortante. Voler un leurre ne paie que si vous pouvez l'envoyer quelque part, et se déplacer latéralement signifie atteindre un second hôte. Ce sont deux actions réseau, et dans Bromure toutes deux traversent le proxy hôte, où la véritable destination d'une requête est filtrée à la sortie et où la forme destructrice d'une action — un delete, un drop ou un terminate contre les API cloud et git que le profil expose — rencontre un garde-fou capable de la refuser, quoi que l'agent ait été persuadé de faire. Tout ce que le code lancé tente laisse une ligne journalisée dans la trace de session.

Et une couche se tient devant tout cela, pour une raison qui colle exactement à cette attaque. Bromure évalue le contenu non fiable qu'un agent lit — une page récupérée ou une réponse d'outil — avec un détecteur d'injection sur l'appareil avant que le modèle n'agisse dessus. Si le texte d'un pixel fonctionne, c'est parce qu'une personne lit la page rendue. Le classifieur, lui, ne le fait pas ; il lit le même flux brut que le modèle, où color:#fff;font-size:1px ne cache rien. L'astuce qui rend le paragraphe invisible à l'œil ne change rien pour un évaluateur qui lit les octets. Il attrape l'essentiel, et un déguisement suffisamment inédit peut encore échapper à un seul détecteur, c'est pourquoi il se tient devant la boîte jetable plutôt que de la remplacer.

Le web est désormais l'entrée non fiable

Pendant des années, le conseil pour les agents de code était de faire attention aux dépôts auxquels vous faites confiance. Kiro fait avancer la leçon : l'entrée dangereuse était une page de documentation, du genre qu'un agent lit cent fois par jour, et l'arme était une propriété CSS qu'un navigateur honore depuis les années 1990. À mesure qu'une plus grande part du flux de développement passe par des agents qui lisent le web ouvert, chaque page est une entrée non fiable, et la lire plus attentivement n'y change rien.

L'invite qu'AWS a ajoutée est le bon correctif, et il devrait être déployé. Mais un contrôle qui dépend d'une personne repérant la seule écriture qui compte, sur chaque page, pour toujours, est un contrôle au piètre bilan sur la durée. Bromure Agentic Coding ne demande pas à l'agent d'être prudent avec le web. Il suppose que la page l'emporte, que la configuration est réécrite et que le code s'exécute, et il fait en sorte que, lorsque tout cela arrive, cela arrive dans une boîte où il n'y a rien à prendre et aucun chemin de retour. C'est la différence entre une invite que l'on peut contourner par la parole et une ligne tracée un niveau plus bas, où la parole cesse de fonctionner. Installez-le et donnez à votre agent une machine qui n'est pas la vôtre à perdre.