Ephemora-Cell MCP

Ephemora Cell

Ephemora Cell es una primitiva ligera de seguridad y ejecución para ejecutar código no confiable dentro de agentes de IA, herramientas MCP, plugins y aplicaciones.

Run untrusted code.
Control its capabilities.
Bound its resources.
Record what happened.

Diseñado para agentes de IA, herramientas MCP, plugins, intérpretes de código y otras cargas de trabajo no confiables.

AI Agent / Application
        │
        ▼
   Tool / Plugin / MCP
        │
        ▼
 ┌───────────────────────┐
 │     Ephemora Cell     │
 │                       │
 │ Capabilities          │
 │ Resource budgets      │
 │ WASI sandbox          │
 │ Execution record      │
 └──────────┬────────────┘
            ▼
       WASM module

~0.5 ms en caliente · ~3M de ejecuciones/hora por núcleo (una línea) hasta ~5.5M en pool · determinista, no "aislado y con esperanza"

Inicio Rápido · Seguridad · MCP · Acción de GitHub · Benchmarks · Documentación

Estado (2026-09-25): última versión v1.0.4.3 (2026-09-25, versión de documentación y endurecimiento — registro de cambios) · auditoría funcional completa 2026-09-24, hallazgos corregidos y publicados el mismo día · evidencia reproducible más reciente: 2026-09-25 (clases de prueba, benchmarks/results/) · 532 pruebas aprobadas, 86% de cobertura (ver insignia de CI — actualizada por versión)

¿Qué es Ephemora Cell?

Ephemora Cell es una primitiva de ejecución y seguridad incrustable para ejecutar código WASM no confiable: aislamiento WASM/WASI, control explícito de capacidades, límites aplicados de CPU/combustible, memoria, E/S y tiempo, salida acotada y registros de ejecución estructurados — opcionalmente firmados. Runtime + primitiva de seguridad + contabilidad en un solo pip install. Utiliza Wasmtime para implementar ese límite — WASM es el mecanismo, la ejecución controlada de código no confiable es el producto.

¿Por qué Ephemora Cell?

Wasmtime te da un runtime de WASM.

Ephemora Cell construye un límite de ejecución a nivel de aplicación a su alrededor:

Wasmtime:            Ephemora Cell:
    Execute WASM         Execute WASM
                         + define capabilities
                         + enforce budgets (fuel, memory, time, I/O)
                         + bound output
                         + collect execution metadata
                         + produce execution records (sign-ready)
                         + integrate with agents and MCP

El problema que responde: los agentes de IA necesitan cada vez más escribir y ejecutar código, llamar herramientas y ejecutar plugins. La pregunta que decide si eso es seguro: ¿cómo permites que un agente ejecute código no confiable sin darle a ese código acceso a tu host, tus credenciales, tu red o cómputo ilimitado — sin nada preabierto por defecto? Los runtimes crudos te dejan ese límite a ti. Cell es ese límite.

El código generado por agentes es diferente del código de aplicación: puede ser defectuoso, computacionalmente ilimitado, inesperadamente costoso — u hostil. El runtime debe aplicar límites, no documentarlos. Cada ejecución de Cell hace:

• Aplicado, no prometido — medición de combustible (CPU), límites de memoria, tiempos de espera de reloj de pared basados en épocas, límites de salida y presupuestos de E/S se ejecutan por ejecución y no pueden ser desactivados por el invitado o el llamador; la postura efectiva se atestigua en el registro de ejecución (RFC 8785 JCS, listo para firmar).
• Detención de bucle determinista — un módulo hostil o defectuoso que se repite para siempre se detiene exactamente en el presupuesto que estableciste, cada vez; la ejecución no puede exceder su presupuesto de combustible. El tiempo de espera de reloj de pared basado en épocas es la red de seguridad adicional — el combustible cuenta la CPU, el reloj limita todo lo demás.
• Ventaja de aislamiento medida — de los vectores de ataque que tienen éxito contra un contenedor Docker estándar (shell, fork, socket, sistema de archivos del host, escape de symlink, …), los 8 están bloqueados aquí (verificado en vivo, script en el repositorio).
• Ejecución en caliente submilisegundo — 0.17 ms invitado / 0.51 ms de extremo a extremo (en pool, medido 2026-09-14; benchmarks/results/).

Por qué ahora — evidencia de 2026 de que la detección y los contenedores no son suficientes (literatura — measured:false para Cell; las filas medidas viven en la escalera de evidencia y nunca se mezclan con estas). SABER — el programa SandboxEscapeBench (Instituto de Seguridad de IA del Reino Unido y Oxford, ICML 2026) muestra que los modelos de frontera escapan de manera confiable de contenedores Docker a través de configuraciones erróneas comunes — el mismo benchmark que este repositorio mapea a WASM en la sección de Seguridad. Investigadores de Trail of Bits (Judson y Hess, 2026) eludieron cinco escáneres de habilidades de agentes y defensas de sandbox en un solo estudio, y el ataque de envenenamiento de habilidades DDIPE (arXiv 2604.03081) mide tasas de elusión del 11.6–33.5% contra ecosistemas de habilidades de agentes. El patrón en los tres: el escaneo y los valores predeterminados de contenedores fallan; el límite que se mantiene es el que se aplica entre el código y el host — la capa que Cell entrega (procedencia por afirmación: docs/security_posture.md).

AI Agent ──▶ Tool / MCP ──▶ Ephemora Cell ──▶ WASM ──▶ bounded result

Cada ejecución responde tres preguntas a la vez — adjuntas al resultado como _meta.execution, canonizadas (RFC 8785 JCS) y firmables:

	Respuesta	Campos de ejemplo
RESULTADO	qué regresó	status, stdout, exit_code
COSTO	cuánto costó	fuel_consumed, elapsed_ms
POLÍTICA	bajo qué reglas se ejecutó	límite de memoria, preaperturas, política de red, wasmtime_version

"Verificando. No afirmado." son datos, no un eslogan: cualquier registro se puede volver a verificar — reescribe un campo y verify() falla. Demo ejecutable: python examples/signed_record_demo.py.

Modelo de Seguridad

Cell asume que el código invitado no es confiable. El host decide explícitamente a qué puede acceder el invitado — y el runtime aplica esa decisión por ejecución.

HOST
────────────────────────────
       Cell Boundary
────────────────────────────
GUEST / UNTRUSTED CODE

Por defecto: sin red · sin acceso arbitrario al sistema de archivos · sin creación de procesos · sin acceso sin restricciones al entorno — y CPU/combustible, memoria, tiempo de ejecución y salida acotados.

La seguridad nunca es opcional. Cada ejecución — en proceso o aislada — se ejecuta bajo límites aplicados (combustible de CPU, memoria, tiempo de reloj de pared, límites de salida — siempre activos, ni el invitado ni el llamador pueden desactivarlos). Lo único que eliges es el límite de proceso: agrega --isolated (o llama a run_isolated()) cuando el módulo proviene de fuera de tu propia compilación — salida de agentes, plugins de terceros, código contribuido por PR. La ruta en proceso permanece para módulos que construyes y confías. Los valores predeterminados aplicados:

Recurso	Predeterminado
Memoria WASM	128 MB (Store.set_limits)
Presupuesto de combustible / CPU	1,000,000 (~13 combustible/iteración, R² = 1.000 hasta 1M iteraciones; re-medido 2026-09-14, benchmarks/results/2026-09-14/fuel_boundary.json — el combustible es por plataforma, ver docs/performance.md)
Tiempo de espera de reloj de pared	30 s (interrupción por época)
stdout/stderr capturados	10 KB
Red	deshabilitada — Preview1: sin APIs de socket; WASI 0.2: vinculado, denegado en tiempo de llamada (medido)
Sistema de archivos del host	denegado por defecto; 14 directorios peligrosos bloqueados (/dev, /proc, /sys, …)
Ejecución / fork de procesos	no disponible en WASI
Subprocesos	deshabilitados (wasm_threads=False)

La misma regla gobierna las características del lenguaje: cada propuesta de WebAssembly que la superficie WASI enviada de Cell no necesita está aplicada como desactivada en la configuración del motor (subprocesos, referencias de funciones, excepciones, GC, llamadas de cola, cambio de pila — atestiguado en cada security_baseline, probado con compilación de prueba por versión). Esa es una defensa estructural deliberada: el registro de 2025/26 — la contabilidad de combustible cayó a través de llamadas call_ref/try_table (GHSA-m63x-6p34-q65x), un escape de heap aarch64 de Cranelift (CVE-2026-34971), y el escape de vm2 montado en el manejo de excepciones try_table de WebAssembly (CVE-2026-26956, fuentes secundarias) — repite un patrón: los sandboxes divergen exactamente donde una propuesta cambió silenciosamente a activada por defecto. Cell mantiene esa superficie en cero y paga el costo en lo que los invitados no pueden ejecutar, no en lo que el host no puede garantizar. Tabla completa de propuestas: SECURITY.md.

Controles adicionales: presupuestos de E/S (io_cpu_seconds / io_budget_bytes — muros para trabajo del host, no solo cómputo del invitado), ABI dual (WASI Preview1 + componentes WASI 0.2, opt-in), memory64 opt-in, límite declarado de heap GC, estado nombrado (64 entradas · 256 KiB · 1 MiB por sesión), y un sidecar de egreso mediador de referencia (docs/egress_patterns.md).

Inicio Rápido

Tres comandos: instala Cell, ejecuta algo no confiable, lee su recibo auditado.

1 — Instala (usa un virtualenv; en Ubuntu ≥ 23.04 / Fedora un pip install simple es rechazado por PEP 668. Windows: usa Git Bash o WSL, y python en lugar de python3):

python3 -m venv .venv && source .venv/bin/activate
python -m pip install ephemora-cell

2 — Ejecuta algo no confiable (el repositorio incluye ejemplos, o trae cualquier .wasm):

git clone https://github.com/MichaelS1011/ephemora-cell.git && cd ephemora-cell
ephemora-cell run examples/hello.wasm --isolated

(agrega aislamiento de procesos a nivel de SO alrededor de la ejecución, unos pocos ms — recomendado para código que no construiste)

Hello from Ephemora Cell!

3 — Lee el recibo auditado — la misma ejecución, legible por máquina. Aquí un módulo hostil (examples/fuel_bomb.wasm) recibe un presupuesto de combustible de 100 unidades y se detiene, exactamente como se presupuestó:

ephemora-cell run examples/fuel_bomb.wasm --fuel 100 --isolated --json

{
  "status": "fuel_exhausted",
  "exit_code": 0,
  "fuel_consumed": 100,
  "fuel_budget": 100,
  "stdout_bytes": 0
}

Lo mismo desde Python — cada resultado lleva estado, costo y salida capturada (ver API y CLI):

Tiempo hasta el valor: sin archivo de política, sin reglas de acceso, sin contenedor que aprovisionar — un pip install y estás ejecutando WASM no confiable bajo un límite duro de combustible + memoria a ~0.5 ms en caliente (la misma llamada tomó a un docker run estándar ~186 ms para iniciar; medido en macOS M5 n=100, benchmarks/results/2026-09-14/competitive_benchmark.json, números DGX en benchmarks/results/2026-09-20/).

Verificación de escala: la ruta de una línea sostiene ~3M de ejecuciones/hora por núcleo (n=500, hello.wasm, Mac M5 — regenera con el fragmento en docs/recipes.md); la ruta de bucle caliente en pool alcanza ~5.5M/hora.

Hacia dónde seguir: aislamiento de agentes/herramientas → Integración MCP (configuración de 3 líneas) · control de CI para PRs no confiables → Integración de Agentes de IA · referencia CLI y recetas de uso → docs/recipes.md. ¿Algo falló? Los sospechosos habituales son venv no activado, python3 vs python en Windows, o una ruta .wasm incorrecta — docs/recipes.md los cubre.

Sesión CLI real: instalación, primera ejecución, informe --json con la línea base de seguridad, una bomba de combustible detenida exactamente en 100/100 unidades, un módulo de ataque bloqueado en la capa de importación WASI. Cada fotograma reproducible desde un clon.

El bucle de devtools para herramientas de agentes

Los mismos comandos son un bucle de desarrollo — editar, ejecutar, leer el recibo — sin Dockerfile, sin construcción de imagen:

Comando	Qué hace en el bucle
ephemora-cell build tool.rs	Compila Rust, Go, C, AssemblyScript o Zig directamente a WASM
ephemora-cell run tool.wasm --json	Veredicto inmediato: estado, código de salida, fuel_consumed, elapsed_ms
ephemora-cell inspect tool.wasm	Importaciones, exportaciones, memoria — qué quiere un módulo, antes de ejecutarlo
ephemora-cell benchmark tool.wasm	Latencia en frío/caliente y dispersión de combustible mientras iteras

