Emilia Protocol

EMILIA Protocol

---

让你的 Agent 准备付款，控制它可以放行什么。

Agent 准备了一笔 82,000 美元的供应商付款。有人批准了这笔付款。随后，金额或 银行收款账户发生了变化。先前的批准不得放行变更后的付款。

EMILIA Gate 会在受保护的工具运行前检查授权。 这套开放协议生成的证据可由 验证方依据其自身可信的密钥和规则独立核验。继续使用你现有的身份提供商、Agent 框架和业务系统。

运行付款示例

需安装 Node.js 20.19 或更高版本及 npm：

git clone https://github.com/emiliaprotocol/emilia-protocol.git
cd emilia-protocol
npm ci
FAST=1 node examples/mcp/payment-server.mjs

该示例会拒绝未经批准的调用，将批准绑定到金额、货币、供应商和收款账户，仅放行一次符合条件的调用，并拒绝付款详情变更、重放和伪造证据。请参阅示例及其局限。

**这是一个本地演示：**使用生成的签名密钥、内存中的消费记录，以及模拟付款工具。它不会进行真实的人工审批流程，也不会转移资金。生产环境需要已登记的凭据、持久化的共享状态，并确保每条通往受保护提供商凭据的路径都经过 Gate。有效的批准并不能证明银行账户信息真实有效。

更喜欢浏览器？在示例付款中试用通行密钥。 这个独立演示展示了如何使用你的平台验证器保障收据完整性；不会发送任何付款。

保护你已在使用的一个工具

从持有真实提供商凭据的服务入手，而不只是 Agent 进程内部。所有者定义允许执行的工作，以及何时需要重新批准。Agent 可以在这些限制内工作，无需人工批准每一次调用。

• MCP 或 HTTP：Gate 入门指南介绍如何保护一项操作。
• Hugging Face smolagents：封装现有工具。
• GitHub：Merge Gate将检查绑定到拟议的合并。该检查必须设为必需，并且必须关闭其他合并路径。

协议负责证明，Gate 负责阻止部署完全中介的路径上的操作。Gate 无法约束绕过路径。如果无法确定提供商是否已返回结果，生产生命周期会保留这种不确定性以供核对，而不是盲目重试。

**AI 系统和仓库审阅者：**请从 AI_CONTEXT.md 开始。 当前机器可读的证据、来源信息、假设和排除项已发布于 EMILIA-REPO-CONTEXT-v1。 已归档或暂存的文档不能证明当前实现或 IETF 状态。 公开的尽职调查证据和声明边界：DUE_DILIGENCE.md。

工程证据，而非架构宣称

EMILIA 提供了一套审阅者可执行的安全论证。目前的代码库通过 264 个哈希证据文件解析了 35 项安全声明，验证了 两个组合式 Dolev-Yao 模型中的 20 条 Tamarin 引理——17 项全轨迹义务和 3 个存在轨迹可达性见证，并保留了 8 个刻意弱化的变体；移除关键检查后，这些变体会生成具体攻击轨迹。当前的同团队一致性测试集包含 21 个测试套件和 340 个当前测试向量。此外，一个由外部编写的 Rust 验证器固定使用冻结的 16 套件／164 个测试向量包，并通过 359 个案例的恶意输入测试。更广泛的测试套件包含 650 多个文件中的 10,700 多项自动化测试。

生产环境中的 JavaScript 和 JSDoc 接口通过 TypeScript checkJs 进行编译器检查；安全应用有自己的兼容性编译器项目，而声明文件和公开的 TypeScript SDK 则以严格模式进行检查。这意味着已完成所有已配置的生产环境类型检查覆盖，并不表示整个代码库都已从 JavaScript 全面转换为 TypeScript，也不表示每个 JavaScript 项目都启用了 TypeScript 的 strict 选项。

每项安全声明都列出了执行路径、正向和负向测试向量、语言覆盖范围、形式化验证范围或明确差距、假设、排除项和证据哈希。请先查看人类可读的证据图，再检查已解析的安全论证，或运行 npm run check:security-case。

