La plupart des frameworks d'agents supposent aujourd'hui un ordinateur de bureau. Un utilisateur, une machine, un processus. L'agent s'exécute tant que l'ordinateur portable est ouvert, écrit sur un système de fichiers local, conserve les clés API dans les variables d'environnement et meurt lorsque le terminal se ferme. Quand quelque chose se casse, l'utilisateur réessaie. Quand l'agent a besoin d'un paquet, pip install le dépose dans le Python de l'utilisateur. L'état, les secrets et le cycle de vie résident tous à l'intérieur d'une même frontière de confiance.
Une infrastructure d'agent cloud n'a aucun de ces luxes.
L'agent s'exécute dans un bac à sable qui démarre à neuf, sur du matériel partagé avec des inconnus, déclenché par des appelants que l'utilisateur ne rencontre jamais : une planification, une requête HTTP, un autre agent. L'utilisateur dort généralement lorsque l'exécution a lieu. Le code à l'intérieur du bac à sable peut être adversarial. Le système de fichiers doit survivre aux déploiements. Les identifiants ne peuvent pas vivre là où vit l'agent. Chaque garantie que le bureau vous donne gratuitement — persistance, identité, confiance réseau, nouvelle tentative — doit être reconstruite en tant que système explicite.
Nous avons passé les derniers mois à resserrer cette couche chez CREAO. Deux leçons en sont ressorties. Si vous avez déjà livré un agent de bureau et vous êtes demandé ce qui change lorsqu'il passe au cloud, voici ce qui change.
Leçon 1 : Séparez ce qui change lentement de ce qui change vite
Sur un bureau, l'environnement de l'utilisateur et l'environnement d'exécution de l'agent sont la même chose, mis à jour au même rythme, par la même personne. Dans le cloud, ce n'est pas le cas.
Une application d'agent accumule de l'état du côté de la plateforme. Un analyste boursier installe matplotlib, télécharge des données de marché, écrit des scripts de création de graphiques. Cet environnement est la mémoire musculaire de l'agent. Nous le figeons dans un instantané du bac à sable au moment où l'utilisateur en est satisfait, et nous conservons cet instantané gelé jusqu'à ce que l'utilisateur modifie à nouveau l'environnement. Chaque exécution démarre à partir de la même image. Mêmes paquets, mêmes fichiers, mêmes versions. L'exécution de lundi se comporte comme celle de vendredi, car rien en dessous n'a bougé.
C'est la propriété que les frameworks de bureau ne peuvent pas vous offrir gratuitement. Un pip install d'il y a six mois résout aujourd'hui en différentes versions. Un instantané cloud résout les mêmes octets pour toujours. La reproductibilité est ce que la plateforme doit à l'utilisateur, et un instantané gelé est le moyen le moins coûteux de la fournir.
Ensuite, le problème de couplage apparaît.
La même image qui gèle l'environnement de l'utilisateur contient également le code d'exécution — la petite bibliothèque d'infrastructure développée par nous qui gère l'agent à chaque exécution. L'utilisateur veut que son environnement reste immobile. Nous voulons que notre exécuteur soit livré plusieurs fois par jour. Un artefact, deux exigences opposées.
Notre premier correctif était brutal. Au démarrage, vérifier si l'exécuteur à l'intérieur de l'instantané correspond à la version que nous venons de déployer. Si ce n'est pas le cas, jeter l'instantané et démarrer à partir d'un modèle propre. Cela a fonctionné, et personne ne s'est plaint. Les dégâts n'ont touché que la première exécution après un déploiement.
Les exécutions non supervisées ont éliminé cette couverture. Un cron job à 9h le lundi ne devrait pas perdre son environnement parce que nous avons déployé à 8h55. Le contrat que nous violions tranquillement — « votre environnement est gelé jusqu'à ce que vous le changiez »
Nous avons mis plus de temps que nécessaire à apercevoir cette solution. L'environnement de l'utilisateur et le code d'exécution changent à des vitesses complètement différentes. L'utilisateur modifie son agent quand il le souhaite. Nous déployons la plateforme plusieurs fois par jour. Les traiter comme un seul artefact imposait un choix à chaque déploiement : conserver le code d'exécution obsolète, ou détruire l'environnement gelé que l'utilisateur nous avait explicitement demandé de préserver.
Le modèle sur lequel nous avons atterri s'inspire de la façon dont les systèmes d'exploitation gèrent les mises à jour. Le noyau change. Votre répertoire personnel ne change pas. Vous n'effacez pas le disque pour installer un correctif de sécurité.
Nous avons tracé la même frontière. Le bac à sable démarre à partir de l'instantané gelé de l'utilisateur, intact. Ensuite, nous effectuons un remplacement à chaud uniquement de l'exécuteur. La séquence :
- Placer le nouvel exécuteur dans un répertoire temporaire à l'intérieur du bac à sable.
- Le valider avec node --check pour que toute erreur de syntaxe soit détectée avant de toucher quoi que ce soit en direct.
- Le remplacer de manière atomique : déverrouiller le flag immuable sur l'ancien exécuteur, copier le nouveau, reverrouiller avec chattr +i, puis cacher le binaire chattr lui-même pour que le code du bac à sable ne puisse pas inverser le verrouillage.
- Vider le cache de compilation V8 (/home/user/.cache/v8-compile-cache/*) pour que le nouveau fichier se charge réellement au lieu d'exécuter du bytecode obsolète.
- Si une étape échoue, tuer le bac à sable et réessayer avec un nouveau. Aucun état semi-mis à jour ne fait jamais tourner un agent.
L'ensemble du remplacement prend environ 300 millisecondes. Nous ne prenons un nouvel instantané après une exécution réussie que lorsque le code d'exécution a été remplacé, intégrant le code mis à jour dans l'image de l'utilisateur afin que l'exécution suivante saute complètement le remplacement. Les déploiements de la plateforme ne jettent jamais l'état de l'utilisateur ; ils y intègrent le nouvel exécuteur. Les paquets, fichiers et personnalisations de l'utilisateur sont conservés inchangés.
Si vous ne retenez qu'une chose de cette leçon, c'est la question de diagnostic. Pour tout ce que vous persistez dans une plateforme cloud, demandez : qui contrôle la cadence de changement sur cet artefact ? Si l'utilisateur et la plateforme le possèdent tous deux, vous finirez par payer pour le couplage. Divisez l'artefact le long de la frontière de propriété et laissez chaque côté se mettre à jour à sa propre cadence.
Leçon 2 : Gardez les secrets hors de la frontière d'exécution
C'est la leçon qui sépare l'infrastructure d'agent cloud de tout le reste.
Un agent de bureau s'exécute en tant qu'utilisateur. Il utilise les clés de l'utilisateur, sur la machine de l'utilisateur, sur le réseau de l'utilisateur. Un agent cloud s'exécute en tant que personne, sur du matériel partagé, sur l'internet ouvert, exécutant du code qu'un LLM a écrit à partir d'une invite qui peut avoir été antagoniste. Le modèle de sécurité doit supposer que le code à l'intérieur du bac à sable est déjà compromis, et non pas espérer le contraire.
La règle que nous maintenons est simple. Aucun identifiant de longue durée ne vit jamais à l'intérieur du bac à sable.
Lorsqu'un agent doit appeler un service authentifié — Slack, GitHub, l'API propre de l'utilisateur — il ne détient pas le jeton. Il envoie une requête HTTP locale à un pont API s'exécutant en dehors du bac à sable. Le pont attache le jeton OAuth du côté hôte et transmet l'appel. La réponse revient sans que le jeton ne pénètre jamais dans la mémoire ou l'environnement du bac à sable.
La partie intéressante est la façon dont le pont sait que le bac à sable est autorisé à demander. Deux vérifications, en couches intentionnellement.
Premièrement, liste blanche IP. Le pont n'accepte les connexions que depuis la plage réseau interne sur laquelle vivent nos hôtes de bac à sable. Un appel provenant d'ailleurs — un ordinateur portable de développeur, une URL divulguée, l'internet public — est abandonné au niveau réseau avant que tout code d'application ne s'exécute. Cela épingle le pont à une seule infrastructure physique et le rend inutile à quiconque en dehors de celle-ci.
Deuxièmement, un JWT de courte durée émis par exécution. Lorsqu'un bac à sable démarre, la plateforme signe un jeton limité à cette exécution spécifique : quel utilisateur, quelle application, quelle session, avec une expiration qui couvre la fenêtre d'exécution et rien de plus. Le bac à sable le présente à chaque appel au pont. Le pont vérifie la signature, vérifie l'expiration, et seulement alors résout les identifiants stockés de l'utilisateur et les attache côté serveur. Si un bac à sable est détourné, l'attaquant hérite d'un jeton qui meurt avec l'exécution et n'autorise que les appels limités à cette session. Il n'y a pas d'identifiant maître à voler.
Le même pont transporte les déductions de facturation, les journaux et les métriques vers l'extérieur, c'est donc l'interface unique qui traverse la frontière du bac à sable dans les deux directions. Tout le reste à l'intérieur du bac à sable est traité comme compromis par défaut.
Si une injection d'invite convainc demain un agent de vider processus.env vers un webhook, l'attaquant obtient un JWT de courte durée qui ne fonctionne que depuis l'intérieur de notre réseau et expire avec l'exécution. C'est cette propriété qui nous permet d'exécuter du code utilisateur non fiable sur une infrastructure partagée sans perdre le sommeil.
Le modèle sous-jacent
Une infrastructure d'agent cloud fiable et sécurisée n'est pas un système nouveau. C'est quelques propriétés maintenues sans exception :
- L'état vit dans le bac à sable, gelé jusqu'à ce que l'utilisateur le modifie.
- Le code est remplaçable à chaud, indépendant de l'état.
- Les identifiants vivent côté hôte, jamais à l'intérieur de l'agent.
- Un pipeline d'exécution unique sert tous les appelants, que le déclencheur soit un humain, un planificateur ou un autre logiciel.
Cette dernière propriété est la chute de tout le design. Une seule fonction executeAgent gère les clics UI, les exécutions planifiées et les appels API. Le système de facturation, les journaux de déduction de crédits, les signaux d'observabilité — tous identiques, qu'un humain ait cliqué sur Exécuter, qu'un cron ait été déclenché ou qu'un script ait appelé l'API. Ajouter une nouvelle surface de déclenchement est un changement de routage, pas un changement d'architecture. L'agent lui-même ne sait ni ne se soucie de qui a appuyé sur la gâchette.
C'est ce que les frameworks de bureau ne peuvent pas vous offrir, et ce qui rend la version cloud digne d'être construite. Un agent sur un ordinateur portable est lié à l'ordinateur portable. Un agent dans le cloud est une fonction que le reste de votre pile peut appeler. L'utilisateur l'écrit une fois. La plateforme la fait survivre aux déploiements, s'exécuter en toute sécurité sur du matériel partagé et accepter des appelants que l'utilisateur n'avait jamais anticipés.
Un agent est une fonction avec une interface en langage naturel. Son implémentation appartient à l'utilisateur. Sa surface de déclenchement, son environnement d'exécution, sa frontière de sécurité appartiennent à la plateforme. La discipline consiste à construire les couches pour que chacune évolue à sa propre cadence, et à passer le temps à trouver les fissures entre les systèmes avant que quelqu'un d'autre ne le fasse.
C'est ce qui rend la prochaine surface bon marché à livrer, et sûre à livrer.