Los fallos regresan calificados, no bloqueantes: un bucle infinito devuelve status: "fuel_exhausted" con su recibo, un devorador de memoria memory_exceeded, un bloqueo un código de salida distinto de cero — los mismos estados que consumen el auto-calificador y el trabajo de banco de pruebas de CI. Una herramienta que se comporta mal nunca se lleva tu terminal con ella.

Integración MCP

Listado en el Registro Oficial de MCP (io.github.MichaelS1011/ephemora-cell-mcp, stdio vía PyPI) y calificado en Glama (licencia A, calidad A, mantenimiento B — clasificador en vivo de Glama; consulta las insignias principales arriba). El flujo de llamadas es el diagrama principal de arriba: la llamada de herramienta del agente entra al servidor stdio, la herramienta se ejecuta dentro de la Cell, y el resultado regresa con su registro de ejecución.

pip install ephemora-cell
ephemora-cell-mcp          # bundled tools: clock + echo; --tools-dir ./tools replaces the bundled set with your own

# One-line setup for GitHub Copilot in VS Code:
code --add-mcp '{"name":"Ephemora Cell","command":"ephemora-cell-mcp"}'

Pídele a tu agente la hora actual: la respuesta proviene de la herramienta incluida clock — un módulo WASM que lee solo el reloj de tiempo real de WASI — y el informe de llamada muestra exactamente cuánto costó esa respuesta.

Se ejecuta completamente en tu máquina — con cualquier cliente MCP y cualquier modelo, incluidos los locales. El servidor MCP es un proceso stdio simple instalado desde PyPI: sin clave API, sin cuenta en la nube, y las herramientas se ejecutan sin conexión dentro del sandbox WASM (sin red a menos que lo permitas explícitamente en el lado del host). Apunta Claude Desktop, VS Code/Copilot, Codex, LM Studio o tu pila de modelos locales hacia él — el lado del sandbox nunca sale de tu hardware. Cuánto obtiene el agente de las herramientas depende entonces de la capacidad de llamada a herramientas de tu cliente y modelo; el sandbox en sí no añade requisitos más allá de una máquina local.

Lo que obtienes:

• Ejecuta herramientas no confiables y construidas por agentes localmente. Cada herramienta es un módulo WASM dentro de un sandbox Cell — sin red, con límites de combustible y memoria, y salida limitada. Si una herramienta se comporta mal, choca contra una pared, no contra tu máquina.

• Verifica cada llamada, no solo la instalación. Cada resultado lleva su registro de ejecución (_meta.execution), y la herramienta nativa get-policy informa la política exacta del sandbox por herramienta — calculada desde la misma ruta de código que la aplica, por lo que el informe y la aplicación no pueden divergir. Las lecturas de política son herramientas; las escrituras de política son decisiones del host (ADR-006): un agente no puede otorgarse acceso a la red o al sistema de archivos, y ninguna conexión de socket tiene éxito (Preview1 no expone APIs de socket; en el mundo WASI 0.2 la conexión se deniega en el momento de la llamada — medido).

• Sin estado por diseño (revisión 2026-07-28). Los clientes en la revisión actual omiten por completo el protocolo de enlace initialize; los resultados llevan respuestas resultType: "complete" y tools/list con ttlMs/cacheScope. Los clientes de la era del protocolo de enlace (Claude Desktop, VS Code, Codex, …) siguen funcionando sin cambios — ambas eras se sirven desde un solo proceso y se prueban en paralelo contra el SDK oficial de MCP en CI. Detalles: docs/mcp.md.

• Aislamiento con precio por cada llamada — tres números distintos (comparación):

  Ruta	Costo por llamada	Por qué
  Runtime agrupado de biblioteca (io_budget_bytes=None)	~0.5 ms	motor en caché, cargas de trabajo confiables
  Servidor stdio MCP, predeterminado	~12 ms	sandbox nuevo por tools/call — la barrera de E/S ADR-002 aplicada mediante un motor por ejecución, medido de extremo a extremo
  Servidor stdio MCP, --pooled	~0.5 ms	herramientas verificadas en el motor agrupado; la barrera de E/S relajada se atestigua en get-policy

• El agente no puede reescribir su propio límite de seguridad. El agente solo puede proponer una capacidad; el host verifica la firma, el hash del módulo y la política fuera de banda antes de que se ejecute cualquier cosa; el runtime aplica por ejecución y devuelve evidencia. Ninguna flecha en esa cadena apunta hacia atrás.

vs Microsoft Wassette. Wassette es el runtime basado en capacidades de Microsoft para herramientas MCP, construido sobre la misma familia de motores Wasmtime — su modelo de extracción OCI mueve la decisión de confianza al momento de la instalación; Cell añade lo que un llamador puede verificar por llamada. Comparación completa lado a lado (re-verificada 2026-09-18): docs/comparison-mcp-servers.md.

Este es un límite de ejecución, no una afirmación de que el software invitado sea confiable. Cell no evalúa si un módulo es malicioso o correcto — un invitado aún puede comportarse mal dentro de los presupuestos que se le dieron.

Integración con Agentes de IA

Código de PR no confiable en GitHub Actions. Este repositorio incluye una acción compuesta: ejecuta un módulo WASM en el sandbox Cell dentro de tu propio flujo de trabajo — con medición de combustible, límite de memoria, tiempo de espera por época y (predeterminado) la ruta de subproceso --isolated (rlimits a nivel de SO, terminación forzada):

- id: run-tool
  uses: MichaelS1011/ephemora-cell/action@main
  with:
    module: path/to/module.wasm   # e.g. built from a PR-provided recipe
    profile: llm
    # fuel: 500_000
- run: echo "status=${{ steps.run-tool.outputs.status }} fuel=${{ steps.run-tool.outputs.fuel_consumed }}"

Los estados no exitosos fallan el paso (fail-on: non-success, predeterminado) — un módulo que agota su presupuesto o excede el límite de memoria no puede llevarse tu flujo de trabajo consigo. Este repositorio usa la acción en cada push: .github/workflows/action-demo.yml ejecuta un módulo benigno y alimenta al mismo módulo con un presupuesto de combustible de 100 unidades, afirmando en vivo que el sandbox lo detiene y contabiliza cada unidad.

Las pruebas de integración de frameworks de agentes (LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, Semantic Kernel, Hermes, NemoClaw) viven en integration/ — verificadas contra los SDK reales de los frameworks.

