Isolation des agents IA : par agent ou par personne ?

Toutes les plateformes d'agents sérieuses ont convergé vers la même réponse : pour qu'un agent fasse du vrai travail, il lui faut un ordinateur. Un écran, un système de fichiers, un navigateur, un terminal. Ce débat est clos.

La question juste en dessous ne l'est pas, et presque personne ne la pose publiquement. À qui appartient cet ordinateur ? Un par utilisateur, un par équipe, ou un par agent ? Ce choix décide de ce qui arrive quand un seul agent déraille, et il se règle discrètement, dans de la documentation, par celui qui livre en premier.

Où se situe la frontière d'isolation aujourd'hui

Trois positions coexistent, toutes en production.

Par session. Rien ne persiste, donc rien n'est partagé. E2B et Browserbase sont là : une sandbox ou une session de navigateur vit le temps d'une tâche, puis disparaît. L'isolation est un effet de bord du caractère jetable de l'environnement, ce qui explique aussi pourquoi le travail étalé sur plusieurs jours n'y rentre pas.

Par utilisateur. Une machine persistante appartient à une personne, et tous les agents qu'elle lance y travaillent. Grok Bot en est l'exemple le plus net. Claude Cowork y aboutit autrement : l'agent tourne dans une machine virtuelle sur le portable devant vous, qui est celui d'une seule personne.

Par agent. Chaque agent reçoit sa propre machine, persistante et inatteignable par les autres. C'est la position de SpineOS. Un projet auto-hébergé comme Bytebot ou Cua peut être configuré ainsi : quand vous opérez l'infrastructure, la frontière est celle que vous construisez.

Ce que signifie vraiment un ordinateur partagé entre agents IA

Que tous les agents lancés par une même personne lisent et écrivent les mêmes fichiers, pilotent le même navigateur et héritent des mêmes sessions ouvertes.

Grok Bot, lancé par xAI en août 2026, en est l'implémentation de référence, et sa documentation est d'une franchise inhabituelle. Extrait de la FAQ Grok Bot, en réponse à « Mes Bots partagent-ils un ordinateur ? » :

Yes. Every Bot on your account uses one persistent cloud computer. They share its files, browser sessions, and logins so they can hand work off. The computer is assigned per user, not per Bot. Do not use separate Bots as a security boundary.

Tous les Bots d'un compte partagent donc un même ordinateur persistant, ses fichiers, ses sessions et ses connexions, et xAI conclut : n'utilisez pas des Bots distincts comme frontière de sécurité. Un éditeur qui prévient ses propres utilisateurs contre ce qu'ils croiront spontanément : bonne documentation, et toute la question de conception en une phrase.

Leur documentation équipes va plus loin : « Bots isolate personalities and workspaces, not compute. » Les Bots isolent des personnalités et des espaces de travail, pas du calcul.

Ce que le modèle par utilisateur fait bien

Deux choses, qu'il serait malhonnête de passer sous silence.

Entre utilisateurs, la séparation est solide. xAI décrit chaque ordinateur comme une micro-machine virtuelle Firecracker « with its own kernel, memory, and virtual devices », et affirme qu'un utilisateur ne peut pas atteindre l'ordinateur d'un autre. Frontière matérielle, pas artifice logiciel.

C'est la gestion des identifiants qu'un lecteur averti remarquera. Leur documentation sécurité indique qu'« un Bot n'a ni identité ni identifiants propres », qu'il agit en tant que membre connecté, et que les jetons de connecteur ne sont jamais stockés sur l'ordinateur. Un agent hérite des accès de la personne à qui il appartient, sans jamais les dépasser.

L'exposition réelle n'est donc pas que vos jetons traînent sur une machine commune. C'est la surface que les agents partagent en travaillant : un système de fichiers, un profil de navigateur, un jeu de sessions ouvertes, sur un même disque durable.

Pourquoi la surface partagée est le vrai sujet

Parce que les défaillances réalistes d'un agent ne sont pas le vol d'identifiants, mais l'empoisonnement d'instructions et l'erreur ordinaire. Les deux circulent par les fichiers et l'état du navigateur. Trois conséquences.

Un agent qui lit le web ouvert devient un canal. S'il consigne sa veille dans un fichier et qu'un second agent lit ensuite ce fichier, tout ce que le premier a été persuadé d'écrire devient une instruction pour le second. Aucun des deux n'a mal travaillé. C'est le disque qui a transporté la charge.

Un profil de navigateur connecté authentifie tous les agents pareillement : cookies et sessions ne sont pas rattachés à une personnalité. Si un agent se connecte à votre outil de facturation, tous les autres le sont aussi.

Les erreurs cessent d'être locales. Un script de nettoyage au mauvais chemin, un fichier de configuration réécrit au mauvais format, et c'est tous les agents d'un coup.

Rien de cela ne rend Grok Bot négligent : c'est un arbitrage assumé, documenté publiquement, consenti en échange de quelque chose que les utilisateurs veulent.

Les arguments pour une isolation par agent

La frontière devrait correspondre à l'unité de défaillance, et cette unité, c'est l'agent. Trois arguments, par ordre d'importance pratique.

La portée. Quand quelque chose a mal tourné, la seule question utile est : jusqu'où cela pouvait-il aller ? Par agent, une machine et un disque connus. Par utilisateur, tout ce que vos agents ont touché depuis le début, plus chaque site où l'un d'eux reste connecté.

