EMILIA Protocol MCP Server

公式

名前付きの人間によるオフライン検証可能な承認を、AIエージェントが不可逆的なアクション（支払いリリース、記録変更、デプロイ）を実行する前に要求します。二人体制、Ed25519トラストレシート、IETF草案、Apache-2.0。

GitHub
2

ドキュメント

EMILIA プロトコル

CI Verify Sample Receipt npm License IETF Internet-Draft Discord

ブレーキのないエンジン

50年にわたり、ソフトウェアセキュリティは一つの問いに答えてきた：誰が入ることを許されるのか？ ファイアウォール、OAuth、パスワード——すべては入口で人間の身元を確認するために構築された。

その時代は終わりつつある。ソフトウェアの主要なユーザーはもはや人間ではなく、自律型AIエージェントだ。エージェントは単にログインするだけでなく、コードを書き、ツールを呼び出し、その場で現実を変える。CISOなら誰でも、たった一つの悪質なプロンプトでエージェントが本番データベースを消去したり、誤った口座に送金したりし得ることを知っている。だから彼らはデプロイをブロックしている——コンプライアンスチームが一つの問いに答えられないために、使えない数十億ドルのAI予算を抱えているのだ：

誰がそのアクションを承認したのか？

私たちの世代の危機は認証ではない。それはアクションの瞬間における認可だ：エージェントがまさに実行しようとしていることが、指名された人間が承認したことそのものであると、実行前にどう証明するのか？

EMILIAはエージェント時代のシートベルトだ。

決定ログは証言である。EMILIAは領収書を生成する。

領収書なし、不可逆的なアクションなし

エージェントが送金、コード削除、本番デプロイ、権限変更、規制対象状態の変更を 有効なEMILIA領収書なしに試みた場合、ツールは実行を拒否する——そしてもし実行されたなら、 誰でも、誰が何を承認したかをオフラインで検証でき、誰も信頼する必要はない。

これがプロトコルの全体像だ。開発者向けの楔は、不可逆的なMCPツールを包む一つのラッパーである。 冷たく、完全にオフラインで、キーもアカウントもなしに見てほしい——各デモは全ループを実行する（拒否 → 指名された人間が正確なアクションに署名 → ツールが実行 → 偽造された領収書は拒否）：

node examples/mcp/payment-server.mjs    # release_payment  — refuses without a receipt
node examples/mcp/github-admin.mjs      # delete_repo      — refuses without a receipt
node examples/mcp/prod-deploy.mjs       # deploy_production — refuses without a receipt

本番環境で独自のツールディスパッチャーをラップする——examples/mcp/ と /mcp を参照：

import { withMcpGuard } from '@emilia-protocol/mcp-guard';
const guarded = withMcpGuard(handleTool, {
  annotations: { release_payment: { irreversible: true, action: 'payment.release' } },
}); // missing receipt → refused, never a silent pass

30秒で試す

# Issue a receipt offline — no API key, no backend needed
npx @emilia-protocol/issue demo

# Add EMILIA to Claude / Cursor / Cline
npx -y @emilia-protocol/mcp-server

実際のFace ID承認を試す → 自分のパスキーで82,000ドルの送金を承認する。VERIFIEDがどのように見えるか確認する。領収書を偽造する。失敗するのを見る。

ブラウザで任意の領収書を検証する —— 貼り付けるだけで、何もアップロードされない。

仕組み——4つの幕

EMILIA crash test — an autonomous agent tries to wire $82,000; the policy engine holds it, a named human signs off on their own device, the receipt verifies offline, and a forged copy fails.

自分で実行する： node examples/crash-test.mjs —— 完全オフライン、APIキー不要。

  [ INTENT ]          [ DECISION ]           [ CEREMONY ]           [ RECEIPT ]
  Agent calls a     Policy-bound, hash-    Named human signs     Signed, offline-
  tool via MCP   →  pinned: allow /     →  the EXACT action  →  verifiable proof.
                    allow-with-signoff /   on their own          Tamper it:
                    deny  (+observe        device (passkey).      fails by design.
                    mode: zero change      What they saw =
                    to production)         what they signed.

第1幕 — インターセプション（MCPネイティブ）。 書き換えなし。EMILIAはModel Context Protocol境界でツール呼び出しをフックする——エージェントがファイルを削除しようとしたり、資本を移動させようとした瞬間、アクションは空中で捕捉される。

第2幕 — 決定（ポリシーバインド、決定論的）。 アクションはハッシュ固定されたポリシーに対してチェックされる： allow、allow-with-signoff、または deny。さらに、本番環境では何も変更せず、何が保留されただろうかを報告する観測モード。決定論的で監査可能——ブラックボックスのリスクスコアではない。

第3幕 — セレモニー（デバイスバインドの人間の承認）。 ポリシーが人間を要求する場合、EMILIAは正確なアクションにバインドされたWebAuthn / パスキー承認を実行する——オペレーター自身のデバイスでのFace ID / Touch ID。人間が見たものが、彼らが署名したものである。 スクリプトはこれを偽造できず、自律ループはこれをスキップできない。

第4幕 — 領収書（証拠）。 結果は署名付き認可領収書であり、誰でもオフラインで、オープンソースコードで、バックエンドなしで、ベンダーへの信頼なしに検証できる。改ざんすれば、検証は構造的に失敗する。オプションで公開タイムスタンプのためにアンカーする——コアにはブロックチェーンは不要。

開発者が使う理由