Casos de Uso

Lo que puedes construir con Cell:

• Ejecución de Código IA — ejecuta de forma segura código generado por un LLM, con límites explícitos:

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

• Sandbox de Herramientas MCP — ejecuta herramientas MCP dentro de un entorno de ejecución acotado (consulta Integración MCP).

• Runtime de Plugins — acepta plugins subidos por usuarios sin darles acceso a nivel de host (WASIConfig(allow_dirs=("/data",), max_fuel=500_000) — misma forma que los fragmentos anteriores).

• Runtime de Herramientas de Agentes — da a agentes autónomos acceso controlado a herramientas computacionales.

• Ejecución Verificable — produce registros estructurados y opcionalmente firmados que describen una ejecución (Registros de Ejecución).

También documentado: cargas de trabajo serverless/edge, validación en entornos aislados, componentes WASI 0.2, integración FastAPI — docs/recipes.md.

Arquitectura

Cell ejecuta el .wasm — no conoce el lenguaje fuente. Un comando compila cinco lenguajes, y el runtime se encuentra debajo de tu pila:

La pila de aplicación — módulo → motor → superficie de capacidades → presupuestos → registro — está diagramada en docs/security_posture.md. La API principal es deliberadamente simple — run_wasm(wasm) → result, con status, exit_code, stdout, stderr, elapsed_ms y fuel_consumed en cada resultado (superficie completa en API y CLI). Eso hace que la ejecución sea adecuada para auditoría, aplicación de políticas y contabilidad de recursos — no solo para ejecutar código. CLI completo (run, --json con security_baseline, inspect, benchmark, build) en los docs de CLI y ephemora-cell --help.

Cualquier lenguaje que compile a WASM. Compilación con un comando y sugerencias de error accionables:

ephemora-cell build src/main.rs # inside a cargo project → tool.wasm → run it

Lenguaje	Compilador	Verificado
Rust	cargo build --target wasm32-wasip1	✅ Compilado + ejecutado (CI)
Go	GOOS=wasip1 GOARCH=wasm go build	✅ Compilado + ejecutado (CI)
C	wasi-sdk clang --target=wasm32-wasip1	✅ Compilado + ejecutado (CI)
AssemblyScript	asc --runtime stub	✅ Compilado + ejecutado (CI)
Zig	zig build-exe -target wasm32-wasi	✅ Compilado + ejecutado (CI)
Python	—	Guía: ejecutar en un intérprete wasi-python (no existe AOT)

Las cinco compuertas de lenguajes compilados se verifican en cada push (.github/workflows/ci.yml). Plataformas: macOS (Apple M5) ✅ · Ubuntu 24.04 ✅ · DGX Spark GB10 ✅

Registros de Ejecución

Alrededor del sandbox hay una cadena de confianza verificable para herramientas de terceros:

TOOL ──▶ SIGNED MANIFEST ──▶ HOST VERIFY ──▶ EPHEMORA CELL ──▶ SIGNED EXECUTION
        (vendor ships)     (fail-closed,      runs inside       RECORD
                           hash + policy      the sandbox       (tamper-evident)
                           check)

Cualquier cosa que falle la verificación se rechaza antes de que se ejecute una sola instrucción — la ejecución nunca depende de un camino feliz.

• Manifiestos de herramientas firmados. Las herramientas de terceros incluyen un manifiesto firmado con Ed25519 (RFC 8785 JCS); el servidor verifica la firma y el hash del módulo antes de registrar y rechaza herramientas sin firmar, manipuladas o con hash no coincidente de forma segura — un .wasm sin manifiesto nunca se carga en modo de herramientas firmadas. ephemora-cell-mcp --require-signed-tools pub.pem, firma con python -m ephemora_cell_mcp.sign_tool.
• Carga dinámica gobernada. Un agente solo puede proponer una herramienta — un tool.request.json colocado en un directorio permitido por el operador; el servidor lo evalúa antes de cada mensaje entrante, verifica firma, hash del módulo y política, luego instala y anuncia (notifications/tools/list_changed). El agente propone; el host dispone (ADR-006).
• Registros de ejecución firmados. Cualquier ejecución se pliega en un registro a prueba de manipulación que cubre estado, combustible, tiempo y la línea base de seguridad atestiguada — modifica un campo y la verificación falla. Demo ejecutable: python examples/signed_record_demo.py.
• División pre-ejecución / recibo (ADR-008). PreExecutionRecord firma lo que una ejecución hará (resumen del módulo, huella de política, resumen de entrada) antes de que se ejecute; el back_link opcional del recibo lo vincula exactamente a esa atestación. Los sobres de estándares abiertos (DSSE v1, JWS separado) llevan los mismos bytes JCS para interoperabilidad del ecosistema — sin cliente de red, sin dependencia.
• Ruta rápida confiable. ephemora-cell-mcp --pooled sirve herramientas verificadas desde el motor agrupado a ~0.5 ms por llamada en lugar de ~12 ms (medido) — la barrera de E/S relajada se atestigua en get-policy.

Las dos rutas de ejecución difieren materialmente. run_wasm() ejecuta el invitado dentro de tu proceso; run_isolated() añade muros a nivel de SO alrededor de un trabajador desechable (y devuelve los campos del informe como un dict). Para invitados fuera de tu propio build — salida de agentes, plugins de terceros, código contribuido por PR — usa la ruta aislada:

Control	run_wasm() (en proceso)	run_isolated() (subproceso)
Medición de combustible (CPU invitado)	✅	✅
Límite de memoria (Store.set_limits)	✅	✅
Tiempo de espera de reloj de pared (época)	✅	✅ + terminación forzada del proceso
Límite de salida de 10 KB	✅	✅
Barrera de bytes de E/S (io_budget_bytes)	✅ observador + interrupción de época	✅
Barrera de CPU de E/S (io_cpu_seconds)	❌ documentado-confiado	✅ vigilante de rusage del trabajador
Cuota de disco (disk_quota_bytes)	❌ capacidad confiada	✅ RLIMIT_FSIZE (por archivo)
RLIMIT_NOFILE/AS/RSS, límite de módulo de 32 MB	❌	✅
Denegación de preopen + revalidación TOCTOU en concesión	✅	✅

Las filas marcadas ❌ en proceso son documentado-confiadas: el control se honra como una capacidad declarada, no como un muro aplicado — un límite a nivel de kernel allí limitaría tu propio proceso. Matriz completa y justificación: SECURITY.md.

