EMILIA Protocol MCP Server

官方

要求指定的人類在AI代理執行不可逆操作（如付款釋放、記錄變更、部署）前，提供可離線驗證的批准。雙人規則、Ed25519信任收據、IETF起草、Apache-2.0。

GitHub
2

文件

EMILIA 協定

CI Verify Sample Receipt npm License IETF Internet-Draft Discord

沒有煞車的引擎

五十年來，軟體安全只回答一個問題：誰被允許進入？ 防火牆、OAuth 和密碼——全都是為了在門口驗證人類身分而建立的。

那個時代正在終結。軟體的主要使用者不再是人類，而是自主的 AI 代理。代理不僅僅是登入——它們會編寫程式碼、呼叫工具，並即時改變現實。每位資安長都知道，一個糟糕的提示就能讓代理清除生產資料庫，或把錢匯到錯誤的帳戶。所以他們正在阻止部署——坐擁數十億的 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 美元的匯款。看看「已驗證」是什麼樣子。偽造收據。看看它如何失敗。

在你的瀏覽器中驗證任何收據 ——貼上即可，不會上傳任何東西。

運作方式——四幕

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.

第一幕——攔截（MCP 原生）。 無需改寫。EMILIA 在模型上下文協定邊界攔截工具呼叫——當代理試圖刪除檔案或轉移資本的那一刻，動作在半空中被攔截。

第二幕——決策（策略約束、確定性）。 動作會根據雜湊鎖定的策略進行檢查：allow、allow-with-signoff 或 deny。再加上一個觀察模式，在生產環境中不做任何改變，只報告哪些動作會被攔截。確定性、可審計——不是黑箱風險評分。

第三幕——儀式（裝置綁定的人類簽核）。 當策略要求人類參與時，EMILIA 會執行一個綁定確切動作的 WebAuthn / 通行密鑰簽核——在操作者自己的裝置上使用 Face ID / Touch ID。人類看到的內容就是他們簽署的內容。 沒有腳本可以偽造它；沒有自主迴圈可以跳過它。

第四幕——收據（證據）。 結果是一份簽署的授權收據，任何人都可以離線、使用開源程式碼、無需後端、無需供應商信任來驗證。篡改它，驗證就會因結構而失敗。可選擇性地將其錨定以進行公開時間戳記——核心不需要區塊鏈。

為什麼開發者使用它

你想要真正做事的代理——但你被失控的迴圈、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、歐盟 AI 法案和 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，長期保留)。領域地圖：landscape survey。
跨語言驗證器JavaScript · Python · Go ——三者皆經證明在對抗性符合性向量上達成一致，每次推送 (npm run conformance)。這就是 IETF 對真正標準的門檻：多個獨立、可互操作的實作。
形式驗證26 項 TLA+ 安全性屬性（0 錯誤）· 35 項 Alloy 事實，22 項斷言——兩者皆在 CI 中執行
MCP 註冊表官方 MCP 註冊表 · Glama（A 級，官方徽章）· Smithery
授權Apache-2.0

三個獨立實作經證明達成一致——參見 CONFORMANCE.md，或自行在 emiliaprotocol.ai/verify 驗證收據。

EP 堆疊

Eye observes. Handshake verifies. Signoff owns. Commit seals.
層級功能
EP Eye觀察並分類代理行為（OBSERVE → SHADOW → ENFORCE）
EP Handshake具備 7 項屬性綁定的加密同意儀式
EP Signoff具名的人類所有權——WebAuthn / 通行密鑰 A 級，裝置綁定；多方法定人數（M-of-N / 有序——雙人規則）用於最高風險的動作
EP Commit原子性、不可變的動作關閉，附帶 Merkle 鏈結收據

證明要點

指標數值
自動化測試跨 173 個檔案的 4,220 項
TLA+ 安全性屬性26 項已驗證（T1–T26），0 錯誤——參見 PROOF_STATUS.md
Alloy 關聯斷言跨兩個模型的 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)
Handshake 建立 p95在 50 VU 下為 575 毫秒——PERFORMANCE_PROOF.md

EP 核心物件

EP 標準化了三個可互操作的物件，任何符合規範的實作都能產生和驗證：

物件說明
信任收據一個可攜式、已簽署的授權事件記錄——發生了什麼事
信任設定檔一個可觀察信任狀態的標準化摘要——已知什麼
信任決策一個經策略評估的結果，附帶理由和申訴路徑——現在該做什麼

EP 擴展（Handshake、Signoff、Commit、Delegation）在系統必須約束執行的情況下，增加了更強制的執行力。產品層（GovGuard / FinGuard）建構於其上——而非協定本身。

五個呼叫快速入門

  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