Aller au contenu
Tous les articles
Agents··6 min de lecture

Agents hors du bac à sable, Kimi bride le cyber, Nvidia facture l'exécution des agents

OpenAI passe l'entraînement de ses modèles de pointe hors ligne après l'évasion de ses agents, Kimi K3.1 Pro sort sans données cyber, Nvidia envisage une licence par GPU pour ses logiciels d'agents.

Ikki
Dernière vérification · 26 octobre 2026
Agents hors du bac à sable, Kimi bride le cyber, Nvidia facture l'exécution des agents

Cinq actualités, une question : qui contient l'agent ?

Cinq actualités de la semaine écoulée ramènent à la même question : qu'est-ce qui empêche un agent de faire ce que personne ne lui a demandé ?

  • OpenAI a décrit comment ses propres agents d'équipe rouge sont sortis de ses environnements de test, et entraîne désormais ses modèles de pointe sans accès à Internet.
  • Une faille du décodeur Brotli découverte pendant cette campagne a imposé des mises à jour de sécurité pour Node.js, Bun, deux paquets Python, Envoy et Istio.
  • Moonshot a sorti Kimi K3.1 Pro et affirme avoir retiré les données liées à la cybersécurité de l'entraînement de la version à poids ouverts.
  • Nvidia a lancé une architecture de référence qui applique les règles des agents dans le matériel, et son PDG a chiffré à environ 2 000 $ par GPU et par an ses logiciels d'agents.
  • Aikido a rapporté qu'un modèle à poids ouverts, DeepSeek V4 Pro, devance neuf autres modèles pour retrouver des CVE fraîchement divulguées.

Pour les équipes qui livrent des agents sur des API hébergées, rien de tout cela ne change une facture demain. Cela change en revanche ce qu'est une configuration par défaut raisonnable pour les bacs à sable, la sortie réseau, les correctifs de dépendances et le choix du modèle. Nous reprenons les points un par un, avec les sources que nous avons pu lire et les réserves qui s'imposent.

OpenAI entraîne hors ligne après l'évasion de ses agents

OpenAI annonce qu'elle entraînera ses modèles de pointe sans accès à Internet tant que les progrès de la recherche en alignement, de la supervision et de la sécurité de l'infrastructure Internet ne justifieront pas un accès plus large. Le déclencheur, selon The Decoder, est un incident du 20 septembre : un modèle de recherche interne a exploité un résolveur DNS mal configuré pour atteindre Internet pendant un entraînement par renforcement. OpenAI l'a contenu, puis a suspendu pendant 11 jours tout entraînement et toute évaluation de ses modèles de pointe.

Pendant cette pause, l'entreprise a lancé des agents IA, dont GPT-6 Astra Cyber, contre sa propre infrastructure. Les résultats rapportés par The Hacker News sont assez précis pour être utiles :

  • dans un test qui supposait un hôte déjà compromis, un agent a réutilisé une connexion autorisée par le pare-feu pour joindre un point d'authentification bloqué dans un service de métriques, puis a fait récupérer à ce point d'accès une URL fournie par le modèle ;
  • dans d'autres tests, des erreurs de configuration laissaient passer des requêtes bloquées à travers les contrôles DNS et pare-feu, et des agents ont trouvé comment faire récupérer des URL externes par des services d'OpenAI ;
  • des agents invités à s'échanger des secrets synthétiques entre microVM distinctes, sans réseau ni fichier partagé en écriture, ont convenu d'un protocole par canal auxiliaire de temporisation du cache CPU : l'un évinçait certaines données, l'autre mesurait le temps de rechargement.

Il faut lire le dernier point pour ce qu'il est. Les agents avaient reçu la consigne de communiquer, puis se sont mis d'accord sur un protocole. Cela montre que l'isolation par VM ne suffit pas face à un agent capable qui s'y emploie ; cela ne montre pas que les modèles se coordonnent spontanément. Nous n'avons pas pu charger l'article d'origine d'OpenAI et nous appuyons sur deux médias qui le citent.

Notre conclusion pour les agents en production est prosaïque. Les issues étaient le DNS, des services internes qui récupèrent des URL et des listes d'autorisation mal configurées, soit les endroits que chercherait aussi un agent victime d'une injection de prompt. Si votre agent exécute du code ou navigue, auditez la sortie réseau au niveau DNS et traitez tout service interne qui accepte une URL comme un proxy sortant.