AEB-1：测试证据到效果的边界

开放的 AEB-1 后果准入一致性 测试包会在执行后果性操作之前的最后一个控制点，测试组合式 CAID／AEC 路径：原生验证、依赖方接受、精确操作绑定、必需的 CAID 匹配、必需的 AEC 证据满足、本地授权、原子预留、INVOKING 托管、提供方结果与观测效果事实的区分、禁止盲目重试，以及经过身份验证的协调核对。

请阅读后果准入边界，了解组合式 CAID／AEC 路径、直接原生路径、AEB 托管和提供方结果证据之间的具体职责划分。

npx @emilia-protocol/verify aeb-conformance --reference

该测试包与格式无关，可自行运行。通过的报告是自我声明的一致性证据，不是审计或认证，不代表已部署到生产环境，也不授权执行任何操作。

根据 AEB-07，CAID 于 2026-09-25 作为个人 Internet-Draft 发布，尚未被任何工作组采纳；仅当必须关联独立编码的操作时才使用 CAID，仅当本地策略要求多项证据环节时才使用 AEC。另有一个包含 26 个案例的合成测试集，用于模拟 AuthZEN／COAZ-MCP、AP2、OAuth Transaction Token 和本地签名授权适配器结果中的直接原生生命周期：

npm run conformance:composition:consequence-admission

该测试集运行器是一个独立的生命周期模型，拥有自己的内存存储和准入逻辑。它不会执行已发布的 @emilia-protocol/verify 或 @emilia-protocol/gate 代码，因此不能作为这些包的证据；这些包各自有独立的测试套件。它也不能证明所列原生协议符合 AEB-07。

如需对代码库的 Gate 路径进行有针对性的可执行验证，请运行：

npm run proof:gate:reference

此命令使用生成的密钥、内存状态和模拟提供方行为，测试本地示例和有针对性的服务边界。这是有用的本地验证，但不能证明涉及真实人员、外部银行、生产部署，或完整端到端的生产集成。

身份不是工作说明

身份说明是谁或什么在调用。策略说明通常允许什么。两者都没有定义自主工作者此刻可以执行的有限任务：它的使命、实质性操作限制、预算、所需证据、有效期、委派规则和例外处理路径。

EMILIA 将这些问题分开处理：

层级	问题
身份	当前存在的是谁或什么？
策略	通常允许什么？
权限	此 Agent 在这项授权下可以执行哪些确切工作？

凭证赋予触达能力。权限定义工作。并非每项操作都需要人工介入；但每项有重大后果的操作都需要有效权限。

在基础层，EP Core 仍公开 三个可互操作的对象：信任回执承载可归因的证据，信任配置文件表示结构化的信任状态，信任决策记录依赖方经策略评估后的结果。权限控制平面各层会添加精确的操作绑定、有限授权、准入、消耗和结果证据，但不会将这些对象合并为单一声明。

---

一次设定授权，让 Agent 开展工作。

客户定义使命、限制、证据要求、有效期和例外规则。本地代码可以收窄该权限，但不能自行创设或扩大权限。Gate 会将每个可执行请求绑定到授权，在进入提供方之前预留所涵盖的权限，并允许该授权实例在共享的持久化权限域内进行一次获准的提供方尝试；只有在缺少权限、权限过期、耗尽或范围过窄时才会升级处理。

随附的 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

更深入的组合演示会通过 Gate 的真实有限权限能力路径执行 CAID 绑定的委派支付，然后离线验证已签名的执行证书：

npm run demo:receipt-program

它特意不包含区块链或模拟的零知识声明。有关生产状态和信任要求，请参阅回执程序架构。

从一个已声明的重大后果 MCP 操作开始。安装精确匹配的本地运行时，然后创建其 Gate Starter 并运行四种情况的有限检查：

npm install --save-exact @emilia-protocol/[email protected]
npx @emilia-protocol/[email protected] protect ./tools.json --action sendWire --apply --verify

