On est pas mal à se poser la même question en ce moment : comment gérer la sécurité et les accès quand nos agents se mettent à exécuter du code, appeler des API et manipuler le système de fichiers ?
Chez WeScale, comment bien développer avec des agents est un sujet qu’on creuse en permanence, et poser des garde-fous dès la conception en fait partie.
Le premier réflexe, quand on est dev ou archi, c’est de regarder du côté du langage : utiliser une syntaxe basée sur les capabilities (des droits d’accès transmis explicitement, comme des clés : sans clé, pas d’accès), où le réseau, les fichiers ou la mémoire sont déclarés dès la configuration du composant. L’intérêt : pouvoir auditer le périmètre d’un agent en un coup d’œil et évaluer immédiatement la criticité de ce qu’on déploie.
C’est ce que cartographie le site agentlanguages.dev, un projet d’Alasdair Allan qui recense plus d’une quarantaine de langages expérimentaux pensés spécifiquement pour être écrits par des IA. Le site divise cette dynamique en trois grands « camps » :
Le camp Syntaxe : réduire le coût en tokens et lever les ambiguïtés (ex. remplacer les symboles par des mots-clés comme NERD ou sérialiser les AST en JSON comme X07).
Le camp Sémantique / Vérification : accepter que le LLM va faire des erreurs, mais rendre le code mécaniquement vérifiable via des contrats explicites et des preuves SMT (comme Vera ou AILANG).
Le camp Orchestration : considérer que ce n’est pas un problème de syntaxe mais de coordination, de bac à sable et de traçabilité d’exécution (comme Boruna).
Ce champ de recherche reste très émergent. La plupart de ces projets sont aujourd’hui au stade d’expérimentations, de preuves de concept ou de travaux académiques. On est très loin d’outils prêts pour la prod.
Pour qu’un de ces langages passe du laboratoire au standard industriel, il ne suffit plus de convaincre des développeurs. Il faut aussi que les modèles sachent écrire dans ce langage.
Un agent a besoin d’une énorme quantité de lignes de code validées pour devenir performant dans un langage. Mais pour générer cette masse de données publiques, il faut déjà une adoption massive par la communauté.
Sans données, pas d’agent efficace. Sans agent efficace, pas d’adoption.
WebAssembly (Wasm) s’est imposé comme un standard de bytecode portable. Conçu à l’origine pour accélérer le web, son usage s’étend désormais aux environnements serveur, à l’edge computing et aux architectures d’extension.
En pratique, des langages comme Rust, Go ou C sont compilés vers ce format avant d’être pris en charge par un runtime dédié comme Wasmtime dans un bac à sable. C’est cet usage hors du navigateur qui nous intéresse ici : Wasm fonctionne comme un bac à sable très léger, et c’est l’hôte qui décide de ce que le programme a le droit de toucher.
Concrètement, trois mécanismes font le travail :
La spécification Wasm Core (W3C) impose le modèle de Linear Memory : un module ne possède aucun pointeur vers l’hôte et ne manipule que son propre tableau de bytes, dont chaque accès est vérifié. Un accès hors limites provoque un arrêt (trap) au lieu de corrompre la mémoire de l’hôte, comme l’avait formalisé le papier fondateur Haas et al., PLDI 2017.
Mais Wasm protège l’hôte contre le module, pas le module contre lui-même. Un buffer overflow reste possible à l’intérieur de sa mémoire linéaire.
WASI, l’équivalent des appels système pour Wasm, applique le principe du deny-by-default : par défaut, un module n’a accès à rien. Il s’appuie sur une sécurité par capabilities : un module ne peut accéder ni au disque ni au réseau sans que l’hôte lui transmette explicitement une ressource (ex. preopened directories).
Depuis WASI 0.2, construit sur le Component Model, ces interfaces sont typées et déclarées en WIT. Le world d’un composant liste donc les familles d’accès dont il a besoin, tandis que la politique fine (domaines autorisés, répertoires montés) reste définie par l’hôte.
Le code peut être écrit ou généré dans des langages bien maîtrisés par les LLM. Rust et Go (via TinyGo) se compilent directement vers Wasm. Python et JavaScript passent par un interpréteur embarqué, ce qui alourdit le module et limite l’usage des bibliothèques natives comme numpy.
Côté contrôle, un runtime comme Wasmtime peut plafonner le CPU et la mémoire, pour qu’un agent ne boucle pas indéfiniment ou ne sature pas l’hôte.
En pratique, la plupart des sandboxes d’agents reposent aujourd’hui sur l’une de ces trois techniques :
Des microVM : des machines virtuelles réduites au strict minimum, qui démarrent en une fraction de seconde (ex. Firecracker, le moteur d’AWS Lambda).
gVisor : un noyau intermédiaire, développé par Google, qui intercepte les appels système d’un conteneur pour l’isoler de la machine hôte.
Des isolates V8 : des environnements d’exécution cloisonnés au sein du moteur JavaScript de Chrome, utilisés par exemple par Cloudflare Workers.
Face à elles, Wasm offre des capabilities plus fines, un démarrage quasi instantané. En contrepartie, son écosystème est moins complet, surtout pour Python et ses dépendances natives. Les approches peuvent aussi se combiner, par exemple des composants Wasm exécutés dans une microVM.
Cloudflare a lancé en mars 2026 ses Dynamic Workers, qui exécutent à la volée du code non fiable, avec en tête de liste celui généré par des agents. L’hôte y choisit les ressources accessibles et peut bloquer ou filtrer le réseau sortant, une logique proche des capabilities.
En octobre 2026, Cloudflare a aussi racheté Deno, surtout pour rendre Workers auto-hébergeable. Deno appliquait déjà le deny-by-default au niveau du runtime JavaScript, avec des permissions explicites par domaine ou par répertoire (--allow-net=api.exemple.com). La philosophie est très proche de WASI, limitée à l’écosystème JS/TS. Et les deux mondes ne s’excluent pas, puisque Workers comme Deno savent exécuter des modules Wasm.
Côté Wasm, des projets concrets existent déjà : Wassette (Microsoft) exécute des outils MCP (les outils qu’un agent peut appeler via le Model Context Protocol) sous forme de composants Wasm.
Ce que ça change en pratique pour une architecture agentique :
Le world WIT d’un composant indique immédiatement s’il demande des accès réseau ou système, indépendamment de la complexité du code généré. Couplé à la configuration de l’hôte (domaines et répertoires autorisés), il donne une vision complète du périmètre de l’agent.
Même en cas de prompt injection, le code ne sortira pas des accès accordés. Mais Wasm ne contrôle pas l’usage de ces accès : un composant autorisé à appeler une API avec un token peut toujours être détourné pour exfiltrer des données par ce canal légitime.
Le runtime doit donc être complété par :
une allow-list réseau stricte ;
des secrets injectés par l’hôte, plutôt que visibles par le code ;
une validation humaine pour les actions sensibles.
Et les runtimes eux-mêmes ont eu des failles (CVE).
Les langages pour agents et les runtimes isolés sont complémentaires : plusieurs de ces langages ciblent Wasm. Pour moi, ces langages vont rester expérimentaux un bon moment et c’est le runtime qui portera la sécurité.
Avec une réserve quand même : le problème d’adoption ne se pose pas pour ceux qui entraînent leurs propres modèles, comme Anthropic, Google ou Microsoft. S’ils décident de sortir un langage pour leurs agents, ils ont les moyens de l’imposer rapidement.
webassembly.org : site officiel du standard WebAssembly, présentation, cas d’usage et spécifications.
agentlanguages.dev : catalogue des langages conçus pour être écrits par des IA (Alasdair Allan).
W3C WebAssembly Core Specification : spécification officielle (W3C).
Haas et al., Bringing the Web up to Speed with WebAssembly, PLDI 2017 : papier fondateur de Wasm.
WASI (GitHub) : spécification WASI.
Bytecode Alliance : Wasmtime, Component Model, WASI.
Wassette (Microsoft) : runtime d’outils MCP sous forme de composants Wasm.
Cloudflare Dynamic Workers (InfoWorld, mars 2026) : isolates V8 pour l’exécution de code généré par des agents.
Ryan Dahl rejoint Cloudflare (DevClass, octobre 2026) : rachat de Deno, objectif Workers auto-hébergeable.