
# Runtime WASM basé sur les capacités pour exécuter du code généré par IA non fiable Runtime WASM basé sur les capacités pour exécuter du code généré par IA non fiable avec des limites imposées sur le CPU, la mémoire, le temps, les E/S et le système de fichiers. Offre une exécution à chaud en moins d'une milliseconde, des enregistrements d'exécution signés et un serveur MCP pour l'intégration.
Exécution WASM rapide et basée sur les capacités avec des limites explicites de CPU, mémoire, temps, E/S et système de fichiers — exécution à chaud en moins d'une milliseconde avec enregistrements d'exécution signés.
Conçu pour les agents IA, les outils MCP, les plugins, les interpréteurs de code et autres charges de travail non fiables.
Les agents IA ont de plus en plus besoin d'écrire et d'exécuter du code, d'appeler des outils et de lancer des plugins. La question qui détermine si cela est sûr :
Comment laisser un agent exécuter du code non fiable sans donner à ce code accès à votre hôte, vos identifiants, votre réseau ou une puissance de calcul illimitée ?
Agent IA ──▶ Outil / MCP ──▶ Ephemora Cell ──▶ WASM ──▶ résultat borné
Ephemora Cell est un petit runtime d'exécution WASM basé sur les capacités, précisément pour cette tâche : une primitive d'exécution — pas un framework d'agents — qui se place sous votre pile d'agents existante, votre serveur MCP, votre système de plugins ou votre application.
pip install ephemora-cell
# Exécutez votre premier module isolé (récupérez les exemples du dépôt, ou apportez n'importe quel .wasm) :
git clone https://github.com/MichaelS1011/ephemora-cell.git
ephemora-cell run ephemora-cell/examples/hello.wasm
Hello from Ephemora Cell!
from ephemora_cell import run_wasm
result = run_wasm("my_module.wasm")
print(result.stdout) # sortie capturée (limite de 10 Ko)
print(result.status.name) # SUCCESS
print(result.elapsed_ms) # temps réel
print(result.fuel_consumed) # calcul réellement utilisé

Session CLI réelle : installation, première exécution, rapport --json lisible par machine avec la ligne de base de sécurité, et un module d'attaque (exploit.wasm) bloqué au niveau de la couche d'import WASI. Vérifiez chaque image : les commandes s'exécutent telles qu'elles sont montrées à partir d'un clone.

Mêmes huit primitives d'attaque, mesurées en direct en une seule exécution (2026-09-02) : un conteneur standard python:3.12-slim laisse passer chacune d'elles (0/8 bloquées), la frontière Ephemora Cell bloque les huit (8/8). Reproduisez les deux colonnes :
python3 assets/demo_attack_probe.py # colonne de gauche -> 0/8 bloquées (Docker standard)
python benchmarks/verify_8_vectors.py # colonne de droite -> 8/8 bloquées (Ephemora Cell)
Le code généré par un agent est différent du code applicatif : il peut être bogué, sans limite de calcul, inopinément coûteux — ou hostile. Le runtime doit appliquer les limites, pas seulement les documenter. Chaque exécution Cell fait :
Chaque exécution s'effectue sous des limites explicites — pas de sécurité sur option :
Contrôles supplémentaires : budgets d'E/S (io_cpu_seconds=2.0 / io_budget_bytes=64 Mio — murs pour le travail hôte, pas seulement le calcul invité), double ABI (WASI Preview1 + composants WASI 0.2, sur option), memory64 sur option, plafond déclaré du tas GC (enregistré dans la ligne de base de sécurité ; le carburant reste la limite effective), état nommé (64 entrées · 256 Kio · 1 Mio par session), et un médiateur de référence sidecar de sortie (appels API côté hôte validés par liste blanche — docs/egress_patterns.md).
L'invité ne reçoit que les capacités explicitement mises à sa disposition. Vérification en direct de huit classes d'attaque (benchmarks/verify_8_vectors.py) :
Résultat : 8/8 vecteurs d'attaque bloqués (vérifié en direct) ; les lignes de base Docker sont mesurées en direct à chaque exécution — jamais codées en dur.
C'est une frontière d'exécution, pas une affirmation que le logiciel invité est digne de confiance. Cell n'évalue pas si un module est malveillant ou correct — un invité peut toujours mal se comporter dans les budgets qui lui ont été accordés. Les chemins d'exécution diffèrent matériellement : le défaut exécute l'invité dans votre processus ; run_isolated() ajoute des murs au niveau du système d'exploitation (rlimits, quota disque, chien de garde CPU d'E/S, arrêt brutal).
Détails complets : SECURITY.md (politique, matrice de contrôle des chemins d'exécution, limitations connues) · docs/threat-model.md (modèle d'adversaire, frontières de confiance, risques résiduels) · docs/security_posture.md (évaluation arXiv 2509.11242, frontière de carburant, recherche connexe).
Mettez chaque exécution en sandbox sans payer les coûts de démarrage à l'échelle d'un conteneur.
Comparaison en direct du démarrage à froid (2026-08-30, même Mac) : docker run python:3.12-slim 171 ms contre Cell 0,40 ms = 427× — c'est une comparaison démarrage à froid de conteneur contre WASM invoqué pour cette charge de travail de référence, pas une affirmation générale que WASM est toujours plus rapide que Docker.
Reproduction : python benchmarks/pool_vs_budget.py · python benchmarks/competitive_benchmark.py (résultats bruts avec measured:true validés sous benchmarks/results/). Charges de travail agentiques et plus : docs/performance.md.
Cell exécute le .wasm — il ne connaît pas le langage source. Construction en une commande avec des messages d'erreur exploitables issus de la matrice de friction mesurée :
ephemora-cell build tool.rs # → tool.wasm → exécutez-le
Les cinq portes de langages compilés sont vérifiées à chaque push (.github/workflows/ci.yml). Plateformes : macOS (Apple M5) ✅ · Ubuntu 24.04 ✅ · DGX Spark GB10 ✅
Code généré par IA — exécutez des outils produits par des agents avec des limites explicites :
result = run_wasm(
"llm_generated.wasm",
max_fuel=200_000,
timeout_seconds=5,
allow_dirs=("/input", "/output")
)
Systèmes de plugins — acceptez des plugins téléchargés par les utilisateurs sans leur donner un accès illimité à l'hôte :
config = WASIConfig(allow_dirs=("/data",), max_fuel=500_000)
result = WASISandbox(config=config).run("user_plugin.wasm")
Également documenté : charges de travail serverless/edge, validation en environnement isolé, composants WASI 0.2, intégration FastAPI — docs/recipes.md. Les tests d'intégration de frameworks d'agents (LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Semantic Kernel, Hermes, NemoClaw) se trouvent dans integration/.
Ephemora Cell fournit un serveur MCP stdio sans dépendance dont les outils sont des modules WASM exécutés dans Cell — déterminisme, comptage de carburant, plafond de sortie, pas de réseau, enregistrements d'exécution signés prêts pour SEP-2787 :
pip install ephemora-cell
ephemora-cell-mcp # outil echo intégré inclus ; enregistrez le vôtre : --tools-dir ./tools
Voir docs/mcp.md et docs/comparison-mcp-servers.md.
flowchart TB
guest["Module WASM invité<br/>(isolé)"]
subgraph sandbox["Sandbox WASI — isolation basée sur les capacités"]
fuel["Compteur de carburant<br/>~13 carburant/itération"]
mem["Limite mémoire<br/>128 Mo max"]
timeout["Garde de délai d'expiration<br/>interruption par époque"]
syscalls["WASI Preview1 — basé sur les capacités,<br/>répertoires pré-ouverts uniquement<br/>fd_read · fd_write · path_open · clock_time_get<br/>proc_exit · environ_get · random_get"]
end
blocked["Bloqué par conception :<br/>exec · fork · socket · /dev · /proc · /sys · threads"]
guest --> syscalls
fuel -.-> sandbox
mem -.-> sandbox
timeout -.-> sandbox
sandbox -.-> blockedL'API principale est délibérément simple : execute(wasm) → result. Chaque exécution renvoie des informations structurées et auditable :
result.status # SUCCESS | ERROR | TIMEOUT | FUEL_EXHAUSTED | MEMORY_EXCEEDED
result.exit_code
result.stdout # limite de 10 Ko
result.stderr
result.elapsed_ms
result.fuel_consumed
Cela rend l'exécution adaptée à l'audit, à l'application de politiques et à la comptabilité des ressources — pas seulement à l'exécution de code. CLI complète (run, --json avec security_baseline, inspect, benchmark, build, profils incl. --profile analytical) dans la documentation CLI et ephemora-cell --help.
Cell est : une primitive d'exécution WASM · une couche d'isolation basée sur les capacités · un runtime à ressources bornées · une bibliothèque Python intégrable · une CLI · une couche d'exécution MCP.
Cell n'est pas : un framework d'agents · un LLM · un système de génération de code · un détecteur de logiciels malveillants · une VM complète · un remplacement pour chaque charge de travail en conteneur.
L'objectif est étroit : rendre l'exécution non fiable suffisamment peu coûteuse et suffisamment contrôlée pour qu'une application puisse le faire en toute sécurité par défaut.
379 tests · 85 % de couverture des instructions (Cell + MCP, seuil 80 %) · 8/8 vecteurs d'attaque bloqués · appliqué par CI à chaque push (tests, couverture, pip-audit, SBOM, bandit) — voir .github/workflows/ci.yml.
SECURITY.md — politique et contrôles de sécurité · docs/threat-model.md — frontières de confiance · docs/security_posture.md — vérification de la surface d'attaque · docs/performance.md — benchmarks · docs/mcp.md — serveur MCP · docs/recipes.md — modèles d'utilisation · docs/languages.md — prise en charge des langages · CHANGELOG.md — modifications
Ephemora Cell est la couche d'isolation open source (Apache 2.0, autonome — aucune dépendance Ephemora). L'édition entreprise d'Ephemora s'appuie sur l'isolation de Cell pour les déploiements de production et réglementés. Cell est complet pour l'isolation ; l'édition entreprise est complète pour l'exploitation — voir docs/enterprise.md pour savoir quand cette conversation vaut la peine d'être menée.
Apache 2.0 — Voir LICENSE.
Une action d'agent. Une exécution bornée. Un résultat contrôlé.
Créé par Michael Soppa.
| Ressource | Défaut |
|---|
| Mémoire WASM | 128 Mo (Store.set_limits) |
| Budget carburant / CPU | 1 000 000 (~13 carburant/itération, R² = 1,000) |
| Délai d'expiration temps réel | 30 s (interruption par époque) |
| stdout/stderr capturés | 10 Ko |
| Réseau | désactivé — aucune API socket dans WASI |
| Système de fichiers hôte | refusé par défaut ; 14 répertoires dangereux bloqués (/dev, /proc, /sys, …) |
| Exécution / fork de processus | indisponible dans WASI |
| Threading | désactivé (wasm_threads=False) |
| Classe d'attaque | Docker | Ephemora Cell |
|---|
Shell (os.system) / fork / sockets réseau | AUTORISÉ | BLOQUÉ — les API n'existent pas dans WASI |
fsync (os.fsync) | AUTORISÉ | BLOQUÉ — rejet au niveau de l'import |
Système de fichiers hôte (/etc/passwd) | AUTORISÉ | BLOQUÉ — pré-ouverture refusée par défaut |
| Évasion par lien symbolique | AUTORISÉE | BLOQUÉE — filtre des répertoires dangereux |
| Multithreading | AUTORISÉ | BLOQUÉ — wasm_threads=False |
| Accès à l'environnement | AUTORISÉ | BLOQUÉ — contrôlé via allow_env |
Scénario (n=1000, hello.wasm, Mac M5, wasmtime 47.0.1) | Médiane murale | Murale p95 | Médiane invité |
|---|
Moteur en pool (io_budget_bytes=None, exécutions de confiance) | 0,46 ms | 0,60 ms | 0,16 ms |
Chemin par défaut (io_budget_bytes=64 Mio, moteur par exécution) | 0,92 ms | 1,26 ms | 0,60 ms |
| Langage | Compilateur | Vérifié |
|---|
| Rust | cargo build --target wasm32-wasip1 | ✅ Compilé + exécuté (CI) |
| Go | GOOS=wasip1 GOARCH=wasm go build | ✅ Compilé + exécuté (CI) |
| C | wasi-sdk clang --target=wasm32-wasip1 | ✅ Compilé + exécuté (CI) |
| AssemblyScript | asc --runtime stub | ✅ Compilé + exécuté (CI) |
| Zig | zig build-exe -target wasm32-wasi | ✅ Compilé + exécuté (CI) |
| Python | — | Recommandation : exécuter sur un interpréteur wasi-python (pas d'AOT existant) |