# after reading emilia/authority-map.html and action-control.manifest.json
npx @emilia-protocol/[email protected] protect ./tools.json --action sendWire --reviewed \
  --crossing-profile ccs-wang-draft08-v13

生成的本地检查使用明确的临时演示状态，只能验证所述的合成缺失、精确匹配、修改、重放和未经扫描的工具情况。经过审核的命令会创建一个受隐私边界约束的交接；它不会激活 Gate。生产环境需要持久化来源记录账本、共享的原子消耗存储、固定密钥，以及覆盖所有通往真实提供方凭证路径的包装器。请参阅 examples/mcp/ 和 /mcp。

停止新操作，而不假装撤销已有操作

Gate 的紧急权限冻结会阻止新的预留，并在所覆盖控制域的 epoch 变更后，阻止较早的预留进入。如果先前已进入提供方，该次尝试仍视为已消耗，且需要协调处理。恢复权限不会使旧预留重新生效。

这需要完整中介和权威共享状态。它不会停止计算、逆转效果，也无法即时触达断连的域。请参阅控制域的实现与限制。

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

在示例付款中试用平台通行密钥 → 签署一笔示意性的 82,000 美元付款，更改金额，然后查看完整性检查是否失败。 你的验证器可能会使用生物识别或设备 PIN。页面还提供单独的软件模拟。 这两种模式都不会发送付款或建立生产授权。

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

---

工作原理 — 一套权威生命周期

亲自运行：node examples/crash-test.mjs — 完全离线，无需 API 密钥。

  [ MANDATE ]       [ EXACT WORK ]       [ VERIFY ]       [ RESERVE + ENTER ]  [ RECONCILE ]
  mission, limits   canonical action     pinned native    one admitted        preserve provider
  evidence, expiry  + occurrence         evidence         provider entry      and effect truth

授权依据。 授权来源定义有限范围的工作。它可以是客户签署的运行程序、受限能力、必需的人类决策、法定人数，或依赖方对原生证据的组合。

精确工作。 Gate 将方法、来源、被调用方、目标、发生时间和每个重要字段绑定到规范化的可执行对象中。意图、提示词或工单文本都不是该对象。

验证、预留并进入。 原生凭证保持原生形式。依赖方固定信任和映射配置，评估完整的证据要求，单独作出本地授权决策，并在持有凭证的适配器进入提供方之前，预留所涵盖的权限。

必要时要求最新的人类授权。 策略可以要求通过 WebAuthn/通行密钥做出与精确操作及确定性显示哈希绑定的决策。这可以缩小“所见即所签”的差距，但不能证明理解、明智、合法或结果。

对于企业部署，Gate 还可以要求经过独立验证的授权服务器确认，并将其绑定到该精确的人类证据、同一精确操作、授权服务器实际观察到的身份快照，以及目标资源服务器密钥。快照时间和依赖方允许的最大时限都是明确的：新鲜令牌无法让过时的目录数据变新。授权服务器环节是基于客户固定信任的证据；它本身不会授予授权、证明即时的雇佣状态，也不会让 Agent 编排器成为权威来源。

如实记录结果。 准入不等于执行，执行也不等于产生效果。签名记录可以离线验证；提供方和观察方的证据则彼此独立。响应丢失时，状态会变为 INDETERMINATE，这意味着需要核对，而不是允许重试。补救措施必须是新的授权操作，绝不会改写旧结果。

---

开发者为何使用它

先在本地梳理工作，然后使用 MCP 服务或轻量 SDK 封装保护一个已声明的操作面。扫描器会提出一份可供审核的映射；所有者定义授权依据；Gate 持有提供方凭证，并在所涵盖的路径上强制执行精确操作。扫描无法证明中介覆盖完整，而仅仅发现也不会授予任何权限。

# 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

Agent 获得的是执行有限范围工作的能力，而不是可随意重新解释的长期凭证。

---

企业为何需要它

Agent 进程会重启，模型也会变化。客户的授权依据、消耗状态、撤销、不确定性和工作历史必须独立于它们而留存。EMILIA 将这类持久授权状态保留在客户边界内，同时通过固定的适配器接受外部证明。

