Les agents ne rentrent pas dans Kubernetes, et trois autres problèmes encore ouverts

Kubernetes a été conçu pour des applications sans état, répliquées. Un agent, c’est l’inverse : une instance unique, isolée, avec un état, qui reste inactive pendant des heures, puis se réveille et attend un outil, un modèle ou une personne. Ce décalage est le premier de quatre problèmes que, selon Katelyn Lesse, responsable de la plateforme chez Anthropic, les ingénieurs logiciels doivent résoudre avant qu’on puisse confier un travail sérieux à des systèmes multi-agents. Les trois autres : qui est un agent et ce qu’il a le droit de faire, jusqu’où s’étendent les dégâts d’un agent compromis, et comment arrêter tout un système d’un coup.

Son article est paru sur X le 26 octobre. Il est court, et il s’ouvre sur les ingénieurs qu’elle voit traverser une crise d’identité à mesure que le métier change. Sa réponse n’est pas du réconfort. C’est une liste de travaux. Je fais tourner 17 agents sur un Mac mini et j’en déplace un dans une sandbox sur un vieux Dell, alors à la fin je confronte ma propre flotte à ses quatre.

D’un chat à des milliers d’agents

Son récit de la façon dont on en est arrivé là est rapide. Les agents ont commencé comme des chats avec un humain dans la boucle. Puis les modèles sont devenus meilleurs pour tenir plus longtemps sur des problèmes plus durs, et les systèmes agentiques sont partis dans le cloud. Puis les modèles sont devenus meilleurs pour travailler ensemble, et on a construit des systèmes multi-agents de base : un orchestrateur qui lance des sous-agents pour une tâche, ou des agents chargés d’autre chose que d’exécuter, « comme noter, conseiller ou rêver ».

Aujourd’hui, certaines équipes construisent des systèmes pour de la recherche sérieuse, de la découverte et de la conception matérielle. Son image, ce sont des milliers d’agents qui travaillent en continu vers un résultat. C’est là qu’apparaissent les nouveaux problèmes, et elle en nomme quatre. Une infrastructure pour des charges plus irrégulières. L’authentification et l’autorisation, pour que les agents puissent être identifiés, travailler ensemble, faire les actions qu’ils doivent faire et être tenus à l’écart de celles qu’ils ne doivent pas faire. La sécurité et l’isolation pour du code et du contenu non fiables. Et la supervision, avec la possibilité d’arrêter un système « quand il dérive vers le mauvais territoire ».

Les modèles vont continuer à s’améliorer, dit-elle, et ces systèmes vont devenir vraiment puissants. Que le monde fasse confiance à cette puissance pour guérir des maladies plutôt que pour causer du tort, cela repose sur les ingénieurs qui construisent la plomberie.

Les agents ne rentrent pas dans Kubernetes

L’industrie du logiciel construit depuis des années sur Kubernetes, conçu pour des applications sans état et répliquées, ou pour des ensembles stables et numérotés de pods avec état. Les agents sont « des charges de travail isolées, avec état, à instance unique ». Ils restent inactifs pendant des durées arbitraires entre deux bouts de travail. Ils passent l’essentiel de leur vie à attendre : des outils, l’inférence du modèle, d’autres agents, un humain.

Chacune de ces formes attend quelque chose de différent de la machine en dessous. Certaines charges ont besoin d’un démarrage rapide. Certaines doivent arrêter de brûler du calcul pendant qu’elles attendent. Certaines ont besoin d’une échelle démesurée. Elle pointe les entreprises d’infrastructure IA qui construisent de nouveaux systèmes de fichiers et des offres de sandboxing, et l’équipe de Google qui construit Agent Substrate comme nouveau runtime, et dit qu’il reste énormément à inventer.

Ma flotte est une petite version du problème de l’inactivité. Dix-sept agents OpenClaw vivent sur un seul Mac mini, chacun derrière son propre bot Telegram, et la plupart ne font rien tant qu’un message n’arrive pas. Forge, mon agent de contribution open source, est l’autre forme : un worker démarre pour une issue, clone un dépôt, lance ses tests et disparaît. Aucun des deux ne ressemble à un replica set.

Qui a fait ça, vous ou votre agent

L’authentification, identifier l’agent qui a fait une action, est la moitié facile. Le monde des microservices a déjà construit et durci les pièces : l’identité de charge de travail (workload identity), des certificats à courte durée de vie plutôt que des clés statiques. On commence à les appliquer aux agents.

