Ephemora Cell MCP — WASM Sandbox について
Ephemora Cell は、エージェント、プラグイン、MCP ワークロードの未信頼 WASM コードを実行するための境界です。エージェント基盤の開発者向けに、実行ごとの機能・リソース制限と検証可能な記録を提供し、公開版と main ブランチの制御機能を区別しています。
主な機能
- 01未信頼 WASM コードの隔離実行
- 02燃料、メモリ、時間、I/O の上限設定
- 03ファイルシステムとネットワーク機能の制御
- 04署名可能な実行記録の生成
- 05Python API と CLI からの利用
活用シーン
- 01エージェント生成コードのリソースを制限
- 02ツールやプラグイン内で未信頼モジュールを実行
- 03実行結果、コスト、ポリシーを確認
MCP 対応
MCP ワークロードの下位に置く WASM 実行バックエンドとして、未信頼コードの制限付き実行と記録を提供できます。README には MCP 連携への言及がありますが、MCP サーバーのツールは具体的に記載されていません。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
3掲載時のツール一覧 · 2 週間前に更新
このツールにパラメーターはありません。
詳細
Ephemora-cell
Ephemora-cell は、信頼できない AI やエージェントが生成したコードのための、一時的でステートレスな、機能制限に基づく実行境界です。
create → constrain → execute → prove → destroy
実行は毎回クリーンな状態から始まり、ホストが許可した制限(燃料、メモリ、時間、I/O、出力サイズ、ファイルシステム、ネットワーク機能)のもとで実行されます。何が起きたかを示す署名付きの証拠を生成でき、実行状態を次の実行に引き継ぐことなく終了します。
証拠は残ります。実行状態は残りません。
一時的。ステートレス。機能制限に基づく。検証可能。
実行状態や権限が暗黙的に引き継がれることはありません。名前付き状態は、ホストが意図的に接続する、別個の制限付き機能です。これは実行の永続化でも、ストレージでもありません(設計上ステートレス)。
AI エージェント、MCP ツール、プラグイン、コードインタープリター、その他の信頼できないワークロード向けに構築されています。統合経路は AI Agent / Application → Tool / Plugin / MCP → Ephemora-cell → WASM module です。以下の図では、その実行の一例として、境界が許可するもの、デフォルトで拒否するもの、そして残るものを示します。
クイックスタート · 適用される制約 · ステートレス性 · セキュリティの根拠 · ご自身で評価 · MCP · ベンチマーク · ドキュメント
最新リリース:v1.1.0 · PyPI · 署名済み GitHub リリース · BUSL-1.1。 リリースノート:CHANGELOG.md · 対応バージョン、および固定された wasmtime==49.0.0 ランタイムに対する 2026-09-24 と 2026-10-02 の wasmtime アドバイザリ対応状況(実測データに基づいてトリアージ済み):SECURITY.md · 最新の再現可能な測定結果:2026-10-02 のインタープリターゲスト実行、benchmarks/results/ · インストール状態ごとの実測件数:docs/release_assurance.md。
「安定」が意味するもの、意味しないもの。 ここでいう安定とは、公開 API の仕様とそのリリースゲートを指します。これらはリリースに含まれ、文書化され、機械的に検査されます。信頼できないワークロードに対する本番環境向けセキュリティの承認を意味するものではありません。独立したレビュー担当者による承認はまだなく、固定された Wasmtime 系統には、修正済みホイールが PyPI に公開されていないアドバイザリが残っています(SECURITY.md)。さらに、最新の隔離制御は公開リリースではなく、main にのみ存在します。コミットごとに、どのビルドにどの制御が含まれるかについては、docs/release_assurance.mdをご覧ください。
Wasmtime は WASM ランタイムを提供します。Cell はその周囲にアプリケーションレベルの境界を構築します。WASM は仕組みであり、信頼できないコードの制御された実行が製品です。
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
エージェントが実行するコードを安全にするうえで重要な問いは、次のとおりです。エージェントに信頼できないコードを実行させながら、そのコードがホスト、認証情報、ネットワーク、無制限の計算リソースに暗黙的にアクセスできないようにするにはどうすればよいでしょうか? 生のランタイムでは、その境界の構築はユーザーに委ねられます。Cell そのものが境界です。オペレーターは明示的に機能を許可できます。また、許可はすべて実行記録に記録されます。
エージェントが生成するコードは、アプリケーションコードとは異なります。バグが含まれたり、計算量が際限なく増えたり、予想外のコストが発生したり、悪意のあるコードだったりする可能性があります。そのため、ランタイムは境界を説明するのではなく、強制します(Cell が強制する内容)。また、実行結果は単なる戻り値ではありません。すべての実行は、_meta.execution に添付され、正規化(RFC 8785 JCS)され、署名可能な形で、次の 3 つの問いに同時に答えます。
| 回答 | フィールドの例 | |
|---|---|---|
| RESULT | 何が返されたか | status、stdout、exit_code |
| COST | どれだけのコストがかかったか | fuel_consumed、elapsed_ms |
| POLICY | どのルールのもとで実行されたか | メモリ制限、preopens、ネットワークポリシー、wasmtime_version |
「検証可能。主張ではない。」はスローガンではなく、データです。記録のフィールドを 1 つ書き換えると、verify() は失敗します。python examples/signed_record_demo.py で実行できるデモをご覧ください。ランタイム、セキュリティ境界、使用量の記録を、1 回の pip install で利用できます。
Cell は汎用コンテナーの代替品ではありません。小さな機能サーフェスと明示的な使用量の記録を求める、高頻度の信頼できないエージェントおよび MCP ワークロードを対象としています。また、エージェントインフラストラクチャでは、新しいフレームワークを必要とせず、既存のハーネスの下で軽量な実行バックエンドとして機能できます。トレードオフは明確です。汎用性はフル機能の Linux サンドボックスより低くなりますが、その代わりに実行サーフェスを小さくし、機能制御を厳格化し、呼び出しごとのオーバーヘッドを低減します。経路ごとの測定値はパフォーマンスをご覧ください。
クイックスタート
3 つのコマンドで、Cell をインストールし、信頼できないものを実行して、監査済みレシートを読み取ります。
1 — インストール(仮想環境を使用してください。Ubuntu ≥ 23.04/Fedora では、PEP 668 により仮想環境なしの pip install は拒否されます。Windows では Git Bash または WSL を使用し、python3 の代わりに python を使ってください):
python3 -m venv .venv && source .venv/bin/activate
python -m pip install ephemora-cell
以下の説明を機能として読む前に、実際に手元にあるビルドを確認してください。公開リリースと現在のソースは同じバージョン文字列(1.1.0)を報告していますが、同じ制御機能は備えていません。コンポーネント分離ゲートと、それを証明するレシートのフィールドは、リリース後に追加されました。
python -c "from ephemora_cell.execution_report import TRUST_UNKNOWN"; echo $?
# 0 → source at main: the enforcement gate is present
# 1 → published 1.1.0 wheel: no component isolation gate, no attestation fields
これらの制御機能を試すには、コミットを固定したソースインストールが必要です。
git clone https://github.com/MichaelS1011/ephemora-cell.git && cd ephemora-cell
git checkout <full-commit-sha> # pin what you are evaluating; record `git rev-parse HEAD`
python -m pip install -e .
2 — 信頼できないものを実行する(リポジトリに付属するサンプルを使うか、任意の .wasm を用意してください):
git clone https://github.com/MichaelS1011/ephemora-cell.git && cd ephemora-cell
ephemora-cell run examples/hello.wasm --isolated
(実行時に OS レベルのプロセス分離を追加します。自分でビルドしていないコードには推奨します。それぞれの方式のコストはパフォーマンスで測定しています)
Hello from Ephemora Cell!
3 — 監査済みレシートを読み取る — 同じ実行の機械可読な結果です。ここでは悪意のあるモジュール(examples/fuel_bomb.wasm)に 100 単位の燃料予算を与え、予算どおりに停止させます。
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
}
Python からも同様に実行できます。すべての結果には、ステータス、コスト、取得した出力が含まれます(全機能についてはAPI、CLI、統合を参照してください)。
from ephemora_cell import run_wasm
result = run_wasm("examples/fuel_bomb.wasm", max_fuel=100)
result.status # <ExecutionStatus.FUEL_EXHAUSTED: 'fuel_exhausted'>
result.fuel_consumed # 100 — the budget, not an estimate
result.stdout # '' — captured output, capped at 10 KB
失敗はクラッシュせず、段階的に報告されます。無限ループはレシート付きで status: "fuel_exhausted" を返し、メモリを過剰に使用するコードは memory_exceeded を返し、クラッシュはゼロ以外の終了コードを返します。これらは、自動採点器と CI のテストベンチジョブが使用するものと同じステータスです。分離された実行方式では、失敗は OS レベルの制限と強制終了機能を備えた使い捨てワーカー内に封じ込められます。
次のステップ: エージェント/ツールの分離 → MCP 統合 · 信頼できない PR に対する CI のゲート設定 → 複合アクション · CLI リファレンスと使用例(トラブルシューティング一覧も含む)→ docs/recipes.md。