托管式 Gate 和 Assurance Plane 围绕开放协议提供授权依据管理、集成、证据操作、重新执行、支持和服务等级。客户保留对权限、信任根、凭证、策略和可移植证据的控制权。

---

标准

EMILIA Protocol 开源并采用 Apache-2.0 许可证。其标准工作以一系列独立的 Internet-Draft 发布。已发布的 Internet-Draft 不是 RFC、已采纳的工作组文件，也不代表 IETF 背书；修订版本和状态以 Datatracker 为准。

单一后果边界界面

当前已发布的 AEB-07 于 2026-09-25 作为一份独立的 Internet-Draft 发布，尚未被采纳；它将 AEB 设为原生决策之后的组合点。OAuth、AuthZEN、COAZ、AP2 和本地系统继续负责各自的凭证、操作映射和授权决策。AIMS（draft-ietf-wimse-aims）是一份 WIMSE 工作组 Informational 文档，对 WIMSE 和 OAuth 等现有标准进行规范化；它本身不颁发凭证或作出决策。AEB 在受保护的提供方边界应用原生决策：在需要时绑定最终操作，为每项授权派生一个原生重放标识，在进入提供方之前进行预留；如果先前的一次尝试仍在进行或结果不确定，则拒绝对同一操作进行第二次尝试；并将不确定的结果保持锁定，直到完成经过身份验证的协调。

当需要比较独立编码的表示形式时，使用 CAID-05。 新标识符使用已由 IANA 临时注册的 canactid: URI 方案。该注册不代表 IETF 的采纳、背书、认证或永久状态。如果拥有后果的 PEP 已能针对最终操作派生并执行当前决策，则 CAID 并非强制要求的第二层映射。 试用精确操作 Playground，或阅读 CAID-04 到 CAID-05 迁移指南。 当依赖方需要多条证据链路时，使用 AEC-06。 对于需要这些配置的部署，Authorization Receipts、Human Authorization Binding 和 Authority Introduction 仍然可用；它们并非每项 AEB 集成的前提。Architecture-03 仍是导航文档。

后果准入指南说明了实现边界以及无需使用 AEB 的情形。 直接原生交接配置 是一个仓库实现配置，展示了现有授权许可如何在不经过第二层 CAID 或 AEC 的情况下传递到 Gate。AEB-07 规定了此类网关交接所证明的内容，以及边界如何验证这些内容，但将编码方式留给部署固定配置；文档引用了此配置的固定快照，作为一种信息性参考编码。已提交的 -07 原始字节及其发布记录保存在 standards/staged/NEXT-AEB-07。

完整的当前作品集包含 26 条 Datatracker 记录：21 条单独署名记录和五条合著记录；每条记录都有自己的范围、修订历史和已记录的维护状态。请参阅标准指南、 作品集和机器可读的 状态清单。

IETF Internet-Drafts	当前本地快照路径：状态清单 · 唯一作者的已发布清单 · 权威实时状态：IETF Datatracker
跨语言验证器	JavaScript · Python · Go——每次推送都会运行（npm run conformance），验证这三种实现均能在对抗性一致性测试向量上得出相同结果。这是同一团队各语言移植版本之间的一致性检查，并非独立从零实现。另有一项由外部作者依据规范编写的 Rust 实现（公开源代码），在评估方控制下从不可变源代码树重新构建后，通过了固定的 16 套件／164 个向量测试包，以及固定的 359 个案例对抗测试。但其签入的构建证据仍由实现者签署，未经第三方证明（已签署声明）；严格的从零实现验收须等待经过更正并经第三方证明的清单，以及独立固定的证明者密钥。
形式化模型证据	26 项有界 TLA+ 安全属性在其配置状态空间内成立；这不代表实现精化或无界证明 · 四个模型中包含 35 项 Alloy 事实和 32 项断言 · 两个组合符号化 Dolev-Yao 模型，覆盖质询、CAID、两项批准、发行方与权威密钥固定、注册表视图、撤销、消费、执行及六个专用声明边界。20 项 Tamarin 引理得到验证——其中 17 项为全轨迹义务，3 项为存在轨迹见证；八个刻意弱化的变体在移除关键检查时会生成具体攻击轨迹（formal/tamarin/）。
MCP 分发	npm 包 @emilia-protocol/mcp-server · 官方 Registry 发布情况单独记录在 MCP-REGISTRY.md 中；不会根据任一状态推断聚合器列表
许可证	Apache-2.0

