Docker confie à la CNCF un format ouvert pour encadrer les permissions des agents IA
Le 24 septembre 2026, Docker a publié la Sandbox Kit Specification v3 sous licence Apache 2.0 et l’a remise à la gouvernance de la CNCF : un Kit devient une image OCI ordinaire qui embarque l’agent, ses outils et la liste typée de ce qu’il a le droit d’atteindre. Les équipes qui déploient des agents de code doivent adopter ce modèle pour transformer des autorisations implicites en artefact versionné et auditable.
24 septembre 2026. Docker annonce à la conférence WeAreDevelopers la publication de la Sandbox Kit Specification v3 et sa remise à la CNCF. Apache 2.0. C’est la licence du format, désormais ouvert. Il y a dix ans, Docker avait déjà fait le même geste : donner son format d’image et le runtime runc à la Linux Foundation, donnant naissance à l’OCI. Pourquoi c’est important : le problème que l’OCI a réglé pour les conteneurs — un format unique et portable — se repose aujourd’hui, à l’identique, pour ce qu’un agent a le droit de faire.
Le même problème, dix ans plus tard
Un conteneur décrit un logiciel immuable. L’image est l’application ; si on veut la changer, on la reconstruit, et elle se comporte partout pareil. C’est pourquoi une image décrit comment le logiciel est construit, mais reste muette sur ce qu’il a le droit de faire une fois lancé. Pour un service web, c’était suffisant : un réseau, un port, et l’affaire était entendue.
Un agent est l’inverse exact. Claude Code ou Codex installent des paquets, appellent des API et utilisent des identifiants à votre place. Ils modifient l’environnement où ils tournent et décident de la prochaine action. Résultat : chaque équipe écrit ses propres règles pour ce que l’agent peut atteindre — une règle réseau ici, un jeton là, un montage de volume pour finir une tâche. Ces règles vivent dans l’historique du shell, dans des tableaux de bord et dans la mémoire de quelqu’un. Au bout de quelques mois, plus personne ne sait répondre à une question simple : qu’est-ce que cet agent a le droit de faire ?
C’est précisément la fragmentation que l’OCI avait été créée pour empêcher, et que Docker veut maintenant éviter pour les agents.
Le Kit : une image OCI, pas un nouvel artefact
La réponse s’appelle un Kit. Le concept n’est pas neuf — les Kits font partie de Docker Sandboxes depuis plusieurs versions, comme manière d’emballer un agent, ses outils et son périmètre dans quelque chose qu’une équipe peut partager. Ce qui change avec la v3, c’est l’artefact lui-même : un Kit est désormais une image OCI ordinaire.
Un Kit transporte trois choses dans une seule image : l’agent, ses outils, et une liste typée de tout ce qu’il demande à atteindre — hôtes, identifiants, volumes. Parce que cette liste fait partie de l’image, épingler l’image épingle l’agent et ses demandes ensemble. Le manifeste porte les déclarations dans une annotation unique, vnd.docker.sandbox.kit.descriptor ; les couches portent le contenu. Il ne s’agit ni d’un nouveau type d’artefact, ni d’un fork d’une spécification OCI : le format utilise un point d’extension que l’OCI définit déjà.
Conséquence pratique, et c’est le point décisif : un Kit se construit avec docker buildx build, se tire avec docker pull, se signe et se scanne avec l’outillage que vous utilisez déjà — parce que c’est une image comme les autres. « L’adoption est gratuite », résume Docker : chaque registre, chaque scanner, chaque outil de signature le prend en charge sans rien déployer de nouveau.
L’autorité devient du code
Le second billet publié par Docker résume la philosophie en trois mots : « Authority as Code ». Aujourd’hui, chaque octroi d’accès à un agent est raisonnable pris isolément : un montage en lecture-écriture, un jeton au périmètre plus large que la tâche, une règle de pare-feu plus rapide à ouvrir qu’à restreindre. Additionnés, ces octrois font tomber l’isolation qu’on croyait avoir — et aucun n’a nécessité d’exploit. Les trous sont de la configuration, ajoutée volontairement, souvent par nous-mêmes.
Le Dockerfile ne dit rien de tout cela. Il répond à tout sur le logiciel — comment il est construit, ce qui est empaqueté, comment il démarre — mais reste muet sur l’extérieur : réseaux, identifiants, volumes, outils, contexte. Cette moitié a vécu dans les flags de docker run, un fichier Compose, une config CI et la mémoire de quelqu’un : non versionnée, non revue. Un Kit l’écrit noir sur blanc, avec le contenu.
La métaphore de la sandbox complète le tableau. Un conteneur partage le noyau de l’hôte ; une Docker Sandbox est une microVM dotée de son propre noyau, donc la frontière se situe sous tout ce que le modèle peut atteindre ou réécrire. À l’intérieur, on peut donner root à un agent et le laisser faire, parce que les dégâts s’arrêtent à la frontière. Mais une sandbox vide n’est pas un environnement : il faut encore dire quel agent y tourne, quels outils il reçoit, et exactement ce qu’il peut toucher. C’est ce que le Kit écrit.
La CNCF, et l’écosystème qui suit
Docker ne garde pas le format pour lui. Comme il y a dix ans pour l’image, le format part sous la gouvernance neutre de la CNCF. C’est le signal qui compte : un format de permissions d’agents ne vaut que s’il est portable entre runtimes — sinon chaque fournisseur livrera sa propre réponse, et on retombe dans la fragmentation.
L’écosystème n’a pas attendu. Docker annonce avoir travaillé avec AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks et Snyk — entre autres — pour construire des Kits pour leurs outils. Cloud, observabilité, sécurité, gestion d’artefacts, frameworks d’agents : toutes les strates de la chaîne d’outillage sont représentées. C’est exactement la dynamique qui a fait le succès du Dockerfile : n’importe qui peut en écrire un, n’importe quel registre peut stocker le résultat, n’importe quel runtime peut l’exécuter.
Pour un SRE ou un RSSI, la promesse est concrète. « Que peut faire cet agent ? » cesse d’être une question d’enquête pour devenir une question de lecture. Un collègue peut tirer l’image, un relecteur peut en faire le diff, un runtime conforme peut l’appliquer. Quand une nouvelle version demande davantage — un hôte supplémentaire, un identifiant de plus — le changement apparaît comme des lignes ajoutées que quelqu’un peut refuser. L’audit de sécurité des agents passe d’un cauchemar de reconstruction à une revue de code ordinaire.
Ce que cela change, et ce que cela ne change pas
Il faut rester lucide sur la portée. La Sandbox Kit Spec ne répare pas un agent malveillant ou un modèle qui décide de faire n’importe quoi : elle rend lisible et exécutoire la frontière qu’on veut lui imposer. Un format ne remplace pas une politique ; il la matérialise. La distinction compte, parce que beaucoup d’équipes confondent encore « j’ai une sandbox » avec « je gouverne mes agents » — alors que la sandbox n’est que la moitié du problème, l’autre moitié étant justement la liste des permissions.
L’autre limite est l’adoption. Le format est ouvert et gratuit, mais sa valeur dépend du nombre de runtimes et d’outils qui le consomment réellement. La présence de Snyk, Datadog et Palo Alto Networks dans la liste des partenaires suggère que le mouvement est lancé ; il reste à voir si les runtimes concurrents — et pas seulement Docker Sandboxes — le prendront en charge. C’est le pari exact que l’OCI a gagné en 2015, mais rien ne garantit qu’il se rejoue à l’identique.
Verdict
Le geste de Docker est le bon, et il arrive au bon moment : les agents de code sont en train de sortir du bac à sable individuel pour entrer dans les pipelines CI et les comptes cloud des entreprises, sans format partagé pour ce qu’ils peuvent faire. Si vous exécutez des agents de code en équipe, commencez par adopter l’idée centrale du Kit — la réponse voyage avec l’agent — même avant que votre runtime ne l’implémente : versionnez et revoyez la liste des hôtes, identifiants et volumes que chaque agent reçoit, comme vous le faites pour le code. Si vous utilisez déjà Docker Sandboxes, migrez vos environnements .sbxenv.yaml vers des Kits signés et épinglés par digest, et exigez la vérification de signature au chargement. Si vous évaluez plusieurs runtimes d’agents, faites du support de la Sandbox Kit Spec un critère de sélection : c’est la meilleure garantie, aujourd’hui, de ne pas reconstruire une île de permissions propriétaires que vous devrez réécrire dans dix-huit mois.