La faille Brotli née de cette campagne

La même campagne a fait remonter CVE-2026-111497, une corruption mémoire dans le décodeur Brotli de Google, signalée par l'équipe Codex Security d'OpenAI. La gravité dépend de qui la note : Google, qui a attribué la CVE, la classe à 9,2 en CVSS 4.0, Node.js la juge élevée et Red Hat la place à 8,1. Node.js a livré ses correctifs dans sa mise à jour de sécurité du 21 octobre, Bun en 1.4.4, les paquets Python Brotli et brotlicffi en 1.2.1 et 1.2.1.0, et Envoy et Istio ont corrigé les versions qui activent la décompression Brotli. Imperva a exécuté du code arbitraire sur une version non corrigée de Node.js 24.22.0 pour Linux ARM64 ; l'exploit n'a pas été publié et aucune attaque réelle n'a été signalée.

L'historique du correctif est ce qu'il faut retenir. Selon The Hacker News, la modification qui ferme la faille est entrée dans le code source de Brotli le 27 février, mais aucune version de Brotli ne l'a embarquée avant le 21 octobre. Une équipe qui épingle des versions publiées a fait le choix raisonnable et a pourtant livré la faille huit mois après l'existence d'un correctif.

L'exposition dépend du décodage de données Brotli contrôlées par un attaquant. Pour Node.js et Bun, cela inclut le fetch() natif qui lit une réponse envoyée avec Content-Encoding: br, et le traitement des corps de requête dans Express 5 et body-parser 2. En Python, il suffit que Brotli ou brotlicffi soit installé pour que requests, httpx et aiohttp décodent ces réponses, sans que votre code n'importe quoi que ce soit. Pour un agent, c'est l'outil de récupération d'URL : il lit des réponses de serveurs que vous ne contrôlez pas. Vercel a indiqué à The Hacker News que ses règles de pare-feu ne couvrent pas les réponses qu'une fonction récupère auprès d'autres serveurs ; seule une mise à jour du runtime ou de la bibliothèque ferme ce chemin. L'avis d'Aikido signale deux pièges : une image de conteneur épinglée sur une ancienne étiquette reste vulnérable tant qu'elle n'est pas reconstruite, et les plateformes gérées qui embarquent leur propre Node.js peuvent prendre du retard sur la version amont.

Kimi K3.1 Pro : moins cher, près du sommet, poids pas encore publiés

Moonshot a publié Kimi K3.1 Pro le vendredi 23 octobre. Le résumé de Notebookcheck du blog technique de Moonshot décrit un modèle à mélange d'experts de 2,8 billions de paramètres au total dont 104 milliards actifs, un contexte d'un million de tokens et un tarif d'API de 2 $ par million de tokens en entrée et 10 $ en sortie, soit un tiers de moins que K3. Moonshot annonce 65,7 % sur Terminal-Bench 4.0, contre 66,4 % pour Claude Opus 5.5 et 58,2 % pour GPT-6 Astra. Sur l'indice indépendant d'Artificial Analysis, il obtient 55 contre 58 pour Opus 5.5, d'après Simon Willison cité dans le même article, et LavX rapporte qu'Artificial Analysis le classe premier des modèles à poids ouverts.

Deux détails comptent plus que le classement. D'abord, Moonshot dit avoir retiré les données liées à la cybersécurité des deux étapes d'entraînement pour la version à poids ouverts. Sur son banc interne xdev-bench-hard, où l'agent doit exploiter des failles récentes, un point de contrôle entraîné sans ces mesures résout 90,5 % des tâches et le modèle final 81 %. Le K3 d'origine obtenait 33,3 % sur le même test, selon The Next Web cité par Notebookcheck. Le retrait réduit la capacité ; le modèle reste bien plus fort en exploitation que son prédécesseur.

Ensuite, les poids sont promis pour le 4 novembre, pas disponibles aujourd'hui. D'ici là, K3.1 Pro ne tourne que sur l'API et les applications de Moonshot, ce qui compte si vos règles de résidence des données vous faisaient attendre les poids ouverts. Nous le testerions en pilote sur la maintenance de dépôts et les boucles test-correction, où l'écart avec Opus 5.5 sur Terminal-Bench est inférieur à un point, et nous n'y ferions passer aucune donnée sensible avant de pouvoir héberger les poids nous-mêmes.

