Ephemora Cell: a capability-based WASM sandbox for untrusted AI code

A developer released Ephemora Cell, an open-source capability-based WASI/WASM sandbox for running untrusted AI agent code, MCP tools, and plugins under explicit, enforceable limits. In the project's published comparison, a stock python:3.12-slim container blocked 0 of 8 documented attack primitives while Ephemora Cell blocked all 8, with pooled warm runs reported in the sub-millisecond range on its benchmarks. The project also ships a dependency-free MCP stdio server and a GitHub Action for running WASM in CI under the same class of limits.

AI agents do not only answer questions. They write code, call tools, and load plugins. The hard part is not starting that work. It is what the code is allowed to do once it runs. Permission systems answer “may it run?” They do not answer “how far may it run?” Ephemora Cell is a small open-source execution layer for that second question. It runs untrusted workloads inside a capability-limited WASI runtime: agents, MCP tools, plugins, code interpreters. Repo: https://github.com/MichaelS1011/ephemora-cell https://github.com/MichaelS1011/ephemora-cell pip install ephemora-cell · Apache-2.0 The shape of the problem AI Agent → Tool / MCP → Ephemora Cell → WASM → bounded result Cell is not an agent framework. It sits under the stack you already have. The guest gets only the capabilities you grant. Everything else is closed by default. Same attacks, different boundary We ran eight documented attack primitives against: a stock python:3.12-slim container Ephemora Cell In that comparison: Docker 0/8 blocked, Cell 8/8 blocked. Shell, fork, sockets, host filesystem, symlink-style escapes, and related vectors are covered by the suite in the repo. Reproduce with the scripts under assets/ and benchmarks/. This is not a universal security guarantee. It is a measured comparison for those vectors. Cell does not decide whether guest code is “good.” A module can still misbehave inside the budgets it received. Performance why you can sandbox every call Cold-starting a container for every tool call is expensive. Cell is aimed at warm, per-call isolation. On our published benchmarks, pooled warm runs sit in the sub-millisecond range for a simple guest; raw results live under benchmarks/results/. Always treat latency numbers as workload- and machine-specific. MCP : tools need a runtime An MCP tool is not only a JSON schema. It is code that runs. Cell ships a dependency-free MCP stdio server. Tools are WASM modules executed inside the same boundary. Responses can carry execution metadata: cost fuel, ms , policy, and outcome — so “what did it return?” and “under which limits?” stay together. pip install ephemora-cell ephemora-cell-mcp There is also a GitHub Action to run WASM in CI under the same class of limits including an isolated path with OS-level walls . Any language that compiles to WASI/WASM can be a guest. The repo CI exercises several toolchains. What Cell is — and is not Is: an execution primitive with explicit, enforceable limits and inspectable results. Is not: a claim that models are safe, that prompt injection is solved, or that residual risk is zero. Trust comes from a narrow boundary and budgets you can measure — not from a promise that the guest is benign. If you build agents or MCP tools and care about what happens after the tool is selected, take a look at the repo, run the attack scripts, and break it. Technical criticism is welcome, especially on the WASI surface and the vector suite.