Enhancing Ephemora Cell Through the Lens of Runtime OS: Transforming a WASM Sandbox into a Verifiable AI Execution Platform

🎥 The YouTube version is also available:

What Is Ephemora Cell? Governing AI Agent Execution with Capabilities, Permits, Human Gates

Books: Runtime Al Governance Practical Guide: Dynamic Al Governance Design through Knowledge Flow, Trust Engine, and Decision Trace

When AI agents connect to business systems, what matters is not only how capable the model is. We must also ask: under whose authority, for what purpose, and to what extent may the code generated by an agent—or the tools it invokes—be executed? And after execution, can its validity be verified?

Ephemora Cell is an interesting entry point to this problem. It runs AI-generated code not in microVMs, but in a capability-based WASM sandbox. Each invocation is given a budget for CPU, memory, time, I/O, and file-system access, and after execution it generates an execution record that can be normalized with JCS and signed and verified using ES256.

This is a design intended to handle short-lived tool executions in a smaller, faster, and auditable form than starting a Docker container. Its role inside an MCP Tool Call is also clear.

However, from the perspective of a Runtime OS, Ephemora Cell may be a powerful core for a “safe executor,” but it does not by itself complete the execution governance required for enterprise AI.

Place Ephemora Cell as the Execution Kernel, put Permit and Boundary in front of it, and connect Human Gate and a Decision Trace Ledger after it.

With this structure, AI evolves from something that merely executes code into something that collaborates within defined authority, purpose, constraints, and accountability.

The Problem Ephemora Cell Solves

Allowing an agent to execute code directly on the host is dangerous. Docker and microVMs can improve isolation, but their startup cost and operational weight can become a problem when agent workflows repeatedly invoke short functions.

Ephemora Cell combines WASM with capability-based security and limits executable operations from the outset. It explicitly defines which inputs may be read, which outputs may be written, which I/O may be used, and which resources may be consumed. Execution remains within those budgets, while results and resource consumption are retained as an Execution Record.

In Runtime OS terms, this corresponds to Isolation and Trace.

But enterprise AI also requires evaluation before execution: purpose, authority, risk, and business rules. It requires escalation to people when necessary, as well as explainability after execution.

Execution Budgets and Business Authorization Are Different Problems

Consider an MCP tool that aggregates quotation data. Ephemora Cell can impose technical boundaries such as: 500 ms, 64 MB, read access only to an input CSV, and write access only to an output JSON file.

On its own, however, it does not answer the following questions:

• Is the requester authorized to read this quotation data?
• May the aggregation result be used to rank procurement candidates?
• If the price difference is substantial, should a responsible person review it?
• May the result proceed to email delivery or an update to a core business system?
• Who is responsible for reassessing an exception?

Technical capabilities limit what can be done. A Runtime OS Permit determines whether a particular actor may perform a particular action in this situation. Designing these as separate concerns is essential.

Improvement 1: Put an Execution Permit Before Execution

Place an Execution Permit in front of Ephemora Cell. Rather than passing an invocation from MCP directly to the Cell, a Permit Engine first determines whether execution is allowed.

A Permit should include the purpose, delegating authority, target data, operational scope, expiration, and additional conditions. It should be treated not as a simple API token, but as a Delegation Contract.

{
  "purpose": "estimate_review",
  "principal": "procurement-agent",
  "delegated_by": "user_123",
  "tool": "estimate_rule_check",
  "scope": {
    "input_dataset": "estimate-2026-q3",
    "allowed_operations": ["read", "calculate", "write_report"]
  },
  "constraints": {
    "max_amount_jpy": 5000000,
    "external_network": false,
    "human_review_required_if": ["price_deviation_over_15pct"]
  },
  "expires_at": "2026-09-13T12:30:00Z"
}

The Cell converts only the scope allowed by the Permit into WASM capabilities. These become concrete execution boundaries: no network access, permission to read only specified inputs, permission to write only specified outputs, and a maximum execution time of 500 ms.

Improvement 2: Extend Budgets into Risk Budgets

In addition to CPU, memory, time, and I/O budgets, enterprise AI needs a risk budget.

Technical success alone does not mean an action should become Act. Even if quotation comparison completes normally, a deviation above 15% should produce Ask and be routed to a human for review. High-impact actions—such as renewing an existing contract or executing a payment—should pass through a Human Gate from the outset.

Improvement 3: Extend the Signed Payload to Include Decision-Making Records

JCS normalization and ES256 signatures are useful for tamper detection and verification of Execution Records. But signing only execution time and memory consumption is insufficient in a business context.

The signed payload should be expanded into a Decision Trace.

MCP Tool Call
  → Identity / Delegation Verification
  → Permit Engine
  → Boundary Compiler
  → Ephemora Cell (WASM Execution)
  → Result Evaluation
  → Act / Ask / Stop
  → Decision Trace Ledger

What needs to be reviewed later is not merely “who executed what.”

• Which policy allowed the execution?
• Under which capabilities and budgets was it executed?
• What were the inputs, module, and outputs?
• Why did the result become Act, Ask, or Stop?
• Did a person approve it or send it back for revision?

Inputs should not be stored indiscriminately. Hashes, reference IDs, and masked summaries should be the default. By carrying the previous Trace Hash into the next record, the history of decisions and execution can be verified in sequence.

Improvement 4: Treat the Human Gate as a Design Element

Human review should not be treated merely as exception handling for failures. There are decisions that people should review even when the process is functioning correctly.

• Act: Automatically execute as a low-risk operation within scope.
• Ask: Hold the result or the next operation pending human approval.
• Stop: Do not execute because it violates a boundary, authority, budget, or policy.

Ephemora Cell executes small, isolated operations that have been approved as Act. In the Ask case, the Cell’s output and Decision Trace are passed to a review interface. In the Stop case, code is not executed, or execution is limited to a non-impacting validation mode.

This allows people to avoid monitoring everything while reliably governing the important boundaries: money, personal data, contracts, and external communications.

Conclusion: A Cell Can Become a Kernel, but It Is Not an OS

Ephemora Cell can become a powerful Execution Kernel for running AI-generated code in a small, fast, capability-constrained environment and retaining the result as a verifiable record.

But business use requires more than a sandbox.

The central question is not only what may be executed, but why this execution is permitted now.
What happens after execution, who can verify it, and where can the system be stopped when something goes wrong?

A Runtime OS answers these questions.

By connecting Permit, Boundary, Human Gate, and a Decision Trace Ledger before and after Ephemora Cell, MCP can evolve from a simple tool-connection standard into a transport layer for execution contracts with enforceable constraints.

Fast WASM execution and verifiable Decision Trace: connecting these two is a practical step toward moving AI agents from experimentation into real business use.

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance