Ephemora Cell

Il livello di esecuzione per codice generato da IA non attendibile.

Esecuzione WASM veloce e basata su capability con limiti espliciti di CPU, memoria, tempo, I/O e filesystem — esecuzione a caldo sub-millisecondo con record di esecuzione firmati.

Progettato per agenti IA, strumenti MCP, plugin, interpreti di codice e altri carichi di lavoro non attendibili.

Il problema

Gli agenti IA hanno sempre più bisogno di scrivere ed eseguire codice, chiamare strumenti ed eseguire plugin. La domanda che determina se ciò sia sicuro è:

Come si permette a un agente di eseguire codice non attendibile senza dare a quel codice accesso al tuo host, alle tue credenziali, alla tua rete o a risorse di calcolo illimitate?

AI Agent ──▶ Tool / MCP ──▶ Ephemora Cell ──▶ WASM ──▶ risultato limitato

Ephemora Cell è un piccolo runtime di esecuzione WASM basato su capability, progettato esattamente per questo compito: un primitivo di esecuzione — non un framework per agenti — che si colloca sotto il tuo stack di agenti esistente, server MCP, sistema di plugin o applicazione.

Avvio rapido

pip install ephemora-cell

# Esegui il tuo primo modulo isolato (prendi gli esempi dal repo, o porta qualsiasi .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)          # output catturato (limite 10 KB)
print(result.status.name)     # SUCCESS
print(result.elapsed_ms)      # tempo reale
print(result.fuel_consumed)   # calcolo effettivamente utilizzato

Sessione CLI reale: installazione, prima esecuzione, report --json leggibile dalla macchina con la baseline di sicurezza, e un modulo di attacco (exploit.wasm) bloccato al livello di importazione WASI. Verifica ogni fotogramma: i comandi vengono eseguiti come mostrato da un clone.

Le stesse otto primitive di attacco, misurate dal vivo in un'unica esecuzione (2026-09-02): un container standard python:3.12-slim le lascia passare tutte (0/8 bloccate), il confine di Ephemora Cell le blocca tutte e otto (8/8). Riproduci entrambe le colonne:

python3 assets/demo_attack_probe.py    # colonna sinistra  -> 0/8 bloccate (Docker standard)
python  benchmarks/verify_8_vectors.py # colonna destra -> 8/8 bloccate (Ephemora Cell)

Perché è importante

Il codice generato dagli agenti è diverso dal codice applicativo: può essere difettoso, computazionalmente illimitato, inaspettatamente costoso — o ostile. Il runtime deve applicare i confini, non documentarli. Ogni esecuzione di Cell fa:

• Applicato, non promesso — la misurazione del fuel (CPU), i limiti di memoria, i timeout a orologio reale basati su epoch, i limiti di output e i budget I/O sono applicati per ogni esecuzione; la postura effettiva è attestata in un record di esecuzione firmato.
• Vantaggio di isolamento misurato — dei vettori di attacco che riescono contro un container Docker standard (shell, fork, socket, filesystem host, symlink escape, …), tutti e 8 sono bloccati qui (verificato dal vivo, script nel repo).
• Esecuzione a caldo sub-millisecondo — 0,16 ms guest / 0,46 ms end-to-end (in pool, misurato) rende il sandboxing di ogni chiamata conveniente anziché eccezionale.

Cosa viene applicato

Ogni esecuzione avviene sotto limiti espliciti — nessuna sicurezza opt-in:

Controlli aggiuntivi: budget I/O (io_cpu_seconds=2.0 / io_budget_bytes=64 MiB — barriere per il lavoro host, non solo per il calcolo guest), dual-ABI (WASI Preview1 + componenti WASI 0.2, opt-in), memory64 opt-in, limite dichiarato dell'heap GC (registrato nella baseline di sicurezza; il fuel rimane il limite effettivo), stato nominato (64 voci · 256 KiB · 1 MiB per sessione) e un sidecar di uscita mediatore di riferimento (chiamate API lato host validate tramite allowlist — docs/egress_patterns.md).

Sicurezza

Il guest riceve solo le capability esplicitamente messe a sua disposizione. Verifica dal vivo di otto classi di attacco (benchmarks/verify_8_vectors.py):

Risultato: 8/8 vettori di attacco bloccati (verificato dal vivo); le baseline Docker sono misurate dal vivo per ogni esecuzione — mai hardcoded.

Questo è un confine di esecuzione, non un'affermazione che il software guest sia affidabile. Cell non valuta se un modulo sia dannoso o corretto — un guest può comunque comportarsi male entro i budget che gli sono stati concessi. I percorsi di esecuzione differiscono sostanzialmente: il percorso predefinito esegue il guest all'interno del tuo processo; run_isolated() aggiunge barriere a livello di sistema operativo (rlimit, quota disco, watchdog I/O CPU, kill forzato).

Dettagli completi: SECURITY.md (policy, matrice di controllo dei percorsi di esecuzione, limitazioni note) · docs/threat-model.md (modello di avversario, confini di fiducia, rischi residui) · docs/security_posture.md (valutazione arXiv 2509.11242, confine del fuel, ricerca correlata).

Prestazioni

Metti in sandbox ogni esecuzione senza pagare i costi di avvio a livello di container.

Confronto live di cold-start (2026-08-30, stesso Mac): docker run python:3.12-slim 171 ms vs Cell 0,40 ms = 427× — questo è un confronto tra cold-start di container e WASM invocato per questo carico di lavoro di benchmark, non un'affermazione generale che WASM sia sempre più veloce di Docker.

