Où s'exécute le code que votre agent écrit

OUTILS IA — L'AGENT QUI AGIT · OÙ TOMBE LE CODE QUE PERSONNE N'A RELU

Caractéristiques relevées le 25 juillet 2026 sur la documentation officielle des technologies d'isolation citées et sur celle d'un fournisseur de bacs à sable. Aucune infrastructure n'a été déployée pour cet article : le protocole de vérification, en fin de page, est à dérouler chez vous.

Un agent qui écrit du code produit un texte inerte. Un agent qui exécute le code qu'il vient d'écrire produit un processus, avec un système de fichiers sous la main, une pile réseau, et tout ce que le système d'exploitation voudra bien lui accorder. Entre les deux, il n'y a qu'une ligne de configuration, et cette ligne est passée d'un usage marginal à l'usage courant en dix-huit mois.

La question n'est plus de savoir si l'on autorise cette exécution : les outils d'analyse de données, les agents de développement et les assistants qui produisent des graphiques la pratiquent tous. La question est de savoir où elle se produit, et ce qui sépare ce processus du reste de vos systèmes. Cette frontière porte un nom générique — le bac à sable — qui recouvre au moins trois architectures aux garanties très inégales.

Le conteneur ordinaire n'a jamais été une frontière de sécurité

C'est le malentendu fondateur. Un conteneur isole des vues : espaces de noms pour les processus, le réseau et le système de fichiers, limites de ressources, filtres d'appels système. Il ne duplique pas le noyau. Tous les conteneurs d'une machine parlent au même noyau hôte, et une faille dans ce noyau est une faille pour tout le monde à la fois.

Tant que les conteneurs d'une même machine appartiennent à la même équipe et exécutent du code écrit par cette équipe, la question reste théorique. Elle cesse de l'être à l'instant précis où le code exécuté a été produit par un modèle, à partir d'une consigne qu'un tiers a pu influencer. La confiance placée dans le code n'est alors plus une hypothèse de travail : c'est le paramètre que l'on cherche à retirer de l'équation.

Deux réponses industrielles existent, et elles ne posent pas le mur au même endroit.

Première réponse : un noyau applicatif entre le code et l'hôte

La première approche consiste à intercaler un noyau écrit en espace utilisateur. Sa documentation le décrit ainsi : « gVisor provides a strong layer of isolation between running applications and the host operating system. It is an application kernel that implements a Linux-like interface » — une couche d'isolation forte, sous la forme d'un noyau applicatif qui implémente une interface de type Linux. Il est « written in a memory-safe language (Go) and runs in userspace ».

La documentation prend soin d'écarter deux confusions courantes : ce n'est « not a syscall filter (e.g. seccomp-bpf), nor a wrapper over Linux isolation primitives », et ce n'est pas non plus « a VM in the everyday sense of the term ». La phrase qui compte se trouve dans le guide d'architecture : « No system call is passed through directly to the host. Every supported call has an independent implementation in the Sentry » — aucun appel système n'est transmis tel quel à l'hôte, chaque appel pris en charge est réimplémenté.

C'est là toute l'idée. La surface d'attaque exposée par un conteneur ordinaire est celle de l'interface système complète du noyau hôte. Le noyau applicatif la remplace par sa propre implémentation et ne conserve avec l'hôte, selon la même documentation, que trois familles d'interactions : le dialogue avec un processus dédié au système de fichiers, un jeu minimal d'appels système qui exclut l'ouverture de fichiers et la création de connexions, et la lecture-écriture de paquets sur une interface réseau virtuelle.

Seconde réponse : une machine virtuelle, mais minuscule

L'autre voie consiste à rétablir une vraie frontière matérielle, tout en supprimant ce qui rendait les machines virtuelles inutilisables pour ce genre d'usage : le temps de démarrage et l'empreinte mémoire. C'est le pari des microVM. La page officielle de l'une d'entre elles annonce une technologie « purpose-built for creating and managing secure, multi-tenant container and function-based services », et publie des chiffres précis.

Un détail de conception mérite d'être relevé, parce qu'il en dit long sur l'état d'esprit. Chaque instance est encadrée par un programme compagnon dont la documentation précise la fonction : « The jailer provides a second line of defense in case the virtualization barrier is ever compromised » — une seconde ligne de défense au cas où la barrière de virtualisation viendrait à céder. Autrement dit, l'éditeur prévoit par écrit l'échec de sa propre barrière principale. C'est la marque d'une conception sérieuse, et un rappel utile : aucune des deux approches ne prétend à l'imperméabilité.

Fig. 1 — Trois façons d'exécuter du code que personne n'a relu. Ce qui distingue les trois colonnes n'est pas leur nom, c'est la hauteur à laquelle passe la frontière : au-dessus du noyau hôte pour le conteneur ordinaire, entre l'application et l'hôte pour le noyau applicatif, au niveau du matériel pour la microVM. Chaque déplacement vers le bas achète de l'isolation et coûte quelque chose.

Ce que l'isolation ne règle pas

Une barrière parfaite autour d'un processus laisse intactes trois questions, et ce sont celles qui font les incidents réels.

Le réseau. Un bac à sable qui accède à Internet peut faire sortir ce qu'il contient. C'est exactement pour cette raison qu'un éditeur d'agents de code documente que l'accès réseau est bloqué par défaut pendant la phase d'exécution, et qu'il nomme l'exfiltration de code ou de secrets parmi les risques encourus. La frontière la plus solide du monde est sans objet si l'on a percé une porte dedans pour la commodité.

Ce que vous mettez à l'intérieur. Un jeton d'accès, une clé d'interface applicative ou une chaîne de connexion injectés dans l'environnement pour que le code « puisse travailler » traversent la barrière avec lui. Le bac à sable protège l'extérieur du code, pas le code de lui-même. Sur ce partage entre ce qu'un agent doit pouvoir atteindre et ce qu'il ne doit jamais détenir, notre article sur les accès à consentir à un agent donne la méthode.

L'origine des consignes. Un environnement parfaitement cloisonné exécutera avec la même docilité un code utile et un code dicté par un contenu hostile rencontré en chemin — c'est l'injection de prompt, cette faille sans correctif. L'isolation limite le rayon de l'explosion ; elle n'empêche pas l'allumette.

La durée de vie est un paramètre de sécurité

Voici le réglage le plus souvent négligé, et le plus révélateur. La documentation d'un fournisseur de bacs à sable l'expose en une phrase : « Sandboxes can run continuously for up to 24 hours (Pro) or 1 hour (Base) » — vingt-quatre heures dans la formule supérieure, une heure dans la formule de base.

Un bac à sable qui vit une heure est un bac à sable. Un bac à sable qui vit vingt-quatre heures est une machine, avec un état qui s'accumule, des fichiers laissés par la tâche précédente, et un processus compromis qui a tout le temps d'attendre la suivante. La longévité n'est pas une amélioration du produit : c'est un curseur qui échange de la commodité contre de la surface d'exposition, et qui doit être réglé consciemment.

Choisir sans se tromper de question

La question utile n'est pas « quelle est la technologie la plus sûre ». C'est : que se passe-t-il si le code qui s'exécute là est hostile ? La réponse dépend de ce qui partage la machine.

Si le bac à sable n'exécute que du code produit pour vous, à partir de consignes que vous maîtrisez, et sur une machine qui ne porte rien d'autre, un conteneur ordinaire assorti d'un filtre d'appels système strict et d'un réseau fermé constitue une réponse honnête. Si la même machine héberge plusieurs clients, plusieurs équipes ou plusieurs niveaux de confiance, la frontière doit remonter d'un cran — noyau applicatif ou microVM — et ce n'est plus une question de préférence technique.

Le critère de bascule est celui de la colocation. Tant que le voisinage est de confiance, l'isolation légère suffit. Dès que le voisinage devient inconnu — et un agent exposé à des consignes venues de l'extérieur rend le voisinage inconnu par construction, comme le montre le cas des assistants que l'on ouvre au public dans notre article sur l'assistant conversationnel que vous exposez — l'isolation légère devient un pari.

🔬 Comment le vérifier vous-même

Les chiffres publiés par les éditeurs décrivent leurs conditions, pas les vôtres. Quatre mesures suffisent à trancher, et aucune ne demande plus d'une journée.

Il y a une raison pour laquelle ce sujet, jusqu'ici réservé aux hébergeurs, arrive sur le bureau des équipes qui construisent avec des modèles. Pendant vingt ans, la sécurité applicative supposait qu'on savait quel code allait s'exécuter. Cette hypothèse vient de tomber : le code est produit au moment de la requête, à partir d'une consigne qu'un tiers peut avoir teintée. Quand on ne peut plus faire confiance au contenu, il reste à faire confiance au contenant — et à connaître, chiffres à l'appui, ce que ce contenant garantit vraiment. Sur ce que l'on peut raisonnablement attendre d'un agent en général, notre article sur la confiance que l'on peut placer dans un agent pose le cadre.

Cet article est le quatrième de la série Outils IA — l'agent qui agit. Le dernier quitte la technique pour le droit : à partir du 2 août 2026, une modification suffisamment lourde d'un modèle existant peut faire de vous, sans que vous l'ayez voulu, le fournisseur de ce modèle au sens du règlement européen. Sur ce que ces agents savent faire d'un poste de travail complet, notre article consacré aux agents à usage ordinateur pose le socle.

Une question, un projet IA ?

Vous voulez exécuter du code produit par un modèle sans exposer le reste de vos systèmes ? Échangeons sur votre contexte.

Prendre contact →