Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
Outils/GitHubGitHub/michaels1011/ephemora-cell
Sécurité des ConteneursAnalyse Dynamique (Sandboxing)Virtualisation de SécuritéSécurité CloudDevSecOpsSécurité des APISécurité de l'IA
GitHubmichaels1011/ephemora-cell

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →

À propos

# 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.

ephemora-cell

Voir le dépôtSite web
111il y a 2 joursPas encore vérifié
Partager

Ephemora Cell

La couche d'exécution pour le code généré par IA non fiable.

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.

PyPI Python 3.10+ License Status

Agent IA → pile d'application des limites Ephemora Cell → résultat borné

Le problème

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 ?

root@kitploit:~
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.

Démarrage rapide

root@kitploit:~
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
root@kitploit:~
Hello from Ephemora Cell!
root@kitploit:~
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é

Démo Ephemora Cell — installation, exécution, rapport JSON, attaque bloquée

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ême attaque, frontière différente — 8 primitives d'attaque autorisées dans un conteneur Docker standard, les 8 bloquées par Ephemora Cell

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 :

root@kitploit:~
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)

Pourquoi c'est important

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 :

  • Appliqué, pas promis — le comptage de carburant (CPU), les plafonds mémoire, les délais d'expiration basés sur les époques en temps réel, les plafonds de sortie et les budgets d'E/S sont appliqués à chaque exécution ; la posture effective est attestée dans un enregistrement d'exécution signé.
  • Avantage d'isolation mesuré — parmi les vecteurs d'attaque qui réussissent contre un conteneur Docker standard (shell, fork, socket, système de fichiers hôte, évasion par lien symbolique, …), les 8 sont bloqués ici (vérifié en direct, script dans le dépôt).
  • Exécution à chaud en moins d'une milliseconde — 0,16 ms invité / 0,46 ms de bout en bout (en pool, mesuré) rend le sandboxing de chaque appel abordable plutôt qu'exceptionnel.

Ce qui est appliqué

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).

Sécurité

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).

Performance

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.

Tout langage qui compile vers WASM

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 :

root@kitploit:~
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 ✅

Cas d'utilisation

Code généré par IA — exécutez des outils produits par des agents avec des limites explicites :

root@kitploit:~
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 :

root@kitploit:~
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/.

Serveur MCP

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 :

root@kitploit:~
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.

Architecture

root@kitploit:~
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 -.-> blocked

L'API principale est délibérément simple : execute(wasm) → result. Chaque exécution renvoie des informations structurées et auditable :

root@kitploit:~
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.

Ce que Cell est — et n'est pas

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.

Tests et vérification

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.

Documentation

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

À propos d'Ephemora

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.

Licence

Apache 2.0 — Voir LICENSE.


Une action d'agent. Une exécution bornée. Un résultat contrôlé.

Créé par Michael Soppa.

Télécharger l’outil
RessourceDéfaut
Mémoire WASM128 Mo (Store.set_limits)
Budget carburant / CPU1 000 000 (~13 carburant/itération, R² = 1,000)
Délai d'expiration temps réel30 s (interruption par époque)
stdout/stderr capturés10 Ko
Réseaudésactivé — aucune API socket dans WASI
Système de fichiers hôterefusé par défaut ; 14 répertoires dangereux bloqués (/dev, /proc, /sys, …)
Exécution / fork de processusindisponible dans WASI
Threadingdésactivé (wasm_threads=False)
Classe d'attaqueDockerEphemora Cell
Shell (os.system) / fork / sockets réseauAUTORISÉ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 symboliqueAUTORISÉEBLOQUÉE — filtre des répertoires dangereux
MultithreadingAUTORISÉBLOQUÉ — wasm_threads=False
Accès à l'environnementAUTORISÉBLOQUÉ — contrôlé via allow_env
Scénario (n=1000, hello.wasm, Mac M5, wasmtime 47.0.1)Médiane muraleMurale p95Médiane invité
Moteur en pool (io_budget_bytes=None, exécutions de confiance)0,46 ms0,60 ms0,16 ms
Chemin par défaut (io_budget_bytes=64 Mio, moteur par exécution)0,92 ms1,26 ms0,60 ms
LangageCompilateurVérifié
Rustcargo build --target wasm32-wasip1✅ Compilé + exécuté (CI)
GoGOOS=wasip1 GOARCH=wasm go build✅ Compilé + exécuté (CI)
Cwasi-sdk clang --target=wasm32-wasip1✅ Compilé + exécuté (CI)
AssemblyScriptasc --runtime stub✅ Compilé + exécuté (CI)
Zigzig build-exe -target wasm32-wasi✅ Compilé + exécuté (CI)
Python—Recommandation : exécuter sur un interpréteur wasi-python (pas d'AOT existant)