L’autorisation est « bien plus ouverte ». La plupart des agents aujourd’hui travaillent au nom d’un humain et utilisent l’identité et les identifiants de cet humain pour atteindre des systèmes et agir. Le premier problème se cache dans cette phrase : côté système receveur, rien ne dit si c’est l’humain ou l’agent qui a agi. Le plus profond, c’est le consentement. Si un système multi-agents travaille pendant des semaines, comment l’humain approuve-t-il réellement ce que son agent peut faire ? L’approbation automatique des appels d’outils aide, dit-elle, mais à l’échelle, les permissions doivent aller plus loin que ça.

Puis la partie encore moins résolue : des agents avec leur propre identité, et des agents qui travaillent ensemble. Comment un agent fait-il confiance à un autre agent qui lui a demandé quelque chose ?

Je connais le premier problème du côté receveur. Chaque pull request qu’ouvrent mes agents a pour auteur moi, pour autant que GitHub le sache. Dans mes propres dépôts, la seule trace qu’une session a fait le travail est un identifiant de session dans un commentaire HTML du corps de la PR. Et ma première tentative pour délimiter ce qu’un agent a le droit de faire m’a appris à quel point cette couche est mince : une règle d’interdiction dans la configuration de ma passerelle n’a rien bloqué pendant un mois, et un agent censé être tenu à l’écart de mon application de finances s’est vu proposer ses 13 outils. Je l’ai raconté dans la note sur les collègues IA dans Slack, où MintMCP donne à chaque agent une identité à lui.

Un agent compromis, c’est un rayon d’explosion

Ces derniers mois, écrit-elle, et surtout ces dernières semaines, des vulnérabilités sont apparues plus vite que l’industrie ne peut les corriger, beaucoup dans des logiciels de base dont dépendent de nombreux systèmes. Posez des milliers d’agents persistants sur ces logiciels, à écrire du code non fiable et à lire du contenu non fiable, et chaque vulnérabilité non corrigée devient plus dangereuse. Ce qu’elle demande aux ingénieurs, c’est de faire preuve d’imagination pour durcir les noyaux, navigateurs, runtimes et bibliothèques communes sur lesquels ces agents tournent.

Les systèmes multi-agents ajoutent une subtilité. Un agent compromis peut transmettre des instructions injectées aux agents avec lesquels il travaille, et ces instructions peuvent finir en mémoire, où de futurs agents leur font confiance par accident. La question devient donc le rayon d’explosion (blast radius) : quand le premier agent tombe, quelle part du système est en danger ? Sa réponse est l’isolation. Les agents devraient agir depuis des environnements d’exécution fortement isolés, en sandbox.

Elle a écrit la version longue en septembre, dans Secure agents: architecture and sandboxing, et c’est la page la plus pratique que j’aie lue sur le sujet. Séparer le cerveau des mains. Le harnais, l’état de la session et les identifiants vivent hors de la sandbox, sur une infrastructure de confiance, et la sandbox n’est qu’un outil que l’agent utilise pour exécuter du code. Quand du code dans la sandbox a besoin d’un service externe, la requête sort par un proxy de sortie qui ajoute l’identifiant au passage, limité à cette seule destination. La sandbox peut contenir un substitut que le proxy échange contre la vraie clé. Sa phrase sur l’alternative, tout dans une seule boîte : « Votre coupe-circuit est en gros à l’intérieur de la chose que vous essayez d’arrêter. »

La sandbox elle-même demande ensuite quatre réglages. L’isolation, du plus faible au plus fort : les conteneurs, qui partagent le noyau de l’hôte et ne devraient pas servir de frontière de sécurité pour du code non fiable ; un noyau en espace utilisateur comme gVisor ; des microVM comme Firecracker, chacune avec son propre noyau derrière le matériel de virtualisation du processeur, son choix pour la plupart des équipes ; et des VM complètes ou des hôtes dédiés pour le travail réglementé. Les sandboxes devraient être éphémères, « du bétail plutôt que des animaux de compagnie », avec des limites strictes de temps et de ressources. La sortie réseau devrait tout refuser par défaut derrière un proxy, avec une liste blanche d’hôtes et de méthodes HTTP, et le DNS fermé ; installer les dépendances au début de la session, puis verrouiller le réseau avant que l’agent commence à travailler. Et les journaux des appels d’outils, des commandes et des accès réseau partent quelque part où la sandbox ne peut pas atteindre, à côté d’un coupe-circuit qui fonctionne en pleine session.

C’est proche de ce que j’ai construit pour les workers de Forge dans ma sandbox dans la sandbox : la clé à l’intérieur de la sandbox est un substitut que le proxy d’OpenShell échange à la sortie, et les workers ont une seconde clôture avec une seule porte, un relais avec une liste blanche d’hôtes.

Un coupe-circuit hors de la chose qu’il arrête

Le dernier ensemble est celui qu’elle qualifie de difficile. Il faut savoir que ces systèmes vont dans une direction positive, et pouvoir les attraper et les couper quand ce n’est pas le cas. Concrètement : du traçage OpenTelemetry à travers les agents, avec la garantie qu’un agent ne peut jamais modifier sa propre trace ni celle d’un autre. Et des coupe-circuits que la supervision peut déclencher, qui arrêtent vraiment tout le système d’un coup et lui coupent ses identifiants.

Le plus dur n’est pas l’interrupteur. C’est de savoir quand l’actionner. « Une persévérance bien intentionnée pour résoudre un problème peut beaucoup ressembler à de la malveillance. » Son exemple : des tentatives répétées d’atteindre un domaine qui n’est pas sur la liste blanche.

J’ai vu cette ambiguïté des deux côtés. Les workers de Forge exécutent les scripts d’installation et les suites de tests d’inconnus derrière un relais qui n’autorise qu’une courte liste d’hôtes. Si un test va chercher une fixture sur un hôte que je n’ai jamais listé, le relais le refuse, et refuse la nouvelle tentative. Vu de l’extérieur, ce worker et une tentative d’exfiltration écrivent la même ligne de journal. L’autre côté : quand j’ai arrêté d’utiliser Hermes cet été, mon coupe-circuit a été de révoquer ses jetons Telegram. Le 14 septembre, ses deux passerelles tournaient en boucle de plantage, en réessayant des jetons qui ne marchaient plus. De la persévérance, pas de la malveillance, et rien dans les journaux seuls ne permettait de le dire.

Où en est ma flotte sur les quatre

Elle termine l’article pour les ingénieurs qui pensent que leurs compétences ne compteront plus : ces problèmes sont grands ouverts, et « vous et vos compétences pouvez faire la différence ». Alors, honnêtement, la mienne.

Infrastructure : un Mac mini, 17 agents, inactifs presque toute la journée. Pas d’ordonnanceur, pas de démarrage rapide, rien à mettre à l’échelle. Ça marche parce que la flotte est petite.

Identité : tout tourne en mon nom. Les agents utilisent mes comptes, et leurs pull requests sont les miennes sur GitHub. Deux d’entre eux, Nova et Spark, ont leurs propres comptes Slack dans un espace de travail réservé aux agents, ce qui est le premier morceau d’une identité. La confiance d’agent à agent ne s’est pas encore posée : Telegram ne livre pas les messages d’un bot à un autre, donc mes agents ne peuvent pas se parler là.

Isolation : partielle. Les workers de Forge tournent dans srt, un runtime de sandbox sur Seatbelt de macOS, et sur le Dell ils tourneront dans une cage Landlock à l’intérieur d’OpenShell, avec les clés dehors. Tous les autres agents exécutent leurs outils sur l’hôte, ce qui est le réglage par défaut d’OpenClaw et la ligne vide de ma note sur les cinq pièces de NVIDIA.

Supervision et arrêt : la ligne la plus faible. Meterlex chiffre chaque session, mais c’est un compteur, pas une trace, et rien ne relie les actions d’un agent à celles d’un autre. Il n’y a pas de coupe-circuit. Arrêter un agent, c’est arrêter sa passerelle ou révoquer un jeton, à la main. Forge a un budget de 5 $ par jour, et son profil Hermes sur le Dell a un hook qui voit chaque appel d’outil avant qu’il s’exécute. C’est ce que j’ai de plus proche d’un interrupteur.

À lire

Son article fait quelques écrans, et il est écrit pour des ingénieurs plutôt que pour des acheteurs. Lisez-le pour les quatre titres, puis son billet de septembre pour les réglages de la sandbox, parce que celui-là, vous pouvez l’appliquer cette semaine.

Pour aller plus loin :

• The new set of problems for engineers to solve, Katelyn Lesse, 26 octobre 2026
• Secure agents: architecture and sandboxing, son billet de septembre sur la séparation du cerveau et des mains
• Espérer n’est pas sécuriser : les cinq pièces d’un agent en entreprise, la version NVIDIA de la même liste, avec OpenShell
• Une sandbox dans la sandbox, les workers de Forge derrière un relais dans OpenShell
• Les collègues IA dans Slack ont besoin de leur propre identité, les agents de MintMCP, chacun son propre principal
• Ce qui casse quand un agent IA gère un vrai commerce, quatre mois d’un agent qui s’obstine sur la mauvaise chose

Si vous faites tourner plus d’un agent, choisissez la ligne où vous échoueriez en premier et dites-moi laquelle. La mienne, c’est le coupe-circuit, et j’aimerais entendre quiconque en a construit un qui arrête toute une flotte et lui coupe ses identifiants en un seul geste.

Texte brut: agents-dont-fit-kubernetes-open-problems.md · Flux Atom · Toutes les notes