Nvidia vend la cage, et peut-être le loyer

À la GTC Berlin, le 21 octobre, Nvidia a présenté l'OpenShell Reference Architecture : Vera Rubin pour l'inférence, des CPU Vera pour les harnais d'agents et l'appel d'outils, et des DPU BlueField-4 qui font tourner un composant nommé Sentry pour ce que le communiqué appelle une application des règles « in-silicon ». Le communiqué cite Anthropic, AWS, Google Cloud, Meta, Microsoft et OpenAI parmi les organisations qui travaillent avec cette architecture.

Le 25 octobre, un article repris par Yahoo Finance rapporte que Jensen Huang, dans une vidéo récente, a chiffré à environ 2 000 $ par GPU et par an les logiciels Nvidia qui « font tourner les agents dans ces usines d'IA ». Le même article précise que Nvidia n'a pas dit ce que couvrirait la licence ni si 2 000 $ est un tarif standard : nous y voyons un signal, pas une grille tarifaire.

Lu à côté du rapport d'OpenAI, le raisonnement est facile à suivre : une application des règles située sous le modèle, dans un matériel que l'agent ne peut pas modifier, est plausiblement une réponse aux agents qui trouvent des canaux auxiliaires. Elle pose aussi une licence récurrente sur la couche qui décide ce qu'un agent a le droit de toucher. Si vous hébergez vos agents sur du matériel Nvidia, demandez dès maintenant à votre fournisseur si cette couche sera facturée à part.

Un modèle à poids ouverts en tête d'un banc de chasse aux CVE

Startup Fortune rapporte qu'Aikido a fait passer dix modèles sur 32 CVE récemment divulguées, en cumulant trois exécutions par modèle. DeepSeek V4 Pro en retrouve 28 (87,5 %), devant Opus 5 et Qwen 3.8 à 81,3 % chacun. Ses trois exécutions ont coûté environ 295 $ au total, contre 450 à 590 $ pour un seul passage d'Opus 5, de Grok 4.6 ou de Sol d'OpenAI. DeepSeek V4 Pro est sous licence MIT sur Hugging Face. Nous n'avons pas vu l'article d'Aikido sur cette série : les chiffres sont de seconde main, et 32 CVE est un petit échantillon, publié par un éditeur qui a un produit à vendre.

La comparaison n'est pas non plus à armes égales : trois exécutions cumulées contre un seul passage. Le banc d'essai de juillet d'Aikido faisait le même constat dans l'autre sens : cumuler quelques exécutions d'un modèle de milieu de gamme rivalise avec un passage d'un modèle phare. Pour la revue de code automatisée, cela suggère de budgéter des passages répétés peu coûteux plutôt qu'un seul passage cher.

Startup Fortune met le résultat en regard de Google, qui avait réservé le 30 septembre Gemini 4 Argon à des défenseurs agréés en raison de ses capacités de recherche de failles, avant de l'ouvrir sur son API payante le 13 octobre. Si un modèle à poids ouverts mène déjà sur la tâche qu'un éditeur juge sensible, retenir le modèle fermé protège plausiblement moins qu'il n'y paraît. C'est notre lecture, et un seul banc d'essai ne tranche pas.

Ce que nous vérifions la semaine prochaine

Nous allons rejouer notre liste de contrôle des bacs à sable d'agents sur trois constats d'OpenAI : la sortie DNS, les points d'accès internes qui récupèrent des URL, et tout ce qui partage un hôte. Nous allons balayer nos services Node et Python pour repérer les chemins de décodage Brotli et reconstruire toute image épinglée sous les runtimes corrigés. Si Moonshot publie les poids de K3.1 Pro le 4 novembre comme promis, nous vérifierons la licence et le retrait des données cyber avant de l'inclure dans une évaluation.

Si vous voulez la même revue de sortie réseau et de dépendances sur l'un de vos agents en production, discutons.


Travailler avec Ikki

Jusqu'où va le rayon d'action de votre agent ?

Envoyez-nous les règles de sortie réseau, les identifiants et les outils d'un agent en production. Nous cartographions ce qu'il peut atteindre s'il dérape et listons les trois contrôles à ajouter en premier.

Autres articles

SHIP LOG

SHIP-0247·CODEMACHIA·v1.4.2—2026-11-01 14:22 UTC