Seguridad

Escalera de evidencia — primero lo más fuerte. Cada fila está medida, la evidencia cruda está confirmada, y cada ejecución es reproducible:

#	Evidencia	Qué demuestra	Cómo se mide	Reproducir
1	Replays de CVE de MCP	Las rutas de explotación reales de dos CVE parcheados se deniegan a nivel del motor; la carga gobernada falla de forma cerrada ante un payload manipulado — también verificado en componentes WASI 0.2, con una denegación de socket medida en tiempo de llamada	Servidor de referencia vulnerable fijado vs. Cell, tokens aleatorios de marcado, controles positivos en ambos lados	python benchmarks/mcp_cve_replay.py
2	Mapeo de SandboxEscapeBench-18	18 escenarios de escape de contenedores/K8s mapeados a WASM: 8 probados en ejecución y denegados, 10 no expresables en la superficie WASI · porción OSS del programa de referencia de Ephemora (ver nota abajo)	Mapeo estructural + intentos en vivo, control positivo de preopen concedido	python benchmarks/sandbox_escape_18.py
3	8 intenciones de ataque × 3 límites	Mismas intenciones, misma regla de código de salida: Docker estándar 0/8 bloqueados · Docker endurecido 2/8 · Cell 8/8 (matriz abajo)	Sondas en vivo, imagen arm64 fijada por digest	python assets/demo_attack_probe.py · python benchmarks/hardened_docker_probe.py · python benchmarks/verify_8_vectors.py
4	Conformidad oficial WASI	72 aprobados / 1 xfail documentado / 0 fallos contra la suite ascendente fijada — reejecutada semanalmente en CI (las ejecuciones semanales de ubuntu alcanzan 71–72 en pruebas fs variables; una peculiaridad documentada del runner, no un defecto de Cell — ver la sección de conformidad)	Adaptador de runtime sobre la suite oficial, JSON crudo confirmado	ver conformidad/
5	Clases de sondas 2026	Los vectores FS complementarios de CVE-2026-47261 (barra final/hardlink/rename/TRUNCATE), sondas de gusano de persistencia y de plano de control están todos denegados en el motor fijado, con controles positivos concedidos en cada clase	Sondas WASI reales + controles positivos, JSON fechado con measured:true	python benchmarks/probe_classes_2026.py
6	Determinismo entre arquitecturas	Combustible determinista por plataforma (dispersión 0), valores ligados a la plataforma	Misma llamada de herramienta en macOS arm64 / DGX GB10 / x86_64	python benchmarks/determinism_probe.py

Fila 2 en contexto. Los 18 escenarios son externos (UK AI Security Institute, MIT — nota de procedencia abajo). Este mapeo es la porción de código abierto del límite de ejecución de un programa más amplio de referencia y aseguramiento; el programa más amplio — incluyendo la evaluación de escape agéntico que la referencia ascendente realmente ejecuta — es parte de la edición empresarial de Ephemora (docs/enterprise.md).

De dónde vienen los 18 escenarios. No son nuestros: el SandboxEscapeBench del UK AI Security Institute (arXiv 2603.02277, escenarios: UKGovernmentBEIS/sandbox_escape_bench, MIT) documenta 18 formas en que el código escapa de los sandboxes de contenedores/Kubernetes. Esta suite hace algo más limitado: cada escenario se mapea a su equivalente WASM/WASI más cercano y se ejecuta contra Cell, sin modelo en el bucle. Las primitivas en las que se basan esos escapes (modos privilegiados, namespaces, cgroups, sockets crudos) no existen en la superficie WASI; los escenarios con un equivalente expresable en WASM (sistema de archivos, sockets) son denegados por el límite en vivo. La seguridad de inyección de prompts y del comportamiento agéntico son capas diferentes — fuera del alcance de un sandbox de ejecución por diseño; la edición empresarial ejecuta el programa de aseguramiento más amplio (docs/enterprise.md).

Lo que no comparamos — y por qué. Las suites de inyección de prompts (garak, InjecAgent) prueban el modelo y la capa agéntica, no el límite de ejecución — fuera del alcance de un sandbox de ejecución. Los proveedores de sandbox en la nube se citan de fuentes de terceros con su estado de fuente; los números de terceros nunca aparecen en la misma tabla que nuestras celdas medidas. Los benchmarks de arranque y rendimiento viven en docs/performance.md con sus advertencias de alcance.

El invitado recibe solo las capacidades explícitamente puestas a su disposición. Verificación en vivo de ocho clases de ataque (benchmarks/verify_8_vectors.py) — medidas contra tres límites, mismas intenciones, misma regla de medición (el código de salida decide, nada codificado):

Clase de ataque	Docker	Docker (endurecido¹)	Ephemora Cell	Capa
Shell (os.system) / fork	PERMITIDO	PERMITIDO	BLOQUEADO — las APIs no existen en WASI	1
Sockets de red	PERMITIDO	PERMITIDO — la creación no necesita capacidad	BLOQUEADO — las APIs no existen en WASI	1
fsync (os.fsync)	PERMITIDO	BLOQUEADO — EROFS vía --read-only	BLOQUEADO — rechazo a nivel de importación	2
Sistema de archivos del host (/etc/passwd)	PERMITIDO	PERMITIDO — el propio archivo del contenedor	BLOQUEADO — preopen denegación por defecto	2
Escape de symlink	PERMITIDO	BLOQUEADO — EROFS vía --read-only	BLOQUEADO — filtro de directorios peligrosos	2
Multihilo	PERMITIDO	PERMITIDO	BLOQUEADO — wasm_threads=False	2
Acceso al entorno	PERMITIDO	PERMITIDO	BLOQUEADO — controlado vía allow_env	2

El límite tiene tres capas, y la tabla las mide por separado:

• Capa 1 — Superficie WASI: el propio formato invitado no tiene puntos de entrada de shell/fork/socket para llamar.
• Capa 2 — Política de sandbox (siempre activa): preopen denegación por defecto, filtro de directorios peligrosos, trampas de importación, wasm_threads=False, allow_env — aplicada por ejecución, no configurable para desactivar.
• Capa 3 — Muro de proceso del SO (--isolated): un proceso de trabajo desechable con rlimits del SO y un kill duro — la capa de mitigación para 0-days del motor (SECURITY.md documenta los avisos de wasmtime de abril de 2026).