Riproduci: python benchmarks/pool_vs_budget.py · python benchmarks/competitive_benchmark.py (risultati grezzi con measured:true committati sotto benchmarks/results/). Carichi di lavoro agentici e altro: docs/performance.md.

Qualsiasi linguaggio che compili in WASM

Cell esegue il .wasm — non conosce il linguaggio sorgente. Build con un solo comando e suggerimenti di errore utili derivati dalla matrice di attrito misurata:

ephemora-cell build tool.rs     # → tool.wasm → eseguilo

Tutti e cinque i gate dei linguaggi compilati vengono verificati a ogni push (.github/workflows/ci.yml). Piattaforme: macOS (Apple M5) ✅ · Ubuntu 24.04 ✅ · DGX Spark GB10 ✅

Casi d'uso

Codice generato da IA — esegui strumenti prodotti dagli agenti con limiti espliciti:

result = run_wasm(
    "llm_generated.wasm",
    max_fuel=200_000,
    timeout_seconds=5,
    allow_dirs=("/input", "/output")
)

Sistemi di plugin — accetta plugin caricati dagli utenti senza dare loro accesso host illimitato:

config = WASIConfig(allow_dirs=("/data",), max_fuel=500_000)
result = WASISandbox(config=config).run("user_plugin.wasm")

Documentati anche: carichi di lavoro serverless/edge, validazione air-gapped, componenti WASI 0.2, integrazione FastAPI — docs/recipes.md. I test di integrazione con framework per agenti (LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Semantic Kernel, Hermes, NemoClaw) si trovano in integration/.

Server MCP

Ephemora Cell include un server MCP stdio senza dipendenze i cui strumenti sono moduli WASM eseguiti all'interno di Cell — determinismo, misurazione del fuel, limite di output, nessuna rete, record di esecuzione firmati pronti per SEP-2787:

pip install ephemora-cell
ephemora-cell-mcp          # strumento echo incluso; registra i tuoi: --tools-dir ./tools

Vedi docs/mcp.md e docs/comparison-mcp-servers.md.

Architettura

flowchart TB
    guest["Modulo WASM Guest<br/>(isolato)"]
    subgraph sandbox["Sandbox WASI — isolamento basato su capability"]
        fuel["Misuratore Fuel<br/>~13 fuel/iterazione"]
        mem["Limite Memoria<br/>128 MB max"]
        timeout["Guardia Timeout<br/>interruzione epoch"]
        syscalls["WASI Preview1 — basato su capability,<br/>solo dir preopen<br/>fd_read · fd_write · path_open · clock_time_get<br/>proc_exit · environ_get · random_get"]
    end
    blocked["Bloccato per progettazione:<br/>exec · fork · socket · /dev · /proc · /sys · thread"]

    guest --> syscalls
    fuel -.-> sandbox
    mem -.-> sandbox
    timeout -.-> sandbox
    sandbox -.-> blocked

L'API primaria è volutamente semplice: execute(wasm) → result. Ogni esecuzione restituisce informazioni strutturate e verificabili:

result.status        # SUCCESS | ERROR | TIMEOUT | FUEL_EXHAUSTED | MEMORY_EXCEEDED
result.exit_code
result.stdout        # limite 10 KB
result.stderr
result.elapsed_ms
result.fuel_consumed

Ciò rende l'esecuzione adatta a audit, applicazione delle policy e contabilità delle risorse — non solo all'esecuzione di codice. CLI completa (run, --json con security_baseline, inspect, benchmark, build, profili incl. --profile analytical) nella documentazione CLI e in ephemora-cell --help.

Cosa è Cell — e cosa non è

Cell è: un primitivo di esecuzione WASM · un livello di isolamento basato su capability · un runtime con risorse limitate · una libreria Python incorporabile · una CLI · un livello di esecuzione MCP.

Cell non è: un framework per agenti · un LLM · un sistema di generazione di codice · un rilevatore di malware · una VM completa · un sostituto per ogni carico di lavoro containerizzato.

L'obiettivo è ristretto: rendere l'esecuzione non attendibile abbastanza economica e controllata che un'applicazione possa farla in modo sicuro per impostazione predefinita.

Test e verifica

379 test · 85% di copertura delle istruzioni (Cell + MCP, soglia 80%) · 8/8 vettori di attacco bloccati · applicato dalla CI a ogni push (test, copertura, pip-audit, SBOM, bandit) — vedi .github/workflows/ci.yml.

Documentazione

SECURITY.md — policy e controlli di sicurezza · docs/threat-model.md — confini di fiducia · docs/security_posture.md — verifica della superficie di attacco · docs/performance.md — benchmark · docs/mcp.md — server MCP · docs/recipes.md — modelli di utilizzo · docs/languages.md — supporto linguistico · CHANGELOG.md — modifiche

Informazioni su Ephemora

Ephemora Cell è il livello di isolamento open-source (Apache 2.0, autonomo — nessuna dipendenza da Ephemora). L'edizione enterprise di Ephemora si basa sull'isolamento di Cell per distribuzioni di produzione e regolamentate. Cell è completo per l'isolamento; l'edizione enterprise è completa per l'operatività — vedi docs/enterprise.md per quando vale la pena avere quella conversazione.

Licenza

Apache 2.0 — Vedi LICENSE.

Un'azione dell'agente. Un'esecuzione limitata. Un risultato controllato.

Creato da Michael Soppa.