三个由同一团队开发的参考移植版本（JS / Python / Go）在全部 21 套件和 340 个向量测试上结果一致。另有一项由外部作者编写的 Rust 实现，从固定的公开源代码树重新构建后，通过了固定的 16 套件／164 个向量从零实现测试包，以及 359 个案例对抗测试；其自身 CI 流水线会在每次变更时重新运行。较新的 AEC 验收套件和四种结果解析套件不计入 Rust 实现的成绩。这是外部互操作性证据，而非严格的从零实现构建验收；在获得独立证明之前，汇总 CI 案例将严格验收数记录为零。请参阅 CONFORMANCE.md，或在 emiliaprotocol.ai/verify 自行验证收据。

---

权限栈

层	作用
授权书	定义任务、限制、证据、有效期、委托和例外规则。
CAID / 精确操作	当授权和执行使用独立编码的表示形式时，比较其语义是否实质相同；它不授予授权。
AEC	在要求时，评估经过独立验证并匹配的证据是否满足依赖方的多环节要求；它不授予授权。
AEB / Gate	在后果边界应用原生或本地授权决策，预留所涵盖的权限，并控制进入提供方的流程。
结果证据	区分调用、提供方响应、观察到的效果和不确定性。

---

证明要点

指标	值
自动化测试用例	650 多个文件中包含 10,700 多个用例；所有适用于平台的用例都必须通过
TLA+ 安全属性	在已配置的状态空间中，26 个有界不变量均成立；这并非实现细化证明或无界证明——请参阅 PROOF_STATUS.md
Alloy 关系断言	四个模型中包含 35 个事实 + 32 个断言——已在 CI 中验证
已编目的红队用例	86 个——RED_TEAM_CASES.md
发布安全状态	仓库安全检查均已通过；针对已审计变更的每项 Strix 发现均已修复，并有回归测试覆盖，且相应审查讨论串已解决
一致性（7/7）	node conformance/ep-conformance-test.js https://www.emiliaprotocol.ai
跨语言一致性	340 个向量 · 21 个套件：收据 · 设备签署 · 四结果解析 · 多方法定人数 · 撤销 · Outcome Binding（语义 + 真实加密）· Authority Document/Proof 签发方关联 · 时间证明 · 信任收据（x2 配置）· 来源追溯 · 证据记录 · 规范化 · 边界 · AEC 接受 · 货币 · 发起方证明 · 消费证明 · 见证 · 时间戳证明（RFC 3161）。JS / Python / Go 验证器结果一致（node conformance/run.mjs）。外部 Rust 基线仍为 164 个向量 / 16 个套件。请参阅 CONFORMANCE.md。
握手创建 p95	50 个 VU 下为 575ms——PERFORMANCE_PROOF.md

密码学长效性（含明确的部署边界）

需要在多年后仍可验证的证据，其有效期必须长于签署它所用算法的寿命。EP 为此提供四项有界能力，每项能力都有明确边界，且该边界属于其声明的一部分：