Resultado: 8/8 vectores de ataque bloqueados (verificado en vivo); ambas líneas base de Docker se miden en vivo por ejecución — nunca codificadas.

Para contexto, las mismas ocho intenciones se midieron contra gVisor (runsc, versión fijada, ejecutado en CI dos veces por determinismo): 8/8 PERMITIDO. gVisor aísla el host del contenedor, pero el invitado conserva el ABI de Linux — así que las mismas primitivas siguen disponibles para el código invitado. Matriz de expectativas predeclarada en benchmarks/gvisor_docker_probe.py; evidencia cruda: benchmarks/results/2026-09-19/08_gvisor_docker_attack_probe.json (confirmado desde el trabajo de CI gvisor-boundary).

¹ Endurecido = exactamente estas banderas — dinos cuáles añadir: --network none --read-only --cap-drop=ALL --security-opt no-new-privileges --pids-limit 64 --user 65534:65534 (imagen fijada por digest; el perfil seccomp por defecto de Docker está activo en ambas columnas). Ambos bloqueos endurecidos son efectos del sistema de archivos --read-only — las banderas aíslan el contenedor hacia afuera, no al invitado hacia adentro: la creación de sockets, el propio /etc/passwd del contenedor, fork, multihilo y entorno siguen disponibles para el invitado.

