Les agents IA doivent proposer l’état système suivant, pas l’écrire en root

8 octobre 2026. Mauro Morales, ambassadeur CNCF et mainteneur de Kairos, publie un billet qui reformule une question devenue récurrente. Un doute. « Sous quelles conditions peut-on, sans risque, laisser un système autonome exploiter une machine ? » Une réponse. Ne pas donner root aux agents, les faire proposer l’état suivant et laisser la forge logicielle transformer cette proposition en réalité. Pourquoi c’est important : à mesure que les agents IA s’installent dans les chaînes d’exploitation, la ligne entre « observer » et « modifier » devient le nouveau périmètre de sécurité du DevOps.

Root n’est pas une API

Le billet s’ouvre sur un aveu honnête : donner root à un agent procure une sensation immédiate de puissance. Morales raconte avoir migré un service domestique d’un MacBook vers un Linux sans coupure, simplement en accordant à l’agent un accès superutilisateur. Puis il tire la conclusion inverse : « ce n’est pas parce que c’est possible que c’est souhaitable ». L’expérimentation et la production n’obéissent pas aux mêmes règles, et s’attendre à ce qu’un fichier AGENTS.md bien rédigé empêche une erreur irréversible relève de l’illusion.

L’argument central n’est pas la panne — une API peut aussi contenir des bugs. C’est la reproductibilité : savoir ce qui a changé et qui l’a changé. « Nous ne devrions pas donner aux agents un accès root non restreint aux systèmes de production, pour la même raison que nous ne le donnons pas aux humains. » La phrase vaut verdict à elle seule. Le problème n’est pas que le modèle soit mauvais, c’est qu’il est non déterministe : on ne peut pas garantir l’issue d’un agent, donc on ne peut pas lui confier un levier irréversible.

Ce raisonnement replace l’agent dans la longue histoire du moindre privilège. Le root n’a jamais été une interface de programmation, c’est une frontière. La franchir pour un humain exige une justification ; la franchir pour un agent ne devrait pas exiger moins.

Le conteneur a déplacé la frontière

Morales replace le débat dans l’histoire du Linux et des conteneurs. Avant eux, une application qui avait besoin d’une bibliothèque l’installait sur le système de base, couplant étroitement l’application et la machine. Les conteneurs ont changé cette frontière en emballant les dépendances utilisateur avec l’application elle-même. Ils ne rendent pas l’hôte inutile — ils partagent toujours son noyau — mais ils offrent une séparation des préoccupations plus nette entre l’application et le système qui l’exécute.

Le rôle de l’hôte se rétrécit alors à une mission étroite : démarrer de façon fiable, fournir le noyau et les capacités d’exécution, et maintenir la plateforme en vie. La plateforme, elle, s’occupe des applications conteneurisées. Cette répartition n’est pas cosmétique : c’est elle qui permet de raisonner séparément sur ce qu’un agent peut toucher.

C’est là que l’immutabilité entre en jeu, non comme une fin mais comme un moyen. Un système immuable ne signifie pas un système figé ; cela signifie que la machine passe d’un état défini à un autre état défini. Les changements du système de base s’expriment dans une définition versionnée, consommée comme une nouvelle image, et non modifiée paquet par paquet à chaud. L’exécution n’est plus le lieu où l’on improvise l’état suivant : c’est le lieu où s’exécute un état produit ailleurs.

L’immuabilité n’est pas un bac à sable

Le billet ne s’arrête pas à l’hôte immuable, et c’est sa force. Les technologies bootc, Flatcar Container Linux et Kairos soutiennent déjà ces cycles de vie d’hôte basés sur l’image. Hadron, le système minimal de Kairos, va jusqu’à ne fournir aucun gestionnaire de paquets. Mais Morales met en garde : l’immuabilité seule ne protège pas la machine d’un processus qui dispose d’un accès hôte, noyau ou disque illimité. L’agent garde la main sur chaque surface où il a un accès en écriture.

Le point décisif est que le logiciel d’agent ne vient pas de la distribution. Il s’installe via un gestionnaire de paquets comme npm, un binaire autonome, une image de conteneur, ou s’intègre à une application existante. C’est pour cela que les harnais d’agent offrent du sandboxing : poser une frontière plus forte autour de ce que l’agent peut faire. Mais tout bac à sable n’est pas étanche. Des harnais locaux comme Claude Code ou Codex restent connectés à l’hôte par le système de fichiers, les identifiants, les outils, les sockets, le réseau ou les permissions accordées en session. Le blog CNCF a déjà documenté pourquoi le sandboxing d’un agent ne suffit pas.