実際の CLI セッション — 各行は、その直前に表示されたコマンドの出力をそのまま記載しています。インストールするのは PyPI の 1.1.0 ホイールです。examples/ と benchmarks/ のパスはリポジトリのクローンであり、最後の場面の直前にはオプションの tools-signing エクストラをインストールする必要があります。一連の流れは 1 回の実行で構成されています。新規実行 → 適用された境界(燃料、メモリ制限、事前オープン、allow_fsync: false)→ 暴走するモジュールを 100 単位中ちょうど 100 単位で停止 → ランタイムに対して測定した拒否(ポジティブコントロールを含む)→ 1 つのフィールドの書き換えを検知する署名済み証拠。実時間とスループットは意図的に表示していません。プラットフォームによって異なり、デモに表示すると、いずれ誤った主張になってしまうためです。
Cell が強制すること
Cell はゲストコードを信頼できないものとして扱います。ホストがゲストのアクセス可能範囲を決定し、ランタイムが実行ごとにその決定を適用します。ゲストがそれを無効にすることはできず、制限を広げた実行では、その事実がレシートに記録されます。デフォルトでは、ゲストには暗黙的なアクセス権が一切ありません。ネットワーク、任意のファイルシステム、プロセスの起動、制限のない環境へのアクセスはできず、CPU、メモリ、時間、出力には上限があります。これらのいずれかを許可する場合は、ホストが明示的に決定し、その内容が記録されます。
- 慣習ではなく、ケイパビリティです。 プリオープンは許可時に再検証され、ホストはゲストが書き込み可能な名前をたどりません。ホスト側のアーティファクト読み取りでは、共有パス上でアトミックに公開するとともに、
O_NOFOLLOWとファイル記述子レベルでの通常ファイル検証を使用します(SECURITY.md)。 - 正確に計上されるリソース制限です。 フューエルは与えられた予算に達するとループを停止し、エポック期限はフューエルで計上されない処理すべてを対象とする上限です。メモリ、出力、ホスト I/O の処理には、それぞれ独自の上限があります(下表)。
- ステートレスな実行です。 サンドボックスディレクトリはなく、エンジンが前回の実行状態を再利用することもなく、権限を継承することもありません(設計によるステートレス性)。
- 強制する前に認証する、仲介された外向き通信です。 デフォルトではゲストの接続は成功しません。Preview1 にはソケットのインターフェースがなく、WASI 0.2 の経路では呼び出し時に
connectが拒否されるため、ホストが接続を開くまでは仲介の対象がありません。運用者が接続を開く場合、各許可は、許可ディレクトリの外部に保持された信頼ルート内の鍵で署名された DSSE エンベロープです。アーティファクトと一緒に配布された鍵は、そのアーティファクトの正当性を何も証明しません。また、許可は運用者の許可リストを置き換えるのではなく、そこから範囲を狭めます。URL ごと、リダイレクトの各段階ごと、リソース上限ごとに適用され、期間、上限、取り消しはリクエストごとに強制されます。--egress-grants-requiredを指定すると、フォールバックが無効になります(ADR-013、docs/egress_patterns.md)。 - 解決済みアドレスを固定します。 名前解決の結果がループバック、RFC1918、CGNAT、リンクローカル、またはメタデータ用のアドレス空間を指す場合、名前解決時に拒否されます。接続先には検証済みのアドレスを使用します。この判定は
ipaddress.is_privateではなく、Cell 独自のアドレスレジストリに基づきます(SECURITY.md、DNS リバインディングに関する注記)。 - 署名付きの証拠です。 レシートには呼び出し元に提示される正確な正規化済みバイト列が署名され、新しい
report_idと発行時刻が含まれます。Cell の外部にある検証者が、同じレシートを以前に見たことがあるかどうかを判断します。有効な署名が証明するのはそのバイト列であり、実行が安全だったことではありません。また、対象が一致しない場合は何の権限も与えません。レシートは許可ではなく、許可はレシートではありません(SECURITY.md)。 - デフォルトでフェイルクローズです。 許可セットの破損、台帳の読み取り不能、権限ディレクトリが空であること、不正なリクエストはいずれも、監査対象の拒否となり、黙って許可されることはありません。安全なタイミングが起動時である場合は、起動時に拒否します。
セキュリティは決してオプトインではありません。 すべての実行(プロセス内でも隔離環境内でも)で、フューエル、メモリ、実時間、出力の各制限が強制されます。呼び出し元が設定できるのは制限の大きさであり、制限を設けるかどうかではありません。意図的な例外が 2 つあり、該当箇所ではその内容が明記されています。max_wasm_bytes(実行時に読み込めるモジュールのサイズ。interpreter プロファイル以外では 32 MiB で、独自のゲストを持ち込む場合に備えて同プロファイルでは 512 MiB に引き上げられます)と、allow_fsync(WASI の同期呼び出しを許可するかどうか。提供されるプロファイルでこれが有効になるものはなく、明示的に --allow-fsync を指定した場合のみ有効になります)です。どちらも署名付きベースラインに記録されるため、制限を広げた実行がデフォルトの実行と誤認されることはありません。ベースラインが示すのは設定値だけではありません。実際に使用された隔離経路(execution_mode)、実際に実行された ABI(abi)、同期呼び出しの遮断が実際に有効だったか(sync_blockade_enforced)も記録します。そのため、同期呼び出しのトラップを持たない経路で実行される WASI 0.2 コンポーネントは、デフォルトの allow_fsync: false であっても、遮断が強制されていないと記録されます。設定されたポリシーを、検証済みの保証とみなすことは決してありません(SECURITY.md)。
隔離は単に選択肢として提供されるのではなく、コンポーネントに対して強制されます。 WASI Preview1 モジュールでは、プロセス境界を適用するかどうかは呼び出し側が選択します。自分たちでビルドしたものではないモジュール(エージェントの出力、サードパーティ製プラグイン、PR で提供されたコードなど)には、--isolated を追加するか、run_isolated() を呼び出してください。WASI 0.2 コンポーネントでは、これは任意ではありません。ホストが明示的に trusted とマークしていないコンポーネントは、untrusted の値も、指定されていない unknown も、どちらも信頼されていないものとして扱われ(フェイルクローズ)、実行エントリーポイントにある中央ゲートによって必ずサブプロセス経由で実行されます。ゲートは隔離レベルを引き上げることしかしません。引き下げることはなく、ワーカーを利用できない場合は、インプロセス実行に暗黙的にダウングレードせず、実行を拒否します(ERROR)。暗黙のフォールバックはありません(ADR-015、SECURITY.md)。例外は一つだけです。低レベルの ComponentSandbox プリミティブを直接使用する場合は、意図的にゲートを迂回します。これはゲートとワーカーが依存する内部エンジンであり、ポリシー境界ではありません。これを使用する呼び出し側が、自らポリシーを適用する責任を負います。
この段落は現在のソースについて説明しています。ゲートと上記の 3 つのアテステーションフィールド(execution_mode、abi、sync_blockade_enforced)は 1.1.0 リリースの確定後にマージされたため、公開済みのホイールには含まれていません。また、次のリリースでバージョンが更新されるまで、main のバージョン文字列は 1.1.0 のままです。Quick Start の 1 行の有無チェックで 2 つのビルドを見分けられます。コミットごとの制御マトリックスは docs/release_assurance.md にあります。
強制適用されるデフォルト設定:
| リソース | デフォルト |
|---|---|
| WASM メモリ | 128 MB(Store.set_limits) |
| Fuel/CPU 予算 | 1,000,000 — 実行中に Fuel の上限を超えることはありません。測定値は 1 イテレーションあたり約 13 Fuel(R² = 1.000)、プラットフォームごとに測定(docs/performance.md) |
| 壁時計タイムアウト | 30 s(エポック割り込み) |
| キャプチャされる stdout/stderr | 10 KB |
| ネットワーク | デフォルトで無効 — Preview1:ソケット API なし。WASI 0.2:リンクされますが、呼び出し時に拒否されます(測定済み) |
| ホストファイルシステム | デフォルトで拒否。危険なディレクトリ 14 個をブロック(/dev、/proc、/sys、…) |
| プロセスの exec/fork | WASI では利用不可 |
| スレッド処理 | 無効(wasm_threads=False) |
同じルールは言語機能にも適用されます。Cell が提供する WASI サーフェスで必要としない WebAssembly 提案はすべて、エンジン設定で無効にします(スレッド、function-references、例外、GC、末尾呼び出し、スタック切り替え。各 security_baseline で証明し、リリースごとにコンパイルプローブでテスト済み)。これは単なる用心ではなく、構造上の措置です。2025/26 年のアドバイザリ記録では、同じパターンが繰り返されています。提案がひそかにデフォルト有効へ切り替わると、サンドボックス間に差異が生じます。Cell はそのサーフェスをゼロに保ち、ホストが保証できないことではなく、ゲストが実行できないことを代償としています(提案の全一覧とアドバイザリごとのトリアージ)。
これらに加えて、I/O 予算(io_cpu_seconds/io_budget_bytes。ゲストの計算だけでなく、ホスト側の処理にも上限を設けます)、デュアル ABI、オプトインの memory64、宣言された GC ヒープ上限、上限付きの名前付き状態、ホストを介した送信制御があります。どの実行パスでどの制御が動作するか、またカーネルによる境界が自分自身のプロセスになる場合に「文書化された信頼済み」が何を意味するかについては、SECURITY.md の制御ごとの実行パスマトリックスを参照してください。
サンドボックスを取り巻く信頼の連鎖
サンドボックスの周囲には、サードパーティ製ツールのための検証可能な信頼の連鎖があります。
検証に失敗したものは、命令を一つも実行する前に拒否されます。実行は、うまくいくことを前提とした経路に依存しません。サードパーティ製ツールは Ed25519 署名付きマニフェスト(RFC 8785 JCS)を同梱します。サーバーは登録前に署名とモジュールハッシュを検証し、署名付きツールモード(--require-signed-tools pub.pem)では、有効なマニフェストのない .wasm ファイルは読み込まれません。エージェントにできるのは、ツールを提案することだけです。つまり、オペレーターが許可リストに登録したディレクトリ内の tool.request.json を使って提案し、インストールして告知する前に検証されます。提案するのはエージェントであり、処理を決めるのはホストです(ADR-006)。
実行ごとに、ステータス、燃料、タイミング、証明済みのセキュリティベースラインを含む、改ざんを検知できる記録が作成されます。各実行の実行前記録とレシートは、署名付きハッシュチェーン形式の LedgerEntry JSONL チェーン(sequence + prev_hash)に封印できます。これは連続性と順序を保ち、鍵なしでもリンクを検証できますが、作成者の検証には鍵が必要です。また、末尾が切り詰められたチェーンは検知できない点も明記され、テストされています(ADR-011、ephemora-cell ledger <path>)。累積テナント予算(--tenant、--tenant-book、--tenant-max-runs)では、実行前に上限を確保し、消費分を精算します。上限を超える次の実行は、アカウント名を記したレシートとともに拒否されます。これは課金用の識別情報であり、隔離境界ではありません。また、実行中に停止することもありません(ADR-012)。
設計上ステートレス
実行状態は次の実行に引き継がれません。 サンドボックスディレクトリも、エンジンのキャッシュ状態も、ケイパビリティも、環境も引き継がれません。実行の境界を越えられるのは、ホストが意図的に自身で保持する名前付き状態だけです。これはこのセクションの最後で説明します。この主張は、tests/test_execution_invariants.py にある、各語に対して1つずつの名前付きテストで検証されています。実行後に再利用できるものが残らないこと(cleanup() は残留物を返すため、ディレクトリが残っていればアサーション失敗です)、実行 B が実行 A の残したものを何も読み取らないこと、付与されていない権限を持ち越す操作がなく、実行が受け取った preopen を正確に証明すること、そしてレシートが呼び出し元に表示された正確なバイト列に対して検証され、外部キーと編集されたフィールドの両方が拒否されることを確認します。
主な測定結果:エンジンプール、実行ごとのエンジン、分離サブプロセスの各経路で、1 000 / 300 / 40 組の連続実行ペアを実施し、各経路で漏洩 0 件でした。さらに、追記中にライターが SIGKILL された監査を40件実施しました(benchmarks/statelessness_probe.py、結果は benchmarks/results/2026-10-05/ にあります)。このプローブが網羅するのはこれら3つの経路です。MCP stdio 経路は今回の実行には含まれておらず、この結果はその経路について何も示していません。サーバー経路全体でのステートレス性の測定は、別途実施予定の未公開ベンチマークです。既定の I/O 予算では実行ごとのエンジンが使われるため、プール経路もテストするために予算を引き上げています。そうしなければ、誤った経路をテストするステートレス性テストになってしまいます。
名前付き状態は別物であり、ホストが保持します。 Cell にはセッションストアが同梱されておらず、ユーザーに代わって作成することもありません。インテグレーターは、上限を設定した StateStore(StateStore(max_entries=64, max_value_bytes=262144, max_total_bytes=1048576))を実行に渡せます。このストアは実行状態ではありません。何も継承されず、ディスクにも何も書き込まれません。しかし、これはホストが保持するオブジェクトであるため、ホストが同じストアを次の実行に意図的に渡せば、設計どおりに名前付き状態が実行をまたいで引き継がれます。tests/test_state.py::TestStateImports::test_gate_demo_counter_across_three_runs では、まさにその方法で、分離された3回の実行にカウンターを渡しています。ここでの永続化は、ホストが付与するケイパビリティであり、既定ではありません。また、これはストレージでもありません
(ADR-004)。
この仕組みを基盤として構築できるものは、明示的な制限下での LLM 生成コード、制約された環境での MCP ツール、ホストレベルのアクセス権を持たないユーザーアップロード型プラグイン、エージェントのツールランタイム、採点や監査のための検証可能な実行記録などです。これらすべてで同じ run_wasm / run_isolated / MCP API を利用できます。サーバーレス、エアギャップ環境での検証、WASI 0.2 コンポーネント、FastAPI など、動作するコードを含むパターンは docs/recipes.md にあります。
MCP 連携
公式 MCP Registry に io.github.MichaelS1011/ephemora-cell-mcp(PyPI 経由の stdio)として登録されています。レジストリで公開されている最新エントリーは 1.0.4.3 です。1.1.0 のメタデータは server.json で準備され、検証済みですが、公開には引き続き発行者の認証が必要です(レジストリへのログインは対話型のデバイスフローです)。Glama も同じサーバーをインデックスしています。グレードはリアルタイムで分類されるため、ここに記載した文ではなく、上のバッジを確認してください。
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"}'
エージェントに現在時刻を尋ねてください。回答は同梱の clock ツールから取得されます。このツールは WASI のリアルタイムクロックだけを読み取る WASM モジュールで、呼び出しレポートには回答にかかったコストが正確に表示されます。
Ephemora-cell、MCP サーバー、およびすべてのツール実行は、完全にお使いのマシン上で動作します。選択したクライアントやモデルはローカルでもリモートでもかまいません。Cell はそのどちらにも含まれません。 サーバーは PyPI からインストールする通常の stdio プロセスです。Cell に API キーやクラウドアカウントは不要で、ツールは WASM サンドボックス内でオフライン実行されます(ホスト側で明示的に許可しない限り、ネットワーク接続はありません)。Claude Desktop、VS Code/Copilot、Codex、LM Studio、またはローカルモデルスタックを接続できます。サンドボックス側の処理がハードウェアの外に出ることはありません。選択したクライアントやモデルプロバイダーの要件は Cell とは無関係です。また、エージェントがツールをどの程度活用できるかは、そのクライアントのツール呼び出し能力によって異なります。サンドボックスが追加で必要とするのは、ローカルマシンだけです。
呼び出しごとに得られるもの:
- 信頼できないツールをローカルで実行。 すべてのツールは Cell サンドボックス内の WASM モジュールです。環境から継承されるネットワーク接続はなく、燃料とメモリに上限があり、出力も制限されます。ツールが誤動作しても、ホストではなくサンドボックスの壁に阻まれます。
- インストールできるだけでなく、検証可能。 各結果には実行記録(
_meta.execution)が含まれます。ネイティブのget-policyツールは、ポリシーを強制するものと同じコードパスで算出した、ツールごとの正確なポリシーを報告するため、レポートと強制内容に食い違いは生じません。プロトコルでは_metaを検証しないため、--receipt-signing-keyを指定すると、同じバイト列に対する DSSE 署名(_meta.attestation)が追加されます。この署名は、運用者の公開鍵を使って帯域外で検証できます。また、max_age_secondsを設定すると、呼び出し元は古いレシートを拒否できます。ポリシーの読み取りはツールで行い、ポリシーの書き込みはホスト側で判断します。エージェントが自分自身にネットワークやファイルシステムへのアクセスを許可することはできません。 - 長時間稼働するサーバー、新しい実行環境。
2026-07-28のステートレスリビジョンでは、現行リビジョンのクライアントはinitializeハンドシェイクを省略します。一方、ハンドシェイク方式のクライアント(Claude Desktop、VS Code、Codex、…)も変更なしで引き続き動作します。両方式は1つのプロセスで提供され、CI では公式 SDK を使ってテストされています。この分離の要点は、MCP サーバーは長時間稼働していても、その内部の各実行環境は毎回新しくできることです。各tools/callは、新たなサンドボックスを起動し、そこには何も引き継がれません。リビジョンの処理、順序に関するルール(initializeより前のレガシートラフィックは、WASM の実行前に-32600で拒否されます)、ttlMs/cacheScope、および免除ルールについては、docs/mcp.md を参照してください。
各 MCP 経路の呼び出しあたりのコストについては、パフォーマンスを参照してください。Microsoft Wassette との比較: Wassette は、同じ Wasmtime 系の MCP ツール向けに Microsoft が提供する、機能ベースのランタイムです。OCI プルモデルでは、信頼性の判断がインストール時に行われます。Cell は、呼び出し元が呼び出しごとに検証できる情報を追加します(docs/comparison-mcp-servers.md、2026-09-18 に再検証済み)。
これは実行境界であり、ゲストソフトウェアが信頼できるという主張ではありません。Cell はモジュールが悪意あるものか、正しく動作するかを評価しません。ゲストは与えられた予算の範囲内で、依然として誤動作する可能性があります。
セキュリティのエビデンス
測定済みの6段階を強い順に示し、それぞれに再現コマンドとコミット済みの生データを添えています。段階の一覧表、プローブ同等性の方法論、攻撃結果のマトリックス、CVE 再現の詳細については、docs/security_posture.md をご覧ください。
- MCP CVE の再現 — 修正済みの2件の CVE における実際のエクスプロイト経路をエンジンレベルで拒否し、改ざんされたペイロードに対する管理下のロードはフェイルクローズし、WASI 0.2 コンポーネントで測定済みの呼び出し時のソケット拒否も確認しています。
- SandboxEscapeBench-18 のマッピング — 英国 AI Safety Institute による18種類のコンテナー/Kubernetes エスケープシナリオを、最も近い WASM 相当のものに対応付けています。WASI のサーフェスでは、8件は実行テストで拒否、10件は表現不可能です。適用可能性を明示しており、範囲を誇張していません。これらのエスケープが依存するプリミティブ(特権モード、名前空間、cgroups、生ソケット)はここには存在せず、モデルも関与していません。
- 8つの攻撃意図 × 3つの境界 — 同じ意図、同じ終了コードの規則で、ハードコードは一切ありません。標準の Docker は0/8をブロック、強化された Docker は2/8、Cell は8/8(デフォルト設定、WASI Preview1 パス)です。以下にリンクした日付入りのベンチマーク成果物で、macOS arm64 と DGX Spark GB10 上で再現しています。2026-09-18(macOS arm64)および2026-09-20(DGX Spark GB10/Linux arm64)のパスはdocs/security_posture.mdに記載されています。ここでの
ALLOWEDは、テスト対象のプリミティブをそのサンドボックス内のゲストコードで引き続き利用できることを意味します。ホストに到達したことを意味するものでも、各境界の優劣を示すものでもありません。 gVisor が8/8の ALLOWED と測定されるのも、まさにこの理由によります。ホストを隔離しつつ、ゲストには Linux ABI を維持します。WASI 0.2 コンポーネントのパスは別の境界であり、現時点では同期ブロック機能を備えていません。これは推論ではなく、測定結果です(SECURITY.md)。 - 公式 WASI およびコア仕様への適合性 — ピン留めされた wasi-testsuite preview-1 スイートでは72件合格/設計上の xfail 1件を文書化/失敗0件、公式 WebAssembly コア仕様では31,931件合格です。すべての逸脱を分類し、予期しないものはありません。CI で毎週再実行し、生の JSON をコミットしています。これは標準仕様への適合性であり、セキュリティ認証ではありません。Cell は第三者による認証を受けていません(conformance/README.md)。
- 2026年のプローブクラス — 2026年のファイルシステムエスケープベクトル(GHSA-vqjp の末尾スラッシュ/ハードリンク/リネームのパターン、および GHSA-2r75/CVE-2026-47261 の TRUNCATE バイパス)、永続化ワームとコントロールプレーンのプローブはすべて拒否され、各クラスで許可されるポジティブコントロールも確認しています。
- ステートレス性のプローブとアーキテクチャ間の決定性 — 設計上のステートレス性に記載の実行ペアの全数検査と、プラットフォームごとに決定的な燃料(ばらつき0)を確認しています。結果はプラットフォームに依存し、ホスト間で比較することはできません。
比較しないもの — その理由。 プロンプトインジェクションのスイート(garak、InjecAgent)は、実行境界ではなくモデルとエージェントのレイヤーをテストするため、実行サンドボックスの対象外です。クラウドサンドボックスプロバイダーについては、出典の状態とともに第三者ソースから引用しており、第三者の数値が測定済みの自社セルと同じ表に掲載されることはありません。
Cell を突破できますか? 文書化されたセキュリティ境界に違反する実行経路(エスケープ、予算のバイパス、アテステーションの欠落など)を見つけましたか? まさにそのような報告をお待ちしています。SECURITY.mdをご覧ください(非公開での開示と責任ある対応)。脅威モデルと文書化された残余リスクを参考に、調査対象を絞ってください。docs/security_posture.mdの方法論のセクションでは、測定方法を説明しています。Cell に関するセキュリティ研究を歓迎します。
ご自身で評価する
上記の主張は、新たにクローンした環境で反証できるように設計されています。内部へのアクセスも、秘密鍵も、非公開のドキュメントも必要ありません。使い捨て環境で実行してください(最後のブロックの前にある安全上の注意をご覧ください)。
git clone https://github.com/MichaelS1011/ephemora-cell.git && cd ephemora-cell
git checkout <full-commit-sha> # pin the commit under evaluation; record `git rev-parse HEAD`
python -m pip install -e . # source, not the published wheel — the gate lives only here
python -m pip install --require-hashes -r requirements-dev.lock # test tooling: the line above does not install pytest
python -c "from ephemora_cell.execution_report import TRUST_UNKNOWN" # ImportError ⇒ you are holding the wheel, not this source
python benchmarks/verify_8_vectors.py # expect exit 0, "8/8 attack vectors blocked", positive controls included
python -m pytest tests/test_isolation_gate.py tests/test_fs_escape_matrix.py tests/test_grant_trust.py # the enforced-boundary negative tests
python -m pytest # full suite — current count under "Testing & Verification"
パッケージインデックスからではなく、固定したコミットのソースからインストールしてください。pip install ephemora-cell は公開済みのリリースを取得しますが、そのリリースは分離ゲートより前のものなので、ゲートを含まず、その存在を否定することもできません。確認結果から対象のビルドを特定できるよう、コミット SHA と wheel/sdist のダイジェストを記録してください。
次に、検証用のゲスト環境をご自身で用意してください。単一の一時ディレクトリだけを許可し、その外にあるものへアクセスできないか試します。たとえば、.. によるトラバーサル、外部を指すシンボリックリンク、ホストの絶対パス、/proc 形式の読み取りなどです(tests/test_fs_escape_matrix.py に記述されているものと同じテストマトリクスです)。各試行は errno による拒否、または正常な拒否で終了し、許可された範囲外のホストパスには決して到達しないはずです。逸脱があれば、ドキュメントですでに明記されているギャップでない限り、発見事項となります。
文書化されたギャップを新たな不具合と誤認しないよう、まず境界を確認してください。脅威モデル、docs/security_posture.md にある6段階と再現コマンド、そして SECURITY.md に記載された既知の制限です。これには、WASI 0.2 のコンポーネント経路では現在、同期を遮断する仕組みがないこと(実測済み)、および2026年のアドバイザリの波に対する上流の Wasmtime の修正が、まだ PyPI に反映されていないことも含まれます。破壊的な検証(既知のホストクラッシュ用サンプル、深いファジング、カーネル脱出の試行)は、この自己検証の対象外です。実稼働中のマシンではなく、専用の隔離ラボで行ってください。
パフォーマンス
境界のコストは? 0.376 ms — サンドボックスで実行した場合に、同じ処理をそのまま実行した場合と比べて加わる、ウォーム時の実測壁時計オーバーヘッドです(推定値ではありません)。
最新の再現可能なベンチマーク — 2026-09-14 · Mac M5 · wasmtime 47.0.1 · hello.wasm · n=1000。以下のライブラリの数値はすべて、新しいクローンから再生成できます。MCP stdio の行は2026-10-06に取り下げました。リポジトリ内に、結果を再現できるコミット済みのベンチマークハーネスも生の結果アーティファクトもないため、ここには掲載していません。ハーネスが用意され次第、再掲載します。
| パス | 呼び出しあたり | この数値の理由 |
|---|---|---|
ライブラリ、プール済みエンジン(io_budget_bytes=None) | 0.51 ms 中央値(p95 0.89) | キャッシュ済みエンジン、信頼されたワークロード |
| ライブラリ、デフォルトの実行ごとのエンジン(64 MiB I/O バジェット) | 中央値 0.94 ms(p95 1.15) | I/O の上限を維持するため、実行ごとに新しいエンジンを使用 |
ライブラリ、run_isolated() | 約10~100 ms | 破棄可能なワーカープロセス、OS の rlimit、強制終了 |
コールド時とウォーム時(各 n=300、初回の実行は破棄):コールド時はゲスト 0.59 ms/壁時計 0.99 ms、ウォーム時はゲスト 0.55 ms/壁時計 0.93 ms — このウォーム時の差が0.376 msです(overhead_warm_ms、benchmarks/results/2026-09-14/pov_benchmark.json)。同じマシンでのコンテナーのコールドスタートとの比較(イメージごとに n=100):docker run の python:3.12-slim は185.9 ms、Cell は0.49 msで、383倍です。これはこのワークロードにおける、コンテナーのコールドスタートと、呼び出された WASM の比較であり、WASM が Docker より高速だという一般的な主張ではありません。このホストでのスループットは、ワンライナーパスでコアあたり約300万回/時、プール済みのホットループで約550万回/時です。過去の CoreMark 測定値はバージョンに依存します。docs/performance.mdを参照してください。
全マトリックス、実行ごとのスコア、エージェント型ワークロード、サードパーティとの位置づけについては、docs/performance.mdを参照してください。再現するには、python benchmarks/pool_vs_budget.py · python benchmarks/competitive_benchmark.py · python benchmarks/coremark_wasi.py --rounds 3 · python benchmarks/determinism_probe.pyを実行します(measured:trueの生の結果はbenchmarks/results/にコミットされています)。
リリースごとに変わらない注意点が2つあります。fuel はプラットフォームごとに異なります — ホストごとに決定的ですが(測定したすべてのマシンでfuel_spread: 0)、ホスト間で比較することはできません。また、ここに示す数値はすべて Cranelift のものです — Python バインディングではインタープリター型バックエンドを選択できないため(Pulley/Winch には到達できないことをtests/test_surface_audit.pyで検証)、フォールバックによって実行特性が知らないうちに変わることはありません。
API、CLI、インテグレーション
Cell は .wasm を実行します。ソース言語は認識しません。強制適用スタック(モジュール → エンジン → ケイパビリティサーフェス → 予算 → 記録)は、docs/security_posture.md に図示されています。主要な API は意図的にシンプルに設計されています。そのため、単にコードを実行するだけでなく、監査、ポリシーの強制適用、リソースの計測にも適しています。
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))
run_isolated() は同じ設定を受け取り、レポートの各フィールドを辞書として返します。ディスククォータ(disk_quota_bytes)と GC ヒープ上限(max_gc_heap_mb)は WASIConfig の設定項目です。名前付き状態はホストから提供される StateStore で、実行時に渡すものであり、設定フラグではありません。コンポーネントのパスは run_wasm(..., abi="component") で呼び出しごとに選択します。レシピについては docs/recipes.md をご覧ください。
CLI — 5 つの動詞で一連の処理をカバーします。同じコマンドを開発サイクル(編集、実行、レシートの確認)にも使用でき、Dockerfile もイメージのビルドも必要ありません。
ephemora-cell run Execute a WASM module (--json, --isolated, --fuel, --stdin, --profile, --abi, --tenant)
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 ledger Verify a run chain: linkage and order, and what it cannot prove
全リファレンスについては ephemora-cell --help と docs/recipes.md をご覧ください。
言語。 WASM にコンパイルできる言語であれば実行できます。5 つの tier-1 ツールチェーン(Rust、Go、C、AssemblyScript、Zig)は、プッシュごとに CI ゲートでビルドと実行の両方が行われます。Python の実行は、持ち込みのゲストとして計測されています。--profile interpreter の下で固定された wasi-python 3.10 を使い、ワークロードごとにプロセス内で 25 回、分離環境で 15 回起動し、すべての実行が success となっています。ただし、22 MB のゲストバイナリがコミットされていないため、CI ゲートではありません。実行できないもの:ネイティブ Python、Node.js/npm パッケージ、Linux/ELF バイナリ。GC/スレッドベースの移植版は、GC ヒープゲートが開くまでロックされています。コンパイルコマンド、ゲート、計測済みインタープリターの数値については docs/languages.md をご覧ください。方針については ADR-009 をご覧ください。プロファイル(plugin、llm、edge、default、analytical、interpreter)は予算のプリセットです。interpreter は持ち込みのインタープリターをゲストとして実行するためのプリセットであり、インタープリターは同梱されず、同期の例外も許可されず、ファイルシステムや環境へのアクセスも付与されません。
GitHub Action
CI で信頼できない PR コードを扱う場合に備え、リポジトリには Cell サンドボックス内でモジュールを実行して評価結果を返すコンポジットアクションが含まれています。分離サブプロセス経路はデフォルトで有効です。
- id: run-tool
uses: MichaelS1011/ephemora-cell/[email protected] # pin a release tag, not a branch
with:
module: path/to/module.wasm # e.g. built from a PR-provided recipe
profile: llm
fuel: 500000
- run: echo "status=${{ steps.run-tool.outputs.status }} fuel=${{ steps.run-tool.outputs.fuel_consumed }}"
成功以外のステータスではステップが失敗します(fail-on: non-success、デフォルト)。予算を使い切ったりメモリ上限に達したりしたモジュールによって、ワークフローが巻き添えになることはありません。入力、出力、失敗時の動作、およびこのリポジトリ独自のデモ用ワークフローがプッシュごとに両方のケースを実証する方法(無害なモジュールは成功し、fuel: 100 の examples/fuel_bomb.wasm は fuel_exhausted かつ fuel_consumed == 100 で失敗する)については、action/README.md をご覧ください。
CI では、フレームワークに関連する 2 つのインテグレーションテストスイート(integration/test_hermes_subagent.py と integration/test_nemoclaw_isolation.py)を実行します。どちらもシミュレーションです。リポジトリ独自のワークロードモジュールを、Hermes 風および NemoClaw 風の呼び出しパターンの下で Cell に実行させます。サードパーティのフレームワークをインストールもインポートもしないため、その形式のトラフィックにおける分離境界をテストするものであり、SDK との互換性を証明するものではありません。integration/ にあるその他のスクリプト(LangGraph、CrewAI、AutoGen、OpenAI Agents SDK、Semantic Kernel)は、それぞれの SDK のインストールが必要なサンプルであり、CI ゲートの対象ではありません。この点について、ここではそれ以外の主張はしていません。
制限事項
**Cell とは:**信頼できないコードのための最小限の実行境界です。明示的な機能と予算を備えた WASM/WASI サンドボックス、リソースを計測するランタイム、組み込み可能な Python ライブラリ、CLI、MCP 実行レイヤーです。
**Cell ではないもの:**永続的なワークスペース · VM · コンテナオーケストレーターまたは汎用コンテナの代替品 · マルウェア検出ツール · マルチテナントのクラウドプラットフォーム · エージェントフレームワーク · LLM · コードジェネレーターです。ディスクには何も書き込まず、実行間で何も引き継ぎません。名前付き状態は、ホストがストアを存続させている間だけ存在します。詳しくは構造上のステートレス性をご覧ください。
コードが信頼できない、または動的に生成される場合 · ツールがサードパーティー製の場合 · AI エージェントが任意のプログラムを実行する場合 · 明示的なリソース予算が必要な場合 · 構造化された実行メタデータが必要な場合に、Cell を使用してください。Cell は上限のある実行に最適化されており、長時間稼働するサービスのワークロード向けではありません。完全な Linux サービスのセマンティクスが必要な場合は、適切なコンテナまたはマイクロ VM 境界を使用してください(実測に基づくサードパーティー比較:docs/performance.md)。
適用される各制御が保証しないこと。各行は誠実な境界を示しており、その境界でテストされています。
| 適用される制御 | 保証すること | 保証しないこと |
|---|---|---|
| メモリ上限(デフォルト 128 MB) | ゲストが設定されたヒープを超過できないこと | ゲストの動作が正しいこと。予算内で発生したバグはゲスト側のバグです |
| Fuel 予算 | CPU を無制限に消費しないこと。上限に達すると実行が停止します | マルウェア検出。予算内に収まる悪意あるコードは問題なく実行されます。モジュールの意味を調べることはありません |
| 実時間タイムアウト | 実行が暴走しないこと。エポック割り込みが発動します | アプリのロジックが正しいこと、または高速であること |
| ネットワーク拒否(デフォルト設定) | デフォルトではゲストの接続が成功しないこと。Preview1 はソケット API を公開せず、WASI 0.2 の経路では呼び出し時に connect を拒否します | 許可された機能の範囲内で安全に動作すること。許可されたチャネルを介した情報流出(例:許可された事前マウント領域へのシークレットの書き込み)は、インテグレーターの責任です(SECURITY.md) |
| ファイルシステム機能の制御(事前マウントのみ、デフォルトで拒否) | ファイルアクセスを明示的にマウントされたディレクトリに限定すること | 完全な VM のセマンティクス。マウントされたパスの内容は、インテグレーターが公開すると選択したものそのものです |
| 出力上限(デフォルト 10 KB) | キャプチャされる出力に上限があること。無制限の出力によってホストのディスクがいっぱいにならないこと | 切り詰められた出力が完全であること。result.stdout とレコードを確認してください |
目標は明確です。信頼できないコードの実行を十分に安価かつ制御可能にし、アプリケーションがデフォルトで安全に実行できるようにします。
詳細:SECURITY.md(ポリシー、既知の制限) · docs/threat-model.md(攻撃者モデル、信頼境界、リソース枯渇マトリックス) · docs/security_posture.md(証拠の段階、攻撃対象領域の検証、関連研究)。
ロードマップ — 安定したテーマを示しており、日付は約束しません。ゲート付きの詳細はSECURITY.mdおよびdocs/observations.mdに記載されています。新しい Wasmtime 系統の適格性評価、およびそれに対する Fuel の決定性と FS エスケープのゲートの再実行 · WASI 0.3。その機能が Python ホイールで提供され、独自の予算適格性評価が完了するまでゲートで保留 · 共有メモリ型スレッド。スレッド対応の Fuel および実時間の計測を備えた、セキュリティレビュー済みの個別オプトイン機能として提供(docs/threads_roadmap.md) · 現在予定されているファズテストに加えた継続的なファジング。パーサー/検証器の対象領域と上記の不変条件を対象とします。
テストと検証
main の現在のゲート(v1.1.0 後の強化後)、このコミットを新規クローンして測定 — ホストごとに固定された値ではありません:テスト1084件が成功(4件スキップ) · ステートメントカバレッジ90%(このコミットで測定した4098/4548、ゲートは80%) · 攻撃ベクトル8/8をブロック(デフォルトのセキュリティ態勢、WASI Preview1 パス) · 公式 wasi-testsuite 適合性テスト72件が成功(バージョン固定、失敗0件) · プッシュごとに CI で強制(テスト、カバレッジ、pip-audit、SBOM、bandit、公式 MCP SDK との相互運用性テスト) — さらに、同じクローンで、インストール済みアーティファクトを対象とした wheel のみのスモークテスト(v1.1.0 GitHub リリースに記録)と、sdist のクリーンルームコンテナ実行を実施しています。
ここでいう「テストスイート」の意味 — 基準となる数値は1つです。 1084/4(収集数1088)は、CI が両方のレッグで使用する環境で pytest が報告する値です。環境には requirements.txt(バージョン固定された wasmtime)、テスト用依存関係、そして Ed25519 を使うすべてのパスで必要となるオプションの tools-signing エクストラ(cryptography>=42)が含まれます。この件数は scripts/check_test_count.py によって pytest --collect-only の結果と照合されるため、リリースの件数に関する記述がコードと食い違うことはありません。関連する数値 — cryptography なしの最小インストール時の件数、sdist コンテナの範囲、ツールチェーンのスキップ件数の非対称性、ホスト負荷が io_cpu_seconds ウォッチドッグに与える影響 — は、それぞれ異なるインストール状態を示しています。これらの条件は docs/release_assurance.md に記載されており、ガードによる自動測定ではなく、各リリース時に手動で再測定しています。
ドキュメント
セキュリティとエビデンス · SECURITY.md — ポリシー、実行パスマトリクス、脆弱性の報告 · docs/threat-model.md — 信頼境界、敵対者モデル、リソース枯渇マトリクス · docs/security_posture.md — エビデンスの段階、結果表、CVE 再現の詳細 · conformance/README.md — 公式 wasi-testsuite とコア仕様の結果 · docs/release_assurance.md — インストール状態ごとの測定件数 · docs/security_review_2026-10-05.md — 6つのレッドチーム調査で判明したこと、効果的なテストで解決したこと、その後オペレーターが下した3つのセキュリティ態勢に関する判断(許可範囲、許可されていないツール、ハンドシェイクの順序)、同日のコードを監査した2回目の調査、そして未解決項目とその理由
はじめに · クイックスタート · docs/recipes.md — 使用パターン(FastAPI、サーバーレス、エアギャップ環境、WASI 0.2)とトラブルシューティング · integration/ — エージェントフレームワークの例
パフォーマンス · docs/performance.md — ベンチマークとパスごとのレイテンシ(CoreMark 測定のバージョン範囲を含む) · benchmarks/results/ — measured:true の生 JSON
統合と言語 · docs/mcp.md — MCP サーバー · docs/comparison-mcp-servers.md — CVE とプローブの対応表 · action/README.md — 複合 GitHub Action · docs/languages.md — コンパイルマトリクスとインタープリターゲスト · docs/egress_patterns.md — 承認された API 呼び出しパターン · docs/observations.md — 意図的に対応を見送っている監視項目と、それぞれの終了条件
判断と変更 · ADR-001…015 — 実行中のワークロードのセキュリティ境界を誰が変更できるかを扱う ADR-006 を含む、すべての意思決定記録 · examples/signed_record_demo.py — 実行への署名と改ざんチェック · CHANGELOG.md
エンタープライズ · docs/enterprise.md — 分離と運用について、その議論をする価値がある場合
ライセンス
Ephemora-cell は Business Source License 1.1(BUSL-1.1)のもとでライセンスされています。ソースコードは公開されていますが、オープンソースではありません。
- 本番以外の用途は無料です — 評価、開発、研究、テスト。
- 適用される変更日の前にビジネス用途または本番用途で使用するには、ライセンサーである Michael Soppa からライセンスを取得する必要があります — docs/enterprise.md をご覧ください。
- 自動移行: 各バージョンは、最初に一般公開された配布から4年後に Apache 2.0 に移行します。
- バージョンごとのライセンス履歴: 1.0.4.3 以下のバージョンは Apache-2.0 です。バージョン 1.0.5 以降は BUSL-1.1 です(ADR-010 に、各バージョンの初回公開配布日と変更日が記載されています)。
- 保証なし: ライセンス対象の著作物は「現状有姿」で提供され、すべての保証および条件は、LICENSE の規定に従って免責されます。
- サードパーティの素材は、ここではライセンスを再許諾していません。別のライセンスのもとで同梱または参照されるものは、THIRD_PARTY_NOTICES.md に記載されています。
Ephemora-cell は、Ephemora に依存しない独立した実行境界です。Ephemora のエンタープライズ版は、本番環境および規制対象の環境へのデプロイに向けて、この境界を基盤としています。Cell は分離機能を完備し、エンタープライズ版は運用機能を完備しています。
mcp-name: io.github.MichaelS1011/ephemora-cell-mcp
1つのエージェントアクション。1つの境界付き実行。1つの制御された結果。
Michael Soppa が作成しました。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。