DEV Community: M.S.

ephemora-cell 1.0.4: a stateless MCP tool server, now on PyPI!!

M.S. — Mon, 21 Sep 2026 18:44:59 +0000

No initialize handshake. No session state. Restart or load-balance the server between calls — clients never notice. tools/list answers with CacheableResult fields (ttlMs: 3600000, cacheScope: "private") so hosts can cache the tool list, and unknown versions are rejected with -32022 naming the supported list — never silently swallowed.

Handshake-era clients (Claude Desktop, VS Code, Codex) keep working unchanged. Both eras, one process — with a test that runs them mixed against one server instance.

get-policy now attests what execution actually grants We caught our own policy report underreporting the filesystem surface: it said preopens: [] while every core-module run actually grants the ephemeral sandbox dir as /sandbox. The fix derives the reported preopens from the same truth as the run witness — and a test now executes a real tool and fails CI if report and witness ever diverge again:

python
reported = engine.policy_for(spec) # what get-policy says
outcome = engine.execute(spec, params) # what actually ran
assert reported["preopens"] == \
outcome.report.security_baseline["preopens"]

One version, three signals The previous wheel said 1.0.3 on the box and 1.0.1 on the wire. Version is now single-sourced — and a test enforces pyproject.toml == runtime version forever.

How we verified it
Fresh venv, plain pip install ephemora-cell, 13/13 acceptance checks against the published wheel: both MCP eras, version negotiation, policy/witness agreement, legacy compatibility unchanged. Bonus finding: the same echo call consumed identical fuel (21143) across two different installs on different machines — the determinism claim held in the wild.

Try it

bash
pip install ephemora-cell
ephemora-cell-mcp # bundled clock + echo; --tools-dir for your own
Feedback welcome — repo, issues and the full CHANGELOG are at https://github.com/MichaelS1011/ephemora-cell

1.000 concurrent sandboxes. 845 executions per second. 7.4 ms P50 latency. 0 errors. Ephemora Cell on DGX Spark, isolation that actually scales. Not just a sandbox. A measurable execution boundary. https://github.com/MichaelS1011/ephemora-cell

M.S. — Thu, 17 Sep 2026 10:50:57 +0000

GitHub - MichaelS1011/ephemora-cell: Ephemora Cell — The execution layer for untrusted AI-generated code. Fast, capability-based WASM execution with explicit CPU, memory, time, I/O, and filesystem limits. · GitHub

Ephemora Cell — The execution layer for untrusted AI-generated code. Fast, capability-based WASM execution with explicit CPU, memory, time, I/O, and filesystem limits. - MichaelS1011/ephemora-cell

github.com

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

M.S. — Sun, 13 Sep 2026 22:00:00 +0000

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

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.

GitHub: https://github.com/MichaelS1011/ephemora-cell