実際に何かを行うエージェントが欲しい——しかし、暴走ループ、APIの過剰支出、偶発的なデータ破壊に麻痺している。EMILIAはプラグアンドプレイのMCPサーバー + 薄いSDKラッパーを提供する。ポリシーハッシュを適用すれば、不可逆的なツール呼び出しは、暗号的に強化され、NIST-AI-RMFにマッピングされた承認と証拠のレイヤーを得る——承認ワークフローや監査インフラをゼロから構築することなく。

# langchain-emilia — wrap any LangChain tool with an EP gate
from langchain_emilia import EmiliaGateClient

gate = EmiliaGateClient(base_url="https://www.emiliaprotocol.ai", api_key="...")
safe_tool = gate.wrap(your_destructive_tool)

pip install langchain-emilia   # PyPI
npm install @emilia-protocol/verify  # npm

エージェントはそのリーシュを振り切れない。

企業が必要とする理由

すべてのプラットフォームシフトは新しいセキュリティプリミティブを生み出す：ウェブはSSLを、クラウドはOkta / IAMを得た。エージェント経済はアクションレベルの信頼を必要とする。企業はコンプライアンスが支出を許さないAI予算を抱えている——EMILIAは、予測不可能なエージェントを監査対応インフラに変え、プリミティブごとにNIST AI RMF、EU AI Act、SOC 2 CC6/7コントロールにマッピングすることで、それらを解き放つ鍵である。

マネージドレイヤー（GovGuard / FinGuard）は、セクター固有のポリシーパック、観測モードパイロット、監査対応証拠パッケージでオープンスタンダードを拡張する——開始に調達は不要。

標準

EMILIAはオープンスタンダードであり、製品の堀ではない。コアはApache-2.0であり、IETFインターネットドラフトとして追跡されている。

IETFインターネットドラフト投稿済み： authorization-receipts · quorum。 standards/ でステージング中： authorization-evidence-chain (EP-AEC, 構成) · evidence-record (EP-EVIDENCE-RECORD, 長期保存)。フィールドマップ： ランドスケープ調査。
クロス言語検証器JavaScript · Python · Go —— 3つすべてが敵対的適合ベクトルで一致することが証明され、毎プッシュ (npm run conformance)。これが真の標準のためのIETF基準：複数の独立した相互運用可能な実装。
形式検証26のTLA+安全性プロパティ（0エラー） · 35のAlloyファクト、22のアサーション —— 両方ともCIで実行
MCPレジストリ公式MCPレジストリ · Glama（グレードA、公式バッジ） · Smithery
ライセンスApache-2.0

3つの独立した実装が一致することが証明されている——CONFORMANCE.md を参照するか、emiliaprotocol.ai/verify で自分で領収書を検証する。

EPスタック

Eye observes. Handshake verifies. Signoff owns. Commit seals.
レイヤー機能
EP Eyeエージェントの振る舞いを観測・分類する（OBSERVE → SHADOW → ENFORCE）
EP Handshake7つのプロパティバインディングを持つ暗号的同意セレモニー
EP Signoff指名された人間の所有権 —— WebAuthn / パスキークラスA、デバイスバインド；最高リスクのアクションのためのマルチパーティクォーラム（M-of-N / 順序付き——二人ルール）
EP Commitマークルチェーン領収書による原子的で不変なアクションクローズ

証明ポイント

メトリック値
自動テスト173ファイルにわたる4,220
TLA+安全性プロパティ26検証済み（T1–T26）、0エラー —— PROOF_STATUS.md 参照
Alloyリレーショナルアサーション2つのモデルにわたる35ファクト + 22アサーション —— CIで検証済み
レッドチームケースカタログ85 —— RED_TEAM_CASES.md
修正されたセキュリティ所見31
適合性 (7/7)node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
クロス言語適合性8スイート —— 領収書 · デバイス承認 · マルチパーティクォーラム · 失効 · 時刻証明 · 信頼領収書 · 来歴 · 証拠記録 —— JS / Python / Go検証器が一致 (node conformance/run.mjs)
ハンドシェイク作成 p9550 VUで575ms —— PERFORMANCE_PROOF.md

EPコアオブジェクト

EPは、任意の適合実装が生成・検証できる3つの相互運用可能なオブジェクトを標準化する：

オブジェクト概要
Trust Receipt認可イベントのポータブルな署名付き記録 —— 何が起こったか
Trust Profile観測可能な信頼状態の標準化された要約 —— 何が知られているか
Trust Decision理由と異議申し立てパスを含むポリシー評価結果 —— 今何をすべきか

EP拡張（Handshake、Signoff、Commit、Delegation）は、システムが実行を制約しなければならない場合に、より強力な執行を追加する。製品レイヤー（GovGuard / FinGuard）はその上に構築される——プロトコル自体ではない。

5つの呼び出しでクイックスタート

  1. ポリシーを作成
  2. ハンドシェイクを開始
  3. 証拠を提示
  4. 検証
  5. 承認して消費

90秒デモ · クイックスタート · エージェントウォークスルー · IETFドラフト · Discord

EPとは何か——そして何でないか

EPはアクションの瞬間における認可であり、アイデンティティシステムでも、ウォレットでも、レピュテーションスコアでもない。

  • であるもの：アクターのアイデンティティ、権限、ポリシー、正確なアクションコンテキストを実行前にバインドするための信頼標準
  • でないもの：OAuth / OIDCの代替（それらはあなたは誰かに答える——EPは誰がこの正確なアクションを承認したかに答える）
  • でないもの：プロプライエタリ製品（コアはApache-2.0でIETF追跡）
  • でないもの：ブロックチェーン（領収書が主役；オプションの公開タイムスタンプは脚注）

CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md 参照