Ephemora-cell: Building a Constrained Execution Layer for AI Agents

When AI Agents Execute Code, Who Guards the Boundaries?

As autonomous agents and MCP (Model Context Protocol) tools become increasingly prevalent, a long-underestimated security concern is coming to the surface: how do we safely run AI-generated code? The open-source project Ephemora-cell, currently gaining traction in developer communities, offers an engineering answer — a WebAssembly-based constrained execution layer that isolates and restricts untrusted workloads produced by agents.

The core tension is this: an AI agent may be authorized to perform only a narrow set of operations, yet the code it actually generates can exhibit unexpected behavior. As the project's author emphasizes, "Prompt-level instructions aren't the same thing as runtime enforcement." This statement points to a critical blind spot in current agent security architecture — we often impose restrictions at the intent layer while leaving the execution layer wide open.

What Ephemora-cell Does

Ephemora-cell is a WebAssembly execution layer accessible via Python, designed specifically for running untrusted agent-generated code. Its design philosophy stands in sharp contrast to conventional approaches: rather than granting generated code ambient host access, it adopts a model built on explicit capabilities and resource budgets.

On a practical level, Ephemora-cell creates a fresh execution environment for each run and enforces multi-dimensional constraints:

• Fuel (computation) limits: Controls the number of instructions the code can consume
• Memory limits: Constrains runtime memory usage
• Time limits: Prevents indefinite hangs or infinite loops
• Output limits: Restricts the size of returned data
• External resource access limits: Cuts off implicit access to the host environment

After execution, the system returns not just the result itself, but also resource-accounting data and policy metadata. This means every execution is auditable and traceable — not a black box. The project also supports signing and verification mechanisms to provide assurances about code provenance.

WebAssembly (WASM) is a low-level instruction set that runs in binary format, originally designed for browsers. However, its core characteristics — memory isolation, explicit capability declarations, and strict separation from the host environment — have made it an increasingly popular choice for server-side sandboxing. WASM modules run within a linear memory space and cannot directly access the host machine's filesystem, network, or system calls; any external interaction must go through interfaces ("imports") explicitly exposed by the host. This contrasts with the traditional process model, where processes inherit a broad set of environmental permissions from their parent and must actively restrict them. WASM modules, by contrast, start with zero permissions and must be explicitly granted access. Runtimes like Wasmtime and Wasmer also introduce a "Fuel" metering mechanism, allowing the host to set an upper bound on the number of instructions a WASM module may consume — enabling computation-level enforcement at the language runtime level. This is the technical foundation behind Ephemora-cell's Fuel limiting feature.

Integration with the MCP Ecosystem

Notably, Ephemora-cell provides MCP integration, exposing WASM-based tools for agents to consume. This aligns with the rapid expansion of the MCP protocol ecosystem — an ever-growing number of tools and data sources are being connected to agents via MCP servers, and the execution safety of those tools is becoming a focal point of architectural design.

Using a WASM sandbox as the runtime foundation for MCP tools effectively inserts a controllable isolation layer between agents and real systems. Agents can still invoke tools to accomplish tasks, but tool behavior is constrained within predefined capability and resource boundaries. For developers building MCP servers, this offers a more reliable approach than simply "trusting the prompt."

MCP (Model Context Protocol) is an open protocol championed by Anthropic, designed to standardize how AI models interact with external tools and data sources. It plays a role similar to what LSP (Language Server Protocol) does for the editor ecosystem: through a unified protocol layer, agents can invoke tools — filesystems, databases, APIs, or custom business logic — in a consistent way, without writing separate integration code for each one. MCP servers expose tool definitions and execution capabilities; agents (clients) initiate calls through the protocol. As the MCP ecosystem expands rapidly and more third-party developers build and publish MCP servers, the trustworthiness of tool code varies widely — making "who ensures MCP tool execution safety" an urgent architectural question.

Architectural Trade-offs: Where Should Execution Permissions Be Enforced?

The central question the project author poses to the community is one that remains unresolved across the broader agent security landscape: at which layer should execution permissions actually be enforced?

Several common approaches exist today:

Agent Framework Layer

Permission controls are implemented within the framework itself. Easy to integrate, but the isolation is weak — once generated code bypasses the framework's logic, the constraints become meaningless.

Container Layer

Docker and similar containers provide mature, general-purpose isolation, but carry non-trivial startup overhead, coarse-grained resource accounting, and make per-invocation auditing difficult.

Dedicated Execution Service

A standalone execution service (the direction Ephemora-cell represents) enables fine-grained capability control and resource budgeting with clear isolation boundaries. The trade-off is the introduction of an additional architectural component and added operational complexity.

The distinctive value of the WebAssembly approach lies in its inherently lightweight sandbox characteristics, fast startup times, and explicit capability model — striking a relatively balanced position between isolation strength and execution overhead. That said, this class of solutions does have potential failure modes: vulnerabilities in the WASM runtime itself, gaps in capability configuration, and the risk of escape through host bridging interfaces.

Current Status and Positioning

Ephemora-cell has been publicly released as v1.1.0, with examples, tests, and clearly documented security boundary documentation. The project is hosted on GitHub (MichaelS1011/ephemora-cell) under a BUSL-1.1 source-available license — meaning the source code is visible but commercial use is restricted.

For engineering teams building MCP servers or autonomous agents, Ephemora-cell may not be the final answer, but it articulates a compelling engineering proposition that demands attention: in an era where agents can autonomously write and execute code, runtime enforcement is far more worth investing in than prompt-level instructions. As agent autonomy continues to grow, constrained execution layers may well evolve from an "optional extra" to a mandatory component of agent infrastructure.

BUSL-1.1 (Business Source License 1.1) is a "source-available but commercially restricted" license model originally proposed by MariaDB and adopted by notable projects including HashiCorp and Sentry. The core terms are: source code is publicly readable and usable for non-production or non-commercial purposes, but commercial use in production environments is prohibited during a specified time window (typically four years), after which the code automatically converts to a designated open-source license (typically GPL or Apache). For engineering teams evaluating Ephemora-cell, this means you can freely read the code and integrate it in test environments, but if you intend to deploy it in a commercial product, you'll need to review the specific license restrictions or negotiate a commercial license with the author.