La conclusion de cette section est un avertissement : croire que, parce que le système de base est protégé, le reste de la machine l’est aussi, c’est commettre une erreur de raisonnement.

L’agent est une charge de travail comme une autre

Morales renverse alors la perspective. L’agent est une charge de travail, et chaque session peut s’exécuter dans un environnement d’exécution éphémère, créé pour la durée du travail puis détruit. La frontière d’exécution doit suivre le modèle de menace : un pod standard partage le noyau de l’hôte et convient à un agent au périmètre étroit, tandis qu’un agent qui exécute du code non fiable ou exige des capacités larges requiert un pod sandboxé ou une machine virtuelle.

L’argument clé est que l’agent n’a pas besoin d’un accès direct à l’hôte pour l’observer ou pour proposer comment le modifier. Il peut faire les deux depuis une charge isolée. La distinction rappelle que la question n’est pas binaire — « l’agent a-t-il accès ou non » — mais graduée : quel accès, à quelle surface, pendant quelle durée, avec quelle autorité de validation.

C’est ici que Morales introduit la distinction la plus utile du billet, entre auto-réparation et auto-amélioration. L’auto-réparation consiste à choisir parmi des réponses déjà autorisées : redémarrer, remplacer ou revenir en arrière sur une charge. L’auto-amélioration consiste à proposer un état système que nous n’avons pas encore autorisé, et qui doit donc traverser la forge logicielle avant de devenir réel.

Fermer la boucle sans ouvrir l’hôte

Le billet illustre la différence par un cas concret et daté. Lors de tests QA d’images Kairos Trusted Boot, un agent a aidé à remonter des démarrages bloqués pendant plusieurs minutes et des boucles de réinitialisation firmware jusqu’à un alignement de section PE incorrect dans go-ukify, la bibliothèque qu’AuroraBoot utilise pour assembler les UKI. Les sections étaient alignées sur 512 octets alors que le stub systemd exigeait 4 Ko. Le correctif a abouti à go-ukify v0.5.2, puis à la mise à jour d’AuroraBoot, et l’agent a vérifié les images corrigées.

Ce que l’agent ne doit pas faire, c’est appliquer ces changements via un accès root ou modifier un système mutable en place. À partir de la question d’autonomie, un système immuable est clairement supérieur : l’agent inspecte l’état courant, consigne son évaluation et ouvre une pull request proposant l’état suivant. Cette proposition suit alors le même processus qu’un changement humain : revue, tests, construction d’une nouvelle image, signature, publication. Ce n’est qu’ensuite que le nouvel état est consommé.

Pour que la frontière soit réelle, l’identité de l’agent doit pouvoir proposer un changement sans pouvoir l’approuver, le fusionner, altérer le pipeline, publier ou signer l’image, ni forcer la machine à le consommer. Sinon, on a remplacé le root par « le root plus quelques étapes ». Cette séparation des autorités rejoint le modèle de menace du CI/CD décrit dans les travaux sur l’IA fantôme dans les pipelines.

Verdict

Si vos agents opèrent déjà vos clusters ou vos hôtes, remplacez tout accès root direct par une chaîne en trois couches : une base immuable (image, pas de mutation à chaud), une isolation de charge proportionnée au modèle de menace (pod, pod sandboxé ou VM), et une proposition d’état qui passe par la forge — revue, build, signature, publication. Accordez à l’identité de l’agent le droit de proposer, jamais celui de fusionner, signer ou déployer. Si vous n’avez pas encore d’agents en production, posez ces frontières avant le premier accès, pas après le premier incident : « faire confiance aux frontières, pas au modèle » est un principe qui coûte bien moins cher à installer qu’à rattraper.

Références

• CNCF Blog — Don’t give AI agents root. Make them propose the next system state (Mauro Morales, 8 octobre 2026)
• The New Stack — Your AI agent just provisioned a resource. Who owns it? (8 octobre 2026)
• The New Stack — The audit log says my name: what an agent inherits when you hand it your credentials (8 octobre 2026)
• CNCF Blog — Shadow AI in CI/CD