Permissions des agents IA : Docker les grave dans l'image

Les permissions des agents IA viennent de trouver un format. Le 24 septembre, en ouverture de la conférence WeAreDevelopers, Docker a publié la Sandbox Kit Specification, une spécification open source sous licence Apache 2.0 qui décrit dans une image OCI ce qu'un agent a le droit de toucher : quels hôtes réseau, quels jetons, quels volumes. Le même jour, Docker et la CNCF ont annoncé un partenariat pour faire de ce format un standard ouvert plutôt qu'un produit maison.

Pour une équipe qui fait tourner Claude Code, Codex ou un agent interne sur du code de production, la question n'est plus « l'agent sait-il faire ? » mais « qu'a-t-il le droit de faire, et qui l'a décidé ? ». Jusqu'ici, la réponse vivait dans un README, un fichier de configuration local ou la mémoire d'un développeur. La spécification propose de la faire voyager avec l'agent lui-même, sous le même digest que son code.

Le contexte

Un conteneur isole un processus avec les namespaces et les cgroups du noyau hôte. Un Dockerfile décrit comment construire l'image : ce qu'on y met, dans quel ordre. Il ne dit rien de ce dont le logiciel aura besoin à l'extérieur une fois lancé, ni des identifiants qu'il réclamera, ni des domaines qu'il appellera.

Pour un service web classique, ce trou est comblé par l'infrastructure : règles de pare-feu, secrets injectés par l'orchestrateur, politiques réseau Kubernetes. Pour un agent IA, c'est plus délicat. Un agent de code décide lui-même, au fil de la session, d'appeler une API, de pousser une branche ou de lire un fichier. Son comportement n'est pas figé au moment du build. Le périmètre de ce qu'il peut atteindre devient donc la seule vraie ligne de défense.

MCP (Model Context Protocol) a standardisé la façon dont un agent parle à ses outils. Il restait à standardiser la façon dont on déclare ce que l'agent a le droit de faire avec. C'est l'ambition du Kit.

Ce que contient un Kit

D'après l'article technique de Docker, un Kit est une image OCI ordinaire. Les déclarations de capacités sont stockées dans une annotation du manifeste, vnd.docker.sandbox.kit.descriptor. Conséquence directe : un Kit se construit avec docker buildx build, se pousse sur n'importe quel registre, se signe et se scanne avec les outils existants. Aucun nouveau type d'artefact, aucun nouveau registre à déployer.

La spécification distingue deux familles :

• le Kit de charge de travail (workload), qui fournit le système de fichiers racine et fait tourner l'agent ;
• le Kit mixin, une surcouche qui ajoute une CLI, des règles réseau, des identifiants ou du contexte.

On compose donc un environnement en empilant un workload et plusieurs mixins, par exemple un agent de code plus un mixin GitHub CLI.

Des permissions typées et versionnées

