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 美元的汇款。看看 VERIFIED 是什么样子。伪造收据。看看它如何失败。

在浏览器中验证任何收据——粘贴进去，不会上传任何内容。

工作原理——四幕

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、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, 长期保留)。领域地图：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原子、不可变操作关闭，带有默克尔链收据

证明点

指标值
自动化测试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)
握手创建 p9550 VUs 下 575ms——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