Mismas ocho primitivas de ataque, medidas en vivo: python:3.12-slim estándar 0/8 bloqueados, contenedor endurecido 6/8 (ambos bloqueos son efectos de bandera --read-only), Cell 8/8. Medido en dos plataformas con resultados idénticos — macOS arm64 (2026-09-18) y DGX Spark GB10 (2026-09-20, benchmarks/results/2026-09-20/*-dgx-aarch64.json). Reproducir:

python assets/demo_attack_probe.py          # stock Docker    ->  0/8 blocked
python benchmarks/hardened_docker_probe.py  # hardened Docker ->  2/8 blocked
python benchmarks/verify_8_vectors.py       # Ephemora Cell   ->  8/8 blocked

Cómo se mide el 8/8 — entorno, equivalencia sonda por sonda entre el cuerpo de la sonda de Docker y el invitado WASM de Cell, lista de archivos de evidencia cruda y la regla de control positivo: docs/security_posture.md. En resumen: el código de salida medido decide, nada codificado; cada vector bloqueado se empareja con un control de capacidad concedida que debe tener éxito.

• Evidencia cruda: benchmarks/results/2026-09-18/ (01_hardened_docker_attack_probe.json · 02_docker_attack_probe.json · 03_cell_8_vector_verify.json) + benchmarks/results/2026-09-02/ histórico

Replays de CVE de MCP. Los servidores de referencia oficiales de MCP tienen CVE reales y parcheados contra esta superficie exacta. benchmarks/mcp_cve_replay.py los reproduce como sus rutas de explotación originales — servidor de referencia vulnerable fijado vs. Cell, mismos archivos, controles positivos en ambos lados (2026-09-17, measured:true):

• CVE-2025-53109/53110 ("EscapeRoute", escape de symlink + recorrido de prefijo): el servidor de referencia vulnerable filtró el archivo protegido en ambas intenciones; Cell bloqueó ambas a nivel del motor (EPERM/ENOTCAPABLE) — con el control de capacidad concedida leyendo con éxito en ambos lados.
• Clase CVE-2025-54136 ("MCPoison", intercambio de payload después de la confianza): una herramienta firmada se acepta una vez, luego un solo byte wasm manipulado hace que la siguiente solicitud de carga gobernada falle de forma cerrada (desajuste de hash).
• Mismos replays contra componentes WASI 0.2 (evidencia, abi: "component"): la ruta de componentes deniega las mismas intenciones de escape (escape de symlink → EPERM, recorrido → sin base de preopen) y la misma manipulación de carga gobernada falla de forma cerrada. El vector de red tiene su propia intención — el mundo WASI 0.2 enlaza wasi:sockets (a diferencia de Preview1), así que se intenta una conexión TCP bajo el sandbox y se rechaza en tiempo de llamada, con el control de lectura concedida pasando en la misma ejecución.

Conformidad: probado contra las suites oficiales

No son suites de prueba propias — el CLI enviado y la configuración del motor que Cell envía se ejecutan contra ambas suites oficiales: la suite preview-1 de WebAssembly/wasi-testsuite a través de un adaptador de runtime, y la suite oficial de especificación central de WebAssembly (era W3C Wasm 3.0, arnés wast2json) — evidencia confirmada bajo conformance/results/:

• WASI: 72 aprobados, 1 xfail documentado por diseño, 0 fallos en las suites preview-1 aplicables (confirmación de suite fijada 609c44613995, 2026-09-14; 55 pruebas preview-3 omitidas — Cell declara solo preview 1)
• Especificación central (ejecutada 2026-09-19, fijada b464a4cd100d, 257 archivos / ~36k comandos): 31,931 aprobados con cada desviación documentada, ninguna inesperada — 3,282 clasificados (los módulos memory64/multi-memory están por diseño fuera de la configuración del motor enviada; v128 no puede pasar a través del enlace wasmtime-py 47; los archivos relaxed-simd abortan nativamente ascendente), 684 aserciones de formato de texto omitidas (dominio del analizador wabt), y un resto de 46 aserciones a nivel de bits NaN del enlace wasmtime-py, listadas textualmente en el JSON de evidencia. Reproducir: python conformance/run_core_spec.py
• Un trabajo de CI semanal reejecuta la suite fijada y sube el JSON crudo, así que la deriva aparece en una semana (.github/workflows/wasi-conformance.yml). Peculiaridad conocida y documentada del runner: los runners compartidos de ubuntu x86_64 muestran abortos raros del motor wasmtime en pruebas fs variables; el trabajo de CI absorbe cada aborto con un solo reintento registrado (adapters/cell_retry_wrapper.py, cada reintento visible en el JSON de evidencia) — una ejecución saludable alcanza 72 aprobados, como en la ejecución de CI del 2026-09-19 — determinista en macOS arm64 y en contenedores limpios (conformance/README.md)
• La única desviación está documentada: sock_shutdown-invalid_fd espera EBADF en un runtime sin preopens; el directorio scratch del sandbox de Cell se preabre como fd 3 por diseño, así que la llamada devuelve ENOTSOCK. La propiedad que Cell afirma — sin superficie de socket — no se ve afectada.
• Alcance honesto: esto es conformidad de estándares, no una certificación de seguridad. Ningún tercero certifica Cell; la evidencia es la suite fijada, el JSON confirmado y el historial de CI.

¿Puedes romper Cell? ¿Encontraste una ruta de ejecución que viole el límite de seguridad documentado — un escape, una evasión de presupuesto, una brecha de atestación? Ese es exactamente el informe que queremos: SECURITY.md (divulgación privada, manejo responsable). El modelo de amenazas y sus riesgos residuales documentados te dicen dónde apuntar; las cajas de metodología en esta página te dicen cómo medimos. La investigación de seguridad en Cell es bienvenida.

Rendimiento

¿Cuánto cuesta el límite de seguridad? 0.376 ms — la sobrecarga de reloj de pared en caliente que una ejecución en sandbox añade sobre el mismo trabajo ejecutado desnudo (medido, no estimado).

Último benchmark reproducible — 2026-09-14 · Mac M5 · wasmtime 47.0.1 · n=1000. Cada número abajo se regenera desde un clon fresco mediante los comandos al final.

Escenario (2026-09-14, n=1000, hello.wasm, Mac M5, wasmtime 47.0.1)	Mediana de pared	p95 de pared	Mediana del invitado
Motor agrupado (io_budget_bytes=None, ejecuciones confiables)	0.51 ms	0.89 ms	0.17 ms
Ruta por defecto (io_budget_bytes=64 MiB, motor por ejecución)	0.94 ms	1.15 ms	0.61 ms
Frío vs. cálido (2026-09-14, n=300 cada uno, sandbox limpio por ejecución vs. motor en caché, primera ejecución descartada): mediana en frío 0.59 ms invitado / 0.99 ms de pared, mediana en cálido 0.55 ms invitado / 0.93 ms de pared — sobrecarga del sandbox (pared cálido − invitado) = 0.376 ms (overhead_warm_ms, benchmarks/results/2026-09-14/pov_benchmark.json).

Comparación de arranque en frío en vivo (2026-09-14, mismo Mac, n=100 por imagen después del calentamiento): docker run python:3.12-slim 185.9 ms vs. Cell 0.49 ms = 383× — esto es una comparación de arranque en frío de contenedor vs. WASM invocado para esta carga de trabajo de referencia, no una afirmación general de que WASM siempre es más rápido que Docker.

Reproducir: python benchmarks/pool_vs_budget.py · python benchmarks/competitive_benchmark.py (resultados brutos con measured:true confirmados bajo benchmarks/results/). Cargas de trabajo agénticas y más: docs/performance.md.

Impuesto del sandbox en una carga de trabajo estándar de la industria (EEMBC CoreMark 1.01)

El mismo coremark.wasm confirmado (EEMBC CoreMark 1.01, fuentes fijadas, wasi-sdk-34) se ejecuta intercalado bajo tres configuraciones de Cell y, cuando sus CLI están en PATH, bajo motores externos — cada ejecución debe pasar la auto-validación de CoreMark. Las puntuaciones son las "Iteraciones/Seg" auto-medidas de CoreMark:

Puntuación mediana (n=3 intercalados)	macOS arm64 (wasmtime 47.0.1, wasmer 7.4.2, wasm3 0.9.0)	DGX Spark GB10 aarch64
wasmtime desnudo (referencia)	55,204	48,860
Sandbox de Cell	50,456 (−8.60%)	44,040 (−9.86%)
Cell + medición de combustible	43,054 (−14.67% vs. sandbox)	38,491 (−12.60% vs. sandbox)
wasmer (control externo)	63,798 (+15.57% vs. desnudo)	53,735 (+9.98% vs. desnudo)
wasm3 (control externo, intérprete)	5,566 (−89.92% vs. desnudo)	5,747 (−88.24% vs. desnudo)

Leer como hechos, no como clasificación: en esta carga de trabajo, la elección del motor abarca un rango de ~9–12× según la plataforma, la capa de sandbox de Cell cuesta 8.6–10.0% sobre el motor desnudo en la misma máquina, y la medición de combustible a nivel de instrucción un 12.5–14.7% adicional. Los motores externos son contexto, no competidores medidos por la API de Cell; wasmer requiere --enable-tail-call (la compilación incluye el conjunto de características upstream Lime1+tail-call). Evidencia con comandos verbatim, versiones y puntuaciones por ejecución: benchmarks/results/2026-09-19/09_coremark_wasi_*.json. Reproducir: python benchmarks/coremark_wasi.py --rounds 3.

El combustible es específico de la plataforma

Los conteos de combustible son deterministas por plataforma (fuel_spread: 0 en cada host medido) pero están vinculados a la plataforma — nunca comparar entre hosts (detalles y ejemplos medidos entre plataformas: docs/performance.md, python benchmarks/determinism_probe.py).

Backend del motor y modo de ejecución

Cada número en esta página es un número Cranelift: el enlace de Python no puede seleccionar un backend interpretado (Pulley/Winch inalcanzables, afirmado en tests/test_surface_audit.py), por lo que ningún fallback puede cambiar silenciosamente la postura. Detalles: docs/performance.md.

API y CLI

API de Python — la superficie principal es deliberadamente simple:

from ephemora_cell import run_wasm, run_isolated, WASIConfig, WASISandbox

result = run_wasm("tool.wasm", max_fuel=1_000_000, timeout_seconds=30)
result.status        # SUCCESS | ERROR | TIMEOUT | FUEL_EXHAUSTED | MEMORY_EXCEEDED
result.exit_code
result.stdout        # 10 KB cap
result.elapsed_ms
result.fuel_consumed

# OS-level process wall for untrusted guests:
result = run_isolated("tool.wasm", config=WASIConfig(max_fuel=500_000))

Perfiles (plugin, llm, edge, default, analytical), estado nombrado, cuotas de disco y límites de heap GC son perillas de WASIConfig; la ruta del componente se selecciona por llamada a través de run_wasm(..., abi="component") — docs/recipes.md tiene las recetas (FastAPI, serverless, air-gapped, WASI 0.2).

CLI — cuatro verbos cubren el bucle:

ephemora-cell run       Execute a WASM module (--json, --isolated, --fuel, --stdin, --profile)
ephemora-cell inspect   Imports, exports, memory — what a module wants, before you run it
ephemora-cell benchmark Cold/warm latency and fuel spread
ephemora-cell build     Compile Rust/Go/C/AssemblyScript/Zig straight to WASM

ephemora-cell --help y docs/recipes.md para la referencia completa.

Limitaciones

Cell es: una primitiva de ejecución WASM · una capa de aislamiento basada en capacidades · un runtime con recursos limitados · una biblioteca Python embebible · una CLI · una capa de ejecución MCP.

Cell no es: una VM general · un orquestador de contenedores · un sistema de detección de malware · una plataforma de nube multi-tenant completa · un marco de agentes · un LLM · un sistema de generación de código · un reemplazo de VM completo para cada carga de trabajo de contenedor.

Usa Cell cuando: el código no es confiable o se genera dinámicamente · las herramientas provienen de terceros · un agente de IA ejecuta programas arbitrarios · necesitas presupuestos de recursos explícitos · necesitas metadatos de ejecución estructurados. No uses Cell para servicios de larga duración con mucha E/S — para eso está el muro de subprocesos de --isolated o una microVM (ver docs/performance.md para la comparación de terceros medida).

Lo que cada control aplicado no afirma — cada fila es un límite honesto, probado en el límite:

Control aplicado	Garantiza	No garantiza
Límite de memoria (128 MB)	el invitado no puede exceder el heap configurado	comportamiento correcto del invitado — un error dentro del presupuesto es un error del invitado
Presupuesto de combustible	sin consumo de CPU sin límite; la ejecución se detiene en el límite	detección de malware — código con intención hostil que se mantiene dentro del presupuesto funciona bien; nada inspecciona lo que el módulo significa
Tiempo de espera de pared	sin ejecución descontrolada; la interrupción de época se dispara	que la lógica de la aplicación sea correcta o rápida
Denegación de red (sin APIs de socket)	sin sockets, sin conexiones salientes por el invitado	comportamiento seguro dentro de las capacidades otorgadas — la exfiltración a través de canales permitidos (por ejemplo, escribir secretos en un preopen otorgado) sigue siendo preocupación del integrador (SECURITY.md)
Control de capacidades del sistema de archivos (solo preopen, denegación por defecto)	acceso a archivos limitado a directorios montados explícitamente	semántica completa de VM — el contenido de la ruta montada es exactamente lo que el integrador eligió exponer
Límites de salida (10 KB)	la salida capturada está limitada; las impresiones sin límite no pueden llenar el disco del host	que la salida truncada esté completa — inspecciona result.stdout y el registro

El objetivo es estrecho: hacer que la ejecución no confiable sea lo suficientemente barata y controlada para que una aplicación pueda hacerlo de forma segura por defecto.

Detalles completos: SECURITY.md (política, limitaciones conocidas) · docs/threat-model.md (modelo de adversario, límites de confianza, matriz de agotamiento de recursos) · docs/security_posture.md (evaluación arXiv 2509.11242, límite de combustible, investigación relacionada).

Hoja de ruta

Elementos reales, con compuertas — sin fechas prometidas:

• Compuerta de actualización del motor (en progreso): wasmtime 48.0.3/49.0.1 cierra el aviso de amplificación de combustible de 2026 (GHSA-m63x-6p34-q65x) y el aviso de flujos WASIp3; bloqueado en la publicación de ruedas de Python a PyPI (vigilado por scripts/check_wasmtime_patch.py), luego re-calificación de determinismo de combustible y una re-ejecución estricta de la matriz de escape FS (tests/test_fs_escape_matrix.py — la ejecución medida del 2026-09-25 muestra que los vectores acompañantes ya están denegados en el motor fijado).
• Compuerta de evaluación WASI 0.3: WASI 0.3 (async del Modelo de Componentes) está deliberadamente bloqueado hasta que la superficie 0.3 se publique en las ruedas de Python, la línea de avisos de flujos esté cerrada, y la superficie tenga su propia calificación de presupuesto (docs/recipes.md).
• Fase de opt-in de subprocesos: los subprocesos de todo-compartido permanecen congelados por defecto; habilitarlos es un opt-in revisado por seguridad por separado con contabilidad de combustible y tiempo de pared consciente de subprocesos (SECURITY.md).

Pruebas y verificación

470 pruebas pasando (4 omitidas) · 86% de cobertura de declaraciones (Cell + MCP, compuerta 80%) · 8/8 vectores de ataque bloqueados · 72 pases de conformidad oficial wasi-testsuite (fijado, 0 fallos) · aplicado por CI en cada push (pruebas, cobertura, pip-audit, SBOM, bandit, interoperabilidad oficial del SDK MCP) — ver .github/workflows/ci.yml.

Documentación

Primeros pasos · Inicio rápido arriba · docs/recipes.md — patrones de uso (FastAPI, serverless, air-gapped, WASI 0.2) · integration/ — ejemplos de marcos de agentes

Seguridad y evidencia · SECURITY.md — política, matriz de ruta de ejecución, reporte de vulnerabilidades · docs/threat-model.md — límites de confianza, modelo de adversario, matriz de agotamiento de recursos · docs/security_posture.md — verificación de superficie de ataque · conformance/README.md — arnés oficial wasi-testsuite

Registros de ejecución y decisiones · ADR-006 — quién puede cambiar el límite de seguridad de una carga de trabajo en ejecución · ADR-001…008 — todos los registros de decisiones · examples/signed_record_demo.py — firmar y verificar manipulación de una ejecución

Rendimiento · docs/performance.md — puntos de referencia · benchmarks/results/ — JSON bruto de measured:true

Integraciones · docs/mcp.md — servidor MCP · docs/comparison-mcp-servers.md — mapeo CVE-a-sonda · action/ — acción compuesta de GitHub

Lenguajes · docs/languages.md — matriz de compilación · docs/egress_patterns.md — patrones de llamadas API sancionados

Empresa · docs/enterprise.md — aislamiento vs. operación: cuando vale la pena tener esa conversación

Cambios · CHANGELOG.md

Acerca de Ephemora

Ephemora Cell es la capa de aislamiento de código abierto (Apache 2.0, independiente — sin dependencia de Ephemora). La edición empresarial de Ephemora se basa en el aislamiento de Cell para despliegues de producción y regulados. Cell está completo para aislamiento; la edición empresarial está completa para operación — ver docs/enterprise.md para cuándo vale la pena tener esa conversación.

Licencia

Apache 2.0 — Ver LICENSE.

---

mcp-name: io.github.MichaelS1011/ephemora-cell-mcp

---

Una acción de agente. Una ejecución limitada. Un resultado controlado.

Creado por Michael Soppa.