EMILIA Protocol

EMILIA Protocol

---

让你的代理准备付款。控制它可以放行的内容。

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

EMILIA Gate 会在受保护工具运行前检查权限。 开放协议使生成的证据能够依据验证方自己的可信密钥 和规则进行独立检查。保留你现有的身份提供方、代理框架和业务系统。

运行付款示例

需要安装 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。有效批准并不能证明银行账户信息真实有效。

更喜欢浏览器？在示例付款上试用通行密钥。 这个独立演示使用你的平台身份验证器展示回执完整性；不会发送付款。

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

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

• MCP 或 HTTP： Gate Starter 将引导你完成一个受保护操作。
• Hugging Face smolagents： 包装现有工具。
• GitHub： Merge Gate 将检查绑定到拟议的合并。必须将该检查设为必需，并关闭其他合并路径。

协议提供证明。Gate 在部署完全中介的路径上实施阻止。 Gate 无法约束绕过路径。如果无法确定提供方的结果，生产生命周期会保留这种不确定性以供协调，而不是盲目重试。

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

工程证据，而非架构声明

EMILIA 提供了一套审查者可以执行的安全论证。当前代码仓库解析了 35 项安全声明，涉及 264 个经过哈希处理的证据文件，验证了 两个组合式 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（于 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 将这些问题分开处理：

层	问题
身份	当前是谁或什么？
策略	通常允许什么？
权限	该代理在此授权下可以执行哪些确切工作？

凭据赋予访问能力。权限定义工作。并非每项操作都需要人工参与；但每项会产生后果的操作都需要有效权限。

在基础层，EP Core 仍公开 三个可互操作的对象：Trust Receipt 携带可归属的证据，Trust Profile 表示结构化的信任状态，而 Trust Decision 记录依赖方经过策略评估的结果。权限控制平面各层会增加精确操作绑定、有限授权、准入、消费和结果证据，而不会将这些对象合并成一个声明。

---

一次设定授权。让代理开展工作。

客户定义使命、限制、证据要求、有效期和例外规则。本地代码可以缩小该权限范围，但不能凭空创建或扩大权限。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/mcp-guard@0.7.0
npx @emilia-protocol/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify

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

生成的本地检查使用明确标记为临时的演示状态，只能证明所述的合成缺失、精确匹配、变更、重放和未扫描工具案例。 经审查的命令会创建一个受隐私限制的交接包；它不会激活 Gate。生产环境需要持久化的来源记录账本、 共享的原子消费存储、固定的密钥，以及在通往真实提供方凭据的每条路径上部署包装器。请参阅 examples/mcp/ 和 /mcp。

阻止新操作，但不假装撤销旧操作

Gate 的紧急权限冻结会阻止新的预留，并在受保护控制域的纪元发生变化后，阻止较早的预留继续执行。 如果先前已进入提供方，则该尝试仍视为已消费，且需要协调。恢复权限不会使旧预留重新生效。

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

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 还可以要求由独立验证的 Authorization Server 确认，并将其绑定到该确切的人类证据、同一确切操作、AS 实际观察到的身份快照，以及预期的 Resource Server 密钥。快照时间和依赖方的最大时效是明确的：新鲜令牌无法让过时的目录数据变成最新数据。AS 这一环是在客户固定的信任基础下提供的证据；它本身不会授予权限，不会证明雇佣关系在某一瞬间的状态，也不会让代理编排器成为权威。

如实呈现结果。 准入不等于执行，执行也不等于产生效果。签名记录可以离线验证；提供方证据和观察方证据仍然彼此独立。响应丢失会变成 INDETERMINATE，这是一种需要协调的状态，而不是重试许可。补救措施是一项新的授权操作，绝不会改写旧结果。

---

开发者为何使用它

先在本地梳理工作，然后用 MCP server 或轻量 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

代理获得的是执行有界工作的能力，而不是可由其重新解释的长期凭据。

---

企业为何需要它

代理进程会重启，模型也会变化。客户的授权范围、消耗状态、撤销状态、不确定性和工作历史必须保存在这些进程之外。EMILIA 会在客户边界内保留这些持久化的权威状态，同时通过固定的适配器接受外部证明。

托管式 Gate 和 Assurance Plane 在开放协议之上提供授权范围操作、集成、证据操作、重新执行、支持和服务级别。客户仍掌控权限、信任根、凭据、策略和可移植证据。

---

标准

EMILIA Protocol 是开放标准，采用 Apache-2.0 许可。其标准工作以多份独立 Internet-Draft 的形式发布。已发布的 Internet-Draft 并非 RFC、已采纳的工作组文档或 IETF 背书；修订版本和状态以 Datatracker 为准。

IANA 注册

两个已注册名称为实现者提供了 EMILIA 格式的通用参考：

• application/vnd.emilia.authorization-evidence-challenge+json 于 2026 年 10 月 6 日注册。它标识已发布序列化规范定义的裸 AE-CHALLENGE-v1 JSON 对象。 HTTP 拒绝响应仍使用 application/problem+json。
• canactid: 于 2026 年 10 月 5 日临时注册。它为 CAID-05 下的确切类型化操作命名。其更正后的 CRI 方案编号为 1033。

这些注册发布了名称及其规范，但并不代表 IETF 采纳、背书、认证或客户部署。

单一后果边界接口

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

当需要比较独立编码的表示时，使用 CAID-05。 新标识符使用 IANA 临时注册的 canactid: URI 方案。该注册不代表 IETF 采纳、背书、认证或永久状态。如果负责后果的 PEP 已经基于最终操作推导并强制执行当前决策，则 CAID 并非必须进行的第二次映射。 试用确切操作演练场，或阅读 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 条由单一作者撰写，5 条由多位作者合著；每条记录都有自己的范围、修订历史和已记录的维护状态。请参阅标准指南、 文档组合和机器可读的 状态清单。

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 验收和四结果协调套件。它属于外部互操作性证据，而非严格的全新实现构建验收；汇总 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 签名声明配置文件 (EP-SCITT-STATEMENT-v1)。 为 EP 收据定义完整的 RFC 9943 签名声明结构，包括 CWT Claims 受保护标头。边界：尚无透明度服务接受任何 EP 声明；外部注册是单独的受控步骤，目前尚未执行。参见 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/scan@0.6.0 protect ./tools.json --action sendWire --apply --verify，将 sendWire 替换为一个已明确声明的具体后果工具。
2. 检查生成的权限映射、操作清单、实质性字段、选定边界和明确列出的盲点。
3. 运行单独的 --reviewed --crossing-profile <launch-profile> 命令，根据这些未更改的字节创建仅所有者可访问的交接内容和未封存的 Lab 工作区。
4. 在拥有提供程序凭据和持久化消耗状态的路径上安装 Gate。
5. 定义运行授权，以及任何需要新鲜人工授权或法定人数的例外规则。
6. 启用强制执行前，先运行拒绝、精确操作、重放、超时和对账测试用例。

90 秒演示 · 快速入门 · 智能体演练 · IETF 草案 · Discord

---

EP 是什么——以及不是什么

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

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

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