Chaque déclaration porte un type et une version. L'exemple publié par Docker pour le mixin GitHub CLI autorise github.com et l'API GitHub avec une liste de méthodes HTTP, puis interdit explicitement DELETE sur les chemins /repos/** :

capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

La règle est simple : deny l'emporte sur allow. Les versions sont indépendantes par type, si bien que network-policy@1 et network-policy@2 peuvent coexister.

Des secrets que l'agent ne voit jamais

Le type credential règle un problème que toutes les équipes qui outillent des agents connaissent : comment donner un jeton à un agent sans qu'il puisse le lire, le logger ou l'exfiltrer. Avec proxyManaged: true, l'agent ne reçoit qu'une valeur sentinelle. Le vrai jeton est injecté par le runtime, au niveau du proxy, dans l'en-tête Authorization des seules requêtes vers le domaine déclaré. Le processus de l'agent ne manipule jamais le secret.

Une entrée peut être marquée optional: true. Si une entrée obligatoire ne peut pas être satisfaite, le lancement est refusé : le comportement par défaut est l'échec sûr.

L'hôte décide, l'agent demande

Le principe central tient en une phrase : un Kit demande des permissions, l'hôte décide de les accorder. Le Kit n'est pas une autorisation, c'est une requête lisible et vérifiable.

La composition résolue au build

Quand on assemble plusieurs Kits, la spécification impose des règles de cohérence : un seul workload, pas de doublon de fournisseur (pas d'écrasement silencieux), mixins ordonnés par leur graphe de dépendances provides / requires plutôt que par l'ordre de la commande. Les règles réseau s'additionnent, les hooks s'exécutent dans l'ordre des dépendances, les licences se cumulent. Un descripteur kind: set permet de figer un assemblage : un ensemble incohérent échoue au build, pas au lancement.

Les mises à jour sous contrôle

C'est le point le plus utile pour une équipe plateforme. Le runtime enregistre l'ensemble normalisé des permissions accordées. Une nouvelle version du Kit qui reste à l'intérieur de cet ensemble s'applique sans demander. Tout élargissement exige une nouvelle approbation, et la suppression d'une règle deny compte comme un élargissement. Le différentiel présenté à l'approbateur montre précisément ce qui change en termes d'autorité, pas en termes de code.

Un premier runtime conforme, local et cloud

La spécification est portable, mais elle arrive avec une implémentation de référence. Docker Sandboxes est présenté comme le premier runtime conforme : chaque agent tourne dans une microVM avec son propre noyau, ce qui place la frontière d'isolation sous la portée de l'agent, là où un conteneur partage le noyau de l'hôte. La CLI s'appelle sbx :

brew install docker/tap/sbx
sbx run ./hello --kit ./gh .

Le même jour, Docker a lancé en disponibilité générale les Cloud Sandboxes, qui exécutent les mêmes Kits avec le même modèle de confiance sur de la capacité Docker. Une session se déplace dans les deux sens avec sbx move my-project --to cloud. La facturation est à la seconde, de 0,07 $ l'heure pour une microVM 1 vCPU / 2 Gio à 1,12 $ pour 16 vCPU / 32 Gio, avec des sessions d'une heure par défaut, jusqu'à 24 heures.

Côté écosystème, Docker cite des Kits construits avec AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks et Snyk. Le partenariat avec la CNCF vise une gouvernance neutre, condition pour que d'autres runtimes adoptent le format.

Ce que ça change pour les équipes IA

La plupart des équipes que nous accompagnons ont industrialisé leurs modèles avant d'industrialiser leurs agents. Le résultat est familier : un agent de code lancé avec un jeton GitHub personnel à droits larges, un accès réseau non filtré et une configuration qui diffère d'un poste à l'autre. Les permissions des agents IA existent, mais elles sont implicites.

Le Kit apporte trois choses concrètes.

Une source de vérité unique. La réponse à « que peut faire cet agent ? » est attachée à un digest. Elle se relit en revue de code, se versionne dans le même dépôt que l'image, et se compare entre deux versions.

Une chaîne d'approvisionnement déjà outillée. Parce que le Kit est une image OCI, la signature, le scan de vulnérabilités, la politique d'admission et la réplication de registre fonctionnent sans changement. Si vous signez déjà vos images, vous signez déjà vos permissions.

Un contrôle de l'élargissement. La règle « tout élargissement exige une approbation » transforme une mise à jour d'agent en décision de sécurité explicite. C'est exactement le type de garde-fou que demandent les équipes sécurité avant d'ouvrir un agent à un dépôt de production.

Il faut aussi garder les pieds sur terre. La spécification vient d'être publiée et Docker Sandboxes est pour l'instant le seul runtime conforme annoncé. Rien ne garantit encore qu'un orchestrateur Kubernetes ou un autre fournisseur de sandbox appliquera ces déclarations. Et le Kit décrit un périmètre, il ne remplace ni la revue des actions de l'agent, ni la journalisation, ni l'évaluation de son comportement.

Notre recommandation pratique : même sans adopter sbx, commencez à écrire l'équivalent d'un Kit pour vos agents. Listez les hôtes réseau réellement nécessaires, les jetons et leur portée minimale, les volumes. Ce travail d'inventaire est le prérequis de toute politique de permissions des agents IA, quel que soit le runtime retenu demain.

En bref

• Docker a publié le 24 septembre la Sandbox Kit Specification, un format open source (Apache 2.0) qui déclare les permissions d'un agent dans une image OCI.
• Réseau, identifiants et volumes sont typés et versionnés ; deny l'emporte sur allow, et les secrets gérés par proxy ne sont jamais visibles de l'agent.
• L'hôte décide : tout élargissement de permissions lors d'une mise à jour exige une nouvelle approbation.
• Docker Sandboxes (microVM locale) et Cloud Sandboxes (GA, facturé à la seconde) sont les premiers runtimes conformes.
• Pour les équipes IA, les permissions des agents IA deviennent un artefact versionné, signé et révisable.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Barrett Ward on Unsplash.