L'attribution. Sur un disque commun, un fichier qui ne devrait pas exister n'a pas d'auteur. Restent les journaux, si la plateforme les a gardés, et la déduction. Donnez à chaque agent son système de fichiers et ce système devient la trace : ce qui est sur la machine, c'est ce que cet agent a fait.

Une révocation exécutable. Détruire un bureau met fin à l'exposition en une action. Sur une machine commune, supprimer un agent supprime une personnalité et laisse chaque fichier écrit et chaque session ouverte.

C'est ainsi que SpineOS est construit. Un bureau cloud par agent, chacun sur sa machine virtuelle avec son disque persistant, isolé de tous les autres au niveau réseau, hébergé en France. Cinq types d'agents y tournent : Claude Code, OpenClaw, Codex, Hermes et Grok CLI. Éditeurs différents, agents différents, machines différentes.

Ce que coûte l'isolation par agent

Elle casse le passage de relais, et le reconstruire est un vrai chantier.

Sur un ordinateur partagé, le relais est gratuit. L'agent A enregistre un rapport, l'agent B l'ouvre. L'agent A se connecte à un outil, l'agent B utilise la session. xAI en fait la raison même de sa conception : fichiers, sessions et connexions sont partagés pour que les Bots se passent le travail. Pas de tuyauterie, pas de protocole, pas de schéma.

Isolez les agents et tout cela disparaît d'un coup. Deux agents qui ne voient pas le système de fichiers l'un de l'autre ne se transmettent rien par défaut. Vous avez remplacé un dossier par un problème de systèmes distribués. Qui vous dit que l'isolation est gratuite n'en a pas construit la seconde moitié.

Comment une base de connaissances partagée répond au problème

En remplaçant une machine partagée implicite par une surface partagée explicite, et en gardant le reste séparé.

Sur SpineOS, les agents appartiennent à un espace de travail doté d'une base de connaissances que chaque bureau lit et écrit. L'agent qui termine une recherche l'y consigne. Un autre la reprend à son exécution suivante. Les bureaux restent séparés : disques, navigateurs, processus. La seule chose commune est celle que vous avez décidé de partager.

Le canal implicite devient auditable. Ce qui circule entre agents est un ensemble de fichiers à un endroit connu, avec un historique, plutôt que l'état complet d'une machine.

Là où cette réponse reste imparfaite

Une base de connaissances partagée reste une surface partagée, et le partage explicite demande un effort que l'implicite ne demande pas. Quatre limites, nommées, parce qu'un éditeur qui n'énumère que ses forces ferait ce que cet article reproche.

C'est un canal. Une note écrite par un agent ayant lu une page hostile reste hostile quand l'agent suivant la lit. L'isolation ramène la surface partagée de « tout » à « un répertoire inspectable ». Elle ne dispense pas de traiter la sortie d'un agent comme une entrée non fiable.

Cela demande de la discipline. Le partage implicite a lieu qu'on y pense ou non, d'où son confort et son danger. Un agent qui ne consigne rien ne transmet rien.

L'état vivant ne traverse pas. Session de navigateur, processus en cours, outil à moitié configuré : rien ne survit à une frontière de machine. Chaque bureau établit ses propres connexions, propriété de sécurité la plupart du temps, friction le reste du temps.

La coordination est plus lente. Se passer le travail par des artefacts écrits coûte plus que partager un système de fichiers déjà commun. L'arbitrage nous paraît juste. Nous ne prétendons pas qu'il est gratuit.

Comment choisir votre frontière

Demandez-vous ce qu'un seul agent entièrement compromis pourrait atteindre, et placez la frontière là.

• Une personne, un agent à la fois, du travail sans rien de sensible : une sandbox par session suffit, et coûte moins cher.
• Une personne, plusieurs agents sur un même dossier, le confort primant sur la séparation : une machine par utilisateur se défend, à condition d'avoir lu la phrase sur les Bots qui ne sont pas une frontière de sécurité, et d'y croire.
• Plusieurs agents à des niveaux de confiance différents, ou quoi que ce soit touchant l'argent, les données clients ou la production : par agent, en budgétant le mécanisme de relais.

La question qui tranche n'est pas architecturale : si l'agent chargé de la veille sur le web ouvert était compromis à l'instant, à quoi d'autre touche-t-il ? Cette réponse est votre vraie frontière, quel que soit le schéma.

La suite

La première question a été tranchée vite : les agents ont un ordinateur, et cela ne reviendra pas.

La seconde est : combien d'ordinateurs ? Elle se règle par des choix par défaut plutôt que par un débat. Or un défaut devient un présupposé, et les utilisateurs présupposent que leurs agents sont séparés. xAI a dû publier une phrase disant l'inverse : le présupposé circule déjà.

L'isolation par agent est le choix par défaut qui le rend vrai.

---

SpineOS donne à chaque agent IA son propre bureau cloud persistant : machine dédiée, disque propre, navigateur propre, isolé de tous les autres bureaux, hébergé en France. Gratuit pendant la bêta, Pro à 49 euros par mois jusqu'à trois agents, Max à 149 euros jusqu'à dix avec espaces de travail partagés. Essayez.