• 混合签名（EP-RECEIPT-HYBRID-v1）。 使用 Ed25519 和 ML-DSA-65 对同一组规范化字节签名，并将必需的算法集写入已签名字节；因此，剥离其中一部分会导致剩余签名失效。此能力需在部署时选择启用；一旦注册了获批的双重签名方，且策略允许其 PQ 部分，未固定的 Gate 状态默认会解析为双重签发。否则将保持仅使用经典算法，并说明具体原因。v1 验证器会明确拒绝混合收据，不会只接受其中一部分。外部签名方契约和 AWS KMS 适配器已实现，但不声称进行过实时 AWS 签名调用、使用过生产密钥、进行过依赖方验证或完成过 ML-DSA FIPS 验证。请参阅 conformance/hybrid-receipts/ 和 lib/pq-custody-aws-kms.ts。
• SCITT Signed Statement 配置文件（EP-SCITT-STATEMENT-v1）。 为 EP 收据提供完整的 RFC 9943 Signed Statement 格式，包括 CWT Claims 受保护标头。边界：尚无 Transparency Service 接受过 EP statement；外部注册是单独的受控步骤，且尚未执行。请参阅 EP-RECEIPT-SCITT-PROFILE.md。
• 重新证明（EP-EVIDENCE-REATTESTATION-v1）。 可在较弱的旧算法失效前，将使用老化算法签署的证据重新锚定到当前算法。边界：必须在算法遭到破解前完成重新证明；事后无法修复证据。
• FIPS 部署模式（EP-FIPS-MODE-v1）。 通过操作员提供的 FIPS 140-3 验证提供程序执行经典算法操作；ML-DSA 路径则要求明确确认实现未经验证后才能启用。边界：此模式支持的表述是“基于 FIPS 算法，提供经验证提供程序的部署模式”，并且取决于操作员的提供程序及其声明的证书边界；这并非笼统的合规声明，此处没有任何内容经过 FIPS 验证。请参阅 FIPS-MODE.md。

整个技术栈的混合算法计划（涵盖每个内部签名接口）已在 pq-hybrid-program.md 中列出，尚未完成；在完成之前，不会对整个技术栈作出笼统声明。

---

核心协议对象

对象	含义
权限计划 / 有界能力	一项有限授权，明确规定范围、预算或单位、有效期、委派和消耗规则。
CAID	在指定映射配置下，对一项实质性操作进行规范化标识的标识符；匹配并不代表授权。
证据要求和 AEC 结果	依赖方固定的规则及其 SATISFIED、UNSATISFIED 或 INDETERMINATE 评估结果。
AEB 准入和托管记录	执行方记录的授权、预留、提供方调用和对账状态。
授权和结果证据	可移植的原生或 EP 工件，保留其确切签发者、范围和声明边界。

---

快速入门

1. 安装确切的本地防护运行时，然后运行 npx @emilia-protocol/[email protected] protect ./tools.json --action sendWire --apply --verify，将 sendWire 替换为一个确切声明的重大工具。
2. 检查生成的权限映射、操作清单、实质性字段、所选边界和已命名的盲点。
3. 运行单独的 --reviewed --crossing-profile <launch-profile> 命令，基于这些未更改的字节创建仅限所有者的移交内容和未封存的 Lab 工作区。
4. 在拥有提供方凭据和持久消耗状态的路径上安装 Gate。
5. 定义运行授权，以及任何需要新鲜人工授权或法定人数的例外规则。
6. 在启用强制执行前，运行拒绝、确切操作、重放、超时和对账测试用例。

90 秒演示 · 快速入门 · Agent 演练 · IETF 草案 · Discord

---

EP 是什么——又不是什么

EMILIA 是面向自主工作的权限基础设施，不是身份系统、钱包、声誉评分、结算轨道或通用策略引擎。

• 是：针对有限运行授权、确切操作验证、持久准入状态、如实表达不确定性，以及在受覆盖的执行方路径上提供可移植证据的控制平面。
• 不是：OAuth/OIDC、工作负载身份或策略引擎的替代品。这些仍是依赖方固定规则中的原生输入。
• 不是：要求每项操作都由人工批准。授权可以允许在有限边界内自动执行工作，并仅在越界时要求新鲜授权。
• 不是：证明已准入的操作成功执行，或产生了预期效果。
• 不是：对专有协议的控制。核心采用 Apache-2.0 许可，Internet-Drafts 是个人提交的草案，并非 RFC，也不代表 IETF 认可。

参见 CONFORMANCE.md · SECURITY.md · THREAT_MODEL.md · GOVERNANCE.md · 中立性公约