EATP 规范（完整文本）

EATP（企业代理信任协议）：核心论文

Enterprise Agent Trust Protocol

为何信任谱系是企业 AI 所缺失的基础设施

作者：洪博士（Dr. Jack Hong），新加坡管理大学

版本：2.2 ｜ 2026 年 3 月

许可：CC BY 4.0

摘要

企业代理信任协议（Enterprise Agent Trust Protocol，EATP）针对企业 AI 治理中的一项结构性缺口：缺乏一种系统化、可验证的机制，将自主 AI 的行为追溯回人类授权。本文阐述该协议的核心洞见，即将信任建立的时刻与信任验证的时刻相分离，并描述五个以密码学方式相互链接的要素（起源记录、委派记录、约束包络、能力证明、审计锚），它们共同构成一条不可伪造（在标准密码学假设下：Ed25519 数字签名的不可伪造性与 SHA-256 的抗碰撞性）的信任谱系链。

2.2 版在协议中扩展了可选的结构化推理轨迹，这是关于信任决策为何作出的机器可验证记录，与既有的「谁、做了什么、何时」相补充。推理轨迹附加于委派记录与审计锚之上，具备企业机密性分级（PUBLIC 至 TOP_SECRET）、双重绑定加密签名（推理轨迹哈希被绑定进父记录的签名中，并以独立的推理签名用于内容验证），以及基于 SD-JWT 选择性披露的隐私模型。

独立的参考 SDK（Python，v0.1.0）实现了完整协议：四项操作（ESTABLISH、DELEGATE、VERIFY、AUDIT）、五个约束维度、带机密性分级的结构化推理轨迹、具备防重放保护的代理间消息传递、PostgreSQL 持久化存储、可与 AI 代理框架直接集成的 MCP 服务器、提供完整生命周期管理的 CLI，以及与六种业界标准凭证格式（JWT、W3C 可验证凭证、DID、UCAN、SD-JWT、Biscuit）的互操作性。

本规范以 CC BY 4.0 发布。所有参考实现以 Apache 2.0 开源许可证发布。EATP 是一项由 Terrene Foundation（泰睿基金会）维护的公共物品。

披露

我设计了 EATP 并构建了 Kailash 参考实现。作者同时是所述系统的设计者、构建者与评估者，这一双重角色构成内在的利益冲突，读者在评估各项主张时应予以权衡。

EATP 规范以 CC BY 4.0（知识共享）发布，意味着任何人都可以阅读、分享并在其上进行衍生创作。参考实现以 Apache 2.0 开源许可证发布，意味着源代码公开可得，任何人在法律上有权使用、修改并据以构建商业产品，永久且不可撤销。

两项专利申请正在审查中（PCT/SG2024/050503 与 P251088SG；已收到正面 IPRP（国际初审报告），目前在新加坡与美国进入国家阶段；尚未授予专利）。Apache 2.0 许可证包含自动专利授予条款（Apache 许可证第 3 节），向用户提供针对所贡献代码的永久、免版税的专利许可，并在用户发起专利诉讼时提供防御性终止条款。规范本身为 CC BY 4.0。两项许可均依其各自条款不可撤销。作者是 Terrene Foundation（泰睿基金会）的创始人，基金会负责发布该规范并维护参考 SDK。本工作未接受任何外部资助。

问责缺口

一名采购代理审批供应商发票。在传统治理下，由人类逐张审阅发票，运用判断并签署。问责清晰：批准的人类对决策负责。

现在把这项职能交给一个 AI 代理。它以机器速度处理发票：每小时数百张，而非每天数十张。运营价值显著。但当一笔不当付款被放行时，会出现一个无人能给出令人满意答案的问题：

「是 AI 批准的」并不是一个答案。

它无法回应董事会询问哪位高管承担责任的问题。它无法回应监管者询问谁违反合规要求的问题。它无法回应审计员询问决策线索在哪里的问题。它无法回应法庭询问谁可被追究法律责任的问题。它当然也无法回应调查人员追问，最初为何授权这一特定代理行事的问题。

这不是假设性的担忧。各组织今日正在部署 AI 代理，问责问题被搁置而非解决。每一个被搁置的问题都在累积机构性风险。这种风险正以与 AI 应用相同的速度增长。

本文要回答的问题不是「我们如何打造更好的 AI」，而是「我们如何把使企业 AI 值得信赖的问责结构制度化」。是去做更好的事，而不是把事做得更好。

为何传统方法失效

四种主流方法主导着当下的思路。它们都行不通。

**人在回路中（Human-in-the-loop）**要求人类批准每一项 AI 行为。这保留了问责，却消除了自动化的经济价值。如果每张发票都必须由人类审批，那么你建造的不是自主代理，而是一个昂贵的校验环节。

基于规则的系统试图预先指定每一种正确行为。这在简单、静态的领域可行；在规则无法预见每一种情形的复杂、动态环境中则失败。规则系统会变得与其要治理的问题一样复杂。

事后审查让 AI 自主行动，由人类事后审查。它捕获了速度优势，却无法挽回已造成的损害。等审查发现问题时，付款已发出、邮件已寄出、决策已执行。

默认信任假定可以信任 AI 正确行事。这忽视了 AI 系统会犯错、可被操纵，并且在缺乏人类那种情境判断的情况下运作。

每种方法都犯了同样的错误：把问责问题视为实现的副产品，而非设计的要求。它们都未能就「谁为这个 AI 代理刚刚做的事负责」给出系统化、可验证的答案。

核心洞见

只要意识到该问题混淆了两个不同的时刻，问题就变得可处理：

信任建立：决定一个代理是否被允许在某些边界内行事。这需要人类判断：理解情境、评估风险、承担责任。

信任验证：检查某一具体行为是否落在那些边界之内。这是一种机械性的比较，机器可在毫秒级内完成。

传统治理把两个时刻合并执行：一个人针对每项行为以其判断进行评估并批准或拒绝。当决策少而慢时，这行得通；当决策多而快时，则失败。

EATP 将这两个时刻分开。人类在建立信任时一次性投入判断：定义谁可行动、在何种边界内、在谁的授权之下。系统则持续验证具体行为是否落在已建立的边界之内。

将信任建立的时刻与信任验证的时刻分开。 人类深思熟虑地定义边界。机器持续地执行这些边界。每一项行为都通过可验证的链条追溯回人类的决策。

这就是 EATP 的贡献。不是关于 AI 治理的新理论，而是一种保留人类问责、同时支持自主运行的特定架构性分离。

五要素：信任谱系链

EATP 定义了五个以密码学方式相互链接的要素。它们共同构成信任谱系链：从任意 AI 行为追溯回人类授权的不间断、可验证的连接。

1. 起源记录（Genesis Record）

组织层面的信任根。

一名人类高管以密码学方式承诺：「我对该 AI 治理框架承担问责。」这不是技术行为，而是治理行为，可与签署公司章程或承担监管义务相比拟。

任何 AI 都不会自行创建起源记录。信任源自人类承诺。

起源记录确立最终的问责主体。它把特定的人类权威（CEO、董事会或治理委员会）与下游全部 AI 操作的链条绑定。其后发生的一切都追溯回这一承诺。

2. 委派记录（Delegation Record）

伴随约束收紧的授权传递。

关键规则是：委派只能减少权限，永远不能扩大。一位拥有 50,000 美元支出权限的经理，可以将 10,000 美元委派给 AI 代理；他无法委派 75,000 美元。协议在创建时即拒绝超出委派者权限的委派。

这与健康的人类组织实际运作方式相吻合。授权自上而下、范围逐级收窄。CFO 把预算授权委派给部门主管，主管再把更小的预算委派给团队负责人。链条中没有人能创建自己并不拥有的权限。EATP 让这一组织原则可以由密码学强制执行。

委派可以限定到特定的约束维度。CFO 可能只委派财务权限；CTO 可能只委派运营权限。单调收紧也适用于这些维度子集：再委派者所获得的维度必须是委派者维度的子集，绝不能是超集。一个仅持有财务与时间权限的代理，无法委派它本身并不拥有的运营或数据访问权限。

实现应当对委派链强制可配置的最大深度（参考实现默认为 10）。链条越深，验证延迟越大，任意中间密钥被泄露时的攻击面越广，人类审计员审查链条时的信任推理也越困难。

可选地，委派记录可以包含一条推理轨迹，即一条结构化记录，说明为何作出该委派、考虑过哪些备选方案、有何证据支持决策。这回答了一个传统访问控制从不追问的问题：不只是「谁把什么委派给了谁」，还包括「为何作出这一决定」。推理轨迹具备自身的机密性分级与双重绑定加密模型：推理轨迹哈希绑定进父记录的签名中（防止事后替换），同时以独立的推理签名支持对推理内容的独立验证。这使得理由可以独立于委派本身被验证、被涂黑或被保留。

3. 约束包络（Constraint Envelope）

跨五个维度的多维操作边界：

财务：交易额上限、支出上限、累计预算。

运营：被允许与被禁止的行为。代理可做什么、不可做什么。

时间：运行时段、停运时段、有时限的授权。

数据访问：读写权限、PII（个人可识别信息）处理规则、数据分级边界。

通信：被允许的渠道、获批的接收方、语气与内容指引。

约束包络把人类判断编码为机器可验证的边界。其判断是：「在我对这一角色、这些风险与这些要求的认识下，该代理应在这些限制内运行，无需额外审批。」判断由人类作出，验证由机器完成。

选择五个维度是一项设计决定。这些维度从对常见组织约束的分析中浮现而来。其他分解方式可能同样有效。但这五个维度涵盖了企业最常面对的治理关切。

4. 能力证明（Capability Attestation）

关于代理获授权可执行哪些行为的签名声明。

这解决了治理框架很少触及的一个问题：能力漂移。随着时间推移，AI 代理逐渐承担起从未明确获得授权的任务。一个负责生成报告的代理开始进行数据更正；一个排程代理开始向外部发送通信。每一次增量扩张看似微小。累计起来，代理的运行远超出其原本的范围。

能力证明使获授权的范围明确且可验证。如果代理尝试超出其证明能力之外的行为，系统会在执行前而非事后将其捕获。

5. 审计锚（Audit Anchor）

永久的、可检测篡改的执行记录。

每个审计锚对前一个锚进行哈希。修改任意一条记录都会使从该处起向后的链条失效，从而使篡改可被检测。

诚实的局限：简单的线性哈希链有已知弱点。攻陷系统的攻击者可以从攻陷点起向后修改所有记录，并保持哈希一致性。生产环境实现应在独立安全审查之后采用更强的机制，例如默克尔树或定期对外检查点。

审计锚回答调查中真正重要的问题：发生了什么？谁授权？适用了哪些约束？这些约束是否被遵守？以及，可选的，代理为何选择此项行为？审计锚可以包含一条推理轨迹，即代理对其决策的结构化理由，其机密性分级与双重绑定签名模型与委派推理轨迹相同。这些回答以密码学方式与证据相绑定，而非凭记忆或断言重构。

验证如何运作

当代理提议某项行为时，系统会检查整条信任谱系链。但验证并非二元。EATP 定义了一种梯度：

结果	含义	行动
自动批准	在所有约束内	执行并记录
标记	接近约束边界	执行并标记以供审查
暂留	越过软性限制	排队等待人类批准
阻止	越过硬性限制	拒绝并给出解释

这一梯度把人类的注意力聚焦在最重要之处：边界附近与限制处，而非分散在所有行为之上。经理无需看到所有常规交易，他只需看到那些接近限制或进入灰色地带的交易。「暂留」的行为不应在超时后自动批准。实现可以选择对该行为自动拒绝或自动降级。任何启用基于超时自动批准的组织，必须以记录一条「标记」的审计锚来审计这一较弱的保证，承认该行为是在没有显式人类授权的情况下推进的。

参考实现提供三种验证级别，以速度换取彻底性：QUICK（约 1 毫秒，进行哈希与过期检查）、STANDARD（约 5 毫秒，进行能力与约束验证）、FULL（约 50 毫秒，对整条链进行加密签名验证，包含推理轨迹哈希与签名验证）。这些延迟数字是设计目标，而非基准测试结果；实际性能取决于实现、存储后端与链深。REASONING_REQUIRED 约束要求推理轨迹必须存在。该名称表达组织策略意图；其执行强度随验证梯度而升级：在 STANDARD 级别，缺失推理产生不阻塞的告警；在 FULL 级别，当 REASONING_REQUIRED 生效时，缺失推理会导致验证失败。当推理轨迹存在且为 FULL 级别时，将同时验证哈希完整性与签名有效性。生产部署可根据每项操作的敏感程度选择合适的级别。

STANDARD 验证的风险。 STANDARD 验证省略了加密签名校验。它不提供加密层面的防御，其安全性完全依赖信任存储的完整性。在分布式部署中，若信任存储被复制或缓存，攻击者一旦获得对本地副本的写入权限，便可插入伪造记录，而 STANDARD 会接受这些记录。三项缓解措施适用：（1）信任存储由操作系统级或数据库级访问控制保护，限制可写者；（2）FULL 验证始终可用，对高后果行为应当使用；（3）审计锚提供事后检测，即便伪造记录在 STANDARD 级别被接受，由此产生的审计轨迹也为后续调查留下证据。

五种信任姿态

EATP 通过五种信任姿态支持渐进式自主：

姿态	自主性	人类角色
伪代理（Pseudo-Agent）*	无	人在回路中；代理仅作为接口
受监督（Supervised）	低	人在回路中；代理提议，人类批准
共同规划（Shared Planning）	中	人在回路之上；人与代理共同规划
持续洞察（Continuous Insight）	高	人在回路之上；代理执行，人类监控
完全委派（Delegated）	完全	人在回路之外；远程监控

*「伪代理」表示该软件作为接口（而非自主代理）；所有推理与决策由人类完成。

姿态可以随着信任通过实证表现的累积而升级，也可以在情况变化时即刻降级。这就是组织实际管理委派的方式：通过过往业绩赢得信任，通过失误失去信任。

存在三类触发姿态转换的情形：（1）信任违规，约束被打破时立即降级；（2）人工请求，人类基于判断决定调整姿态；（3）环境条件，情境改变（例如必需的审阅人不可用、网络分区隔离了信任存储或出现时间紧迫的运营情境）促使预防性降级。值得注意的是，时间紧迫的情境不构成自动批准「暂留」行为的理由；紧迫性可能使姿态降级（减少代理可自主完成的事），但绝不能绕过约束执行。

级联吊销

当任意层级的信任被吊销时，所有下游委派将在一个由凭证有效期与传播延迟决定的有界窗口 Δ 内失效，此后下游代理的进一步行为将不再获得授权。在权威源被移除并且传播窗口关闭后，没有任何代理会成为继续运行的孤儿。

重要警示：「即时且原子化」是架构目标，并非可保证的属性。分布式系统存在传播延迟。被缓存的凭证可能短暂存续。在传播窗口 Δ 内，被吊销的代理可能凭借缓存凭证继续运行。

缓解措施：使用有效期为五分钟的短期凭证为 Δ 设上界；基于推送的吊销通知加快传播；行为幂等性防止重连期间的重复执行。吊销在信任存储中是永久且不可撤销的。若下游代理在吊销发生时离线，其下次验证尝试将失败。组织应针对传播并非真正即时这一现实进行设计，并为这一缺口构建补偿性控制。

现有技术：EATP 在何处之上构建

EATP 并非凭空而来。诚实地评估现有技术是必要的。

控制平面 / 数据平面分离来自软件定义网络与 Kubernetes。将策略决策与策略执行相分离的架构模式已被充分确立。

PDP/PEP 架构（策略决策点 / 策略执行点）源自 XACML，提供了集中的策略决策与分布式执行的模式。

OAuth 2.0 作用域（RFC 6749）展示了带约束收紧的委派授权，这正是 EATP 应用于 AI 代理委派的原则。

SPIFFE/SPIRE 为分布式系统提供工作负载身份与信任引导。

PKI 证书链确立了带加密验证的层级化信任模式。

**Haber 与 Stornetta（1991）**为数字文档发展了时间戳机制。**Merkle（1980）**形式化了哈希树，用于高效验证。

**Irving 等（2018）**在 DeepMind 提出通过辩论进行 AI 安全的框架，让 AI 代理在人类裁判面前为某项拟议行为正反辩论。EATP 的验证梯度处理一个相关但不同的问题：与其让代理逐项辩论，EATP 预先确立可接受行为的边界，并以机械方式验证合规。两种方法是互补的，辩论机制可以作为针对 EATP 暂留以待批准的行为的一种人工审查流程。

**NIST AI 风险管理框架（2023）**建议的治理结构包括明确的授权链、有据可查的风险边界、持续监控与可审计的决策记录。在较高层面，EATP 的五要素映射到这些建议：起源记录确立治理权威，约束包络编码风险边界，信任姿态实现渐进监控，审计锚提供决策记录。NIST 并不规定具体协议；EATP 是其结构性方法的一种具体实现。

基于能力的安全起源于 Dennis 与 Van Horn（1966），他们引入「能力」作为不可伪造的权限令牌。Miller、Yee 与 Shapiro（2003）证明，能力纪律（即权限只能通过显式委派流转）可在没有环境权威的情况下提供约束属性。EATP 的委派模型即是一种能力系统：每条委派记录都是一项不可伪造（在前述同一密码学假设下）、可衰减的能力，只能收窄权限。其关键差异在于，EATP 的能力承载多维约束与审计义务，这是经典能力系统所不具备的。

Macaroons（Birgisson 等，2014）为去中心化授权引入情境化附加条件，即可由附加条件（限制条件）衰减的持有者凭证，无需联系颁发者。EATP 的约束收紧模型与之直接类比：每次委派都增加约束以收窄运行包络。Macaroons 在请求 / API 层运作；EATP 在组织治理层运作，并加入了 Macaroons 不涉及的人类来源可追溯性、审计锚与推理轨迹。

KeyNote/PolicyMaker（Blaze、Feigenbaum、Lacy，1996；Blaze 等，1999）将「信任管理」作为一类独立问题提出，即判断一组凭证是否证明某项请求符合安全策略。EATP 处理同一个根本问题：该 AI 代理拟议的行为是否符合由人类权威确立的信任策略？但它在时间约束维度、渐进验证与对决策原因的结构化推理上加以扩展。

SPKI/SDSI（Ellison 等，1999）提出以授权证书替代身份证书，把公钥直接绑定到授权而非姓名。EATP 的起源记录与委派记录承担类似功能：把加密密钥绑定到具体、受约束的授权，而非泛泛的身份。

Zanzibar（Pang 等，2019）是 Google 用于生产规模授权的系统，采用基于关系的访问控制，证明全局一致的授权决策可在大规模下作出。EATP 的验证操作面临同样的一致性挑战；Zanzibar 在一致读取与命名空间分区方面的方法，对 EATP 部署的未来扩展设计具有参考意义。

Cedar（Cutler 等，2024）提供了一种经过形式化验证的授权策略语言，附有可靠性与可判定性的证明。EATP 的约束逻辑尚未经过形式化验证；Cedar 既证明了对授权策略语言进行形式化验证的可行性，也展示了所需的工作量。这是被承认的局限（参见下文「形式化验证」）。

OPA/Rego（Cloud Native Computing Foundation）提供了通用策略引擎，配以声明式策略语言。许多组织已使用 OPA 进行基础设施授权。EATP 的约束评估可以使用 OPA 作为策略后端来实现；两者运行在不同层次（OPA 评估策略规则；EATP 管理信任谱系与产生这些规则的约束）。

这些都是成熟、被充分理解的系统与框架。身份与访问系统验证身份与权限。授权系统管理被委派的权限。策略系统评估合规规则。治理框架描述良好的 AI 监督应是什么样。它们分别回答：「这个实体是否如其所声称？」「该实体是否被允许执行此操作？」「该行为是否符合策略？」以及「应由何种结构治理 AI 系统？」。

EATP 增加的内容：上述既有系统并不验证某项行为是否落在人类为 AI 代理设立的信任边界之内，也不沿不间断的链条把每一项行为追溯回人类授权，更不记录信任决策为何作出。EATP 处理的是身份 / 访问 / 授权基础设施与面向自主 AI 系统的、保留问责的治理之间这一具体缺口。在治理框架提供结构性建议之处，EATP 提供了一项具体协议，并被设计为运行在既有身份与授权基础设施之上（而非取代它们）。

这是一项比「开创整片领域」更为狭窄的贡献，也是对此处所新增内容更诚实的描述。

竞争格局

数项现有技术处理 EATP 所针对的信任、授权与委派问题的某些部分。诚实地评估其对比，对任何评估 EATP 是否新增价值的人都是必要的。

既有方法

X.509 / PKI 提供具有加密验证的层级化证书链，是 TLS 与代码签名的支柱。然而 X.509 证书证明的是身份，而非行为边界。证书所说的是「这是由权威 B 颁发的代理 A」，而不是「代理 A 在工作时间内可花费至多 10,000 美元，但不可访问 PII」。X.509 也缺乏行为级审计轨迹，且没有跨委派链条进行约束收紧的概念。

SPIFFE/SPIRE 为分布式系统提供工作负载身份，具有自动凭证轮换与引导。它解决「这个工作负载是谁」，但不解决「这个工作负载在这些具体边界内被授权可做什么」。SPIFFE 身份是二元的：工作负载要么具备身份，要么不具备。它没有渐进信任姿态或多维约束的机制。

UCAN（用户控制授权网络） 支持具有衰减的委派授权，即每次委派只能收窄权限。这是与 EATP 委派模型最接近的现有技术。UCAN 在能力委派方面表现良好，但不包含行为级审计轨迹、多维约束包络或信任姿态。UCAN 主要面向去中心化网络应用，而非企业治理场景。

Biscuit 提供基于 Datalog 授权语言的衰减令牌。与 UCAN 类似，它支持跨委派链条的能力收窄。Biscuit 在细粒度授权策略方面表现出色，但缺乏审计轨迹基础设施、信任姿态，以及把每项行为通过链条追溯到具体人类权威的人类来源可追溯性。

OAuth 2.0 / OIDC 为带作用域的 API 访问提供委派授权。它无处不在，但其设计针对的是用户向应用程序的委派，而非带约束收紧的代理之间的委派。OAuth 作用域粒度较粗（例如 read:files），没有内建的多维约束机制，也不产生行为级审计记录。

同时代的 AI 代理信任协议

近期有四篇论文直接处理 AI 代理信任问题。EATP 必须与每一项加以区分。

经鉴权委派（Authenticated Delegation，AD）（South、Marro、Hardjono、Mahari、Whitney、Greenwood、Chan 与 Pentland，2025）通过扩展 OAuth 2.0 与 OIDC，提出在自主 AI 代理之间建立信任的框架。AD 引入自然语言权限描述，并在既有身份基础设施上建立委派链。其关键优势在于落地务实：已部署 OAuth 的组织可在既有基础设施上扩展，而非部署新协议。AD 处理授权问题（代理可做什么），但未规定多维约束包络、渐进信任姿态、结构化推理轨迹或行为级审计轨迹。AD 是一篇描述框架的立场论文，未报告参考实现。EATP 运行在 AD 授权层之上的治理层：组织可在运行时使用 AD 进行基于 OAuth 的授权，同时使用 EATP 进行治理层的信任建立、约束定义与审计。

代理化 JWT（Agentic JWT，A-JWT）（Goswami，2025）以代理身份校验和机制扩展 JWT 标准，用于自主 AI 代理系统中的安全委派。A-JWT 面向 IETF 标准化定位，建立在普及的 JWT 基础设施之上。该协议处理令牌级信任（这个 JWT 是否来自合法代理？），但未规定组织治理链、约束包络、信任姿态或推理轨迹。A-JWT 保护单个委派令牌的安全；EATP 治理决定这些令牌应包含什么内容的组织信任谱系。两者直接互补：EATP 信任谱系可导出为 JWT 令牌（进而扩展为 A-JWT 令牌），用于运行时强制。

Omega（Bodea 等，2025）通过保密虚拟机（AMD SEV-SNP）与保密 GPU（NVIDIA H100）为 AI 代理提供以硬件为根的信任。Omega 为多代理工作负载建立嵌套隔离，对代理代码、模型与 LoRA 权重进行差分证明，并定义在代理代码无法访问的特权内存层执行的声明式策略语言。证明协议使用 Tamarin Prover 进行了形式化验证。这处理的是 EATP 不涉及的威胁模型：被攻陷的执行环境。然而，Omega 把信任视作二元（已证明或不可信），仅提供一个人工审批谓词，不规定组织治理链、多维约束包络、信任姿态或推理轨迹。两者在不同层次互补：Omega 保护执行环境（硬件信任），EATP 治理该环境内的代理获授权可做什么（组织信任）。EATP 审计锚可存入 Omega 的可检测篡改日志中，以实现纵深防御。

OpenPort 协议（OPP）（Zhu 等，2026）规定了一种治理优先的协议，通过服务器端网关保护 AI 代理对应用工具的访问。OPP 引入预飞行影响绑定，即针对规范化影响摘要（依据 RFC 8785）的加密哈希，将执行结果钉定到预先计算的效果之上；同时引入「状态见证（State Witness）」配置，处理延迟批准流程中的检查时刻 / 使用时刻漏洞。自动执行被视为显式、有时限、可吊销的能力，而非默认设置。OPP 在网关层运作，治理代理行为如何穿越工具访问边界。它不处理人类来源可追溯性、代理间委派链或结构化推理轨迹。两个协议在代理行为生命周期中处理不同点位，且自然可组合：EATP 在上游建立信任与约束，OPP 治理被信任代理通过的网关。EATP 约束包络可被 OPP 网关消费，从而推导其授权策略。

EATP 的独特贡献

在上述被调研的系统中，有三项协议特性为 EATP 所独有：

带加密绑定的结构化推理轨迹。 没有任何被调研的系统记录信任决策为何作出。EATP 推理轨迹提供结构化理由（决策、备选方案、证据、方法、置信度评分），具备双重绑定加密签名（推理哈希位于父签名中，防止事后替换；独立的推理签名支持内容验证）、五级企业机密性分级（PUBLIC 至 TOP_SECRET），以及基于 SD-JWT 的选择性披露以实现保护隐私的审计。这填补了「发生了什么」（审计日志可回答）与「为何发生」（既有协议无人回答）之间的缺口。

带渐进自主性的信任姿态。 没有任何被调研的系统形式化「信任级别与人类介入」之间的关系。EATP 的五种命名姿态（从「伪代理」到「完全委派」）在每种自主级别下定义了具体的人类角色，并附明确的升降级机制。这与组织实践直接对应：同一代理可能因实证表现、任务敏感度或情境变化，在不同姿态下运作。

带四类结果的验证梯度。 没有任何被调研的系统提供分级验证结果。二元的通过 / 失败验证迫使在阻止合法行为与放行可疑行为之间二选一。EATP 的四种结果（自动批准、标记、暂留、阻止）将人类注意力聚焦于边界情形，而非分散到所有行为之上。

没有任何单一系统提供以下全部

上述被调研的系统各自处理信任、授权与治理问题的不同方面。下表汇总了基础设施协议、同时代 AI 代理信任协议与 EATP 的特性覆盖：

要求	X.509	SPIFFE	UCAN	Biscuit	OAuth	AD	A-JWT	Omega	OPP	EATP
层级化信任链条	是	是	是	是	部分	是	是	否	否	是
约束收紧	否	否	是	是	否	否	否	否	否	是
多维约束	否	否	否	部分	否	否	否	否	否	是
行为级审计轨迹	否	否	否	否	否	否	否	是	是	是
信任姿态（渐进自主性）	否	否	否	否	否	否	否	否	否	是
人类来源可追溯性	否	否	否	否	否	是	部分	否	否	是
决策推理轨迹	否	否	否	否	否	否	否	否	否	是
硬件信任根	否	否	否	否	否	否	否	是	否	否
预飞行影响绑定	否	否	否	否	否	否	否	否	是	否
形式化验证	否	否	否	部分	否	否	否	是	否	否
与既有格式互操作	N/A	X.509	JWT	N/A	JWT	OAuth	JWT	N/A	N/A	JWT、W3C VC、DID、UCAN、SD-JWT、Biscuit

这并非声称 EATP 优于上述系统。它们运行在不同层次，处理信任问题的不同方面。X.509、SPIFFE 与 OAuth 解决身份与访问。UCAN 与 Biscuit 解决委派授权。AD 与 A-JWT 在既有授权基础设施上为 AI 代理扩展。Omega 以硬件信任保护执行环境。OPP 在组织边界处治理代理交互。EATP 解决保留问责的治理：确立谁在何种多维约束内授权了什么、以及为何如此，并被设计为对这些系统加以补充而非取代。EATP 信任谱系恰恰可以被导出为 JWT、UCAN、W3C VC 与 DID 格式，因为该协议旨在与既有基础设施集成。

NIST 的 AI 风险管理框架（2023）建议的治理结构包括授权链、风险边界、监控与审计记录。没有任何单一既有协议实现了这一完整集合。EATP 是这样做的一次尝试。其是否成功是一个实证问题；上述对照描述的是它所针对的结构性缺口。

生态情境

EATP 是一套治理架构的一个组件。理解它与配套框架的关系，有助于厘清它解决与不解决的问题。

CARE / EATP / CO 三角

Terrene Foundation（泰睿基金会）发布三项并列规范：

CARE（协作自主反思企业，Collaborative Autonomous Reflective Enterprise）（Hong，2026a）定义哲学框架：在 AI 增强的组织中，人类用于何处？CARE 的回答是：人类提供信任、判断与问责，这些是 AI 无法为自身提供的。CARE 确立的是「为何」。

**EATP（企业代理信任协议）**把 CARE 的哲学具体化为一项可验证的协议。EATP 的信任谱系、约束包络与审计锚是 CARE 「信任源自人类承诺，并必须保持可追溯」原则的密码学实现。EATP 确立的是信任基础设施层面的「如何」。

CO（认知编排，Cognitive Orchestration）（Hong，2026c）定义人类如何组织 AI 的工作。CO 提供五层架构，用于在人机协作中维持机构情境、护栏与运行流程。COC（面向代码生成的 CO，Cognitive Orchestration for Codegen）（Hong，2026d）是首个领域应用，把 CO 实例化于软件开发。CO 确立的是运营方法论层面的「如何」。

每项规范都可独立使用。组织可以在不采用 CARE 或 CO 的情况下采纳 EATP；可以在不实施 EATP 协议的情况下采纳 CARE 的哲学；也可以在两者皆不采用的情况下使用 CO 的方法论。但合在一起，它们形成一套连贯的治理栈：CARE 定义原则，EATP 提供可验证的信任谱系，CO 组织工作，PACT（Hong，2026f）则提供组织架构，使得在多层级架构中定义包络、获得知识访问与落实问责变得可行。约束型组织论题（Hong，2026e）研究的是当上述要素一并部署时所涌现的组织形态。

独立可采纳

EATP 被设计为可在不依赖 Terrene Foundation 架构其他任何组件的情况下被采纳。独立 SDK（pip install eatp）对 Kailash、CARE 或 CO 零依赖。组织可以仅使用 EATP 包，把 EATP 信任验证集成到任何既有系统中：FastAPI 服务、Django 应用、MCP 服务器或 A2A 代理网络。

这一设计是有意的。信任基础设施通过广泛采纳创造价值。把采纳与更大框架捆绑会限制广度。独立 SDK 的存在是为了降低采纳门槛，而不是引导通往更大平台的入口。

一致性程序

为支持健康的多实现生态，EATP 定义了三个规范性一致性级别。EATP Compatible（基础）要求起源记录、审计锚与至少一个约束维度，足以提供轻量级信任锚定。EATP Conformant（标准）要求全部五个要素、全部四项操作、完整验证梯度、级联吊销与推理轨迹支持。EATP Complete（完整）在此之上进一步要求全部五种信任姿态、五个机密性级别、StrictEnforcer 与 ShadowEnforcer 两种执行器，以及包括 VerificationBundle 格式在内的互操作性导出。

一致性与参考实现身份是正交的。参考实现由基金会维护，作为协议行为的规范基线；参考身份代表受托管理，而非更高的一致性等级。一致性级别使第三方实现得以声明其覆盖范围，并使采用者得以评估互操作性保证。

开源参考实现

Kailash（完整平台：Core SDK、DataFlow、Nexus、Kaizen）是覆盖最广的 EATP 实现，在 EATP 信任原语之上构建编排、注册与多代理协调。Kailash 在 Apache 2.0 许可下完全开源，由 Terrene Foundation（泰睿基金会）发布。独立 EATP SDK 的存在是为了实现独立可采纳：让那些希望获得信任基础设施而无需采用完整工作流编排平台的组织可以使用。两者皆开放、皆 Apache 2.0，且都不会造成锁定。

参考实现

EATP v0.1.0 提供独立的 Python SDK（pip install eatp），实现完整的协议规范。该 SDK 包含 49,864 行源代码，分布在 85 个模块、20 个子系统中；附带 28,556 行测试代码，分布在 33 个测试文件中，包含 1,575 个自动化测试，其中包括对抗性攻击场景（1,752 行测试移植攻击、重放攻击与链条操纵）与基于属性的不变量验证（732 行使用 Hypothesis）。十一个示例程序（2,665 行）演示集成模式。

核心协议实现

四项操作：ESTABLISH 创建起源记录并将代理密钥与权威绑定。DELEGATE 在单调约束收紧下传递能力。VERIFY 在三种彻底程度（QUICK、STANDARD、FULL）上验证信任谱系。AUDIT 把行为记录到一条以哈希链接的、仅追加的轨迹中。

五个约束维度：财务、运营、时间、数据访问与通信，附六个内置约束模板（治理、财务、社群、标准、审计、最小化）以及模板自定义 API。

结构化推理轨迹：可选的推理轨迹，附带五级机密性分级（PUBLIC 至 TOP_SECRET），可附加于委派记录与审计锚。推理轨迹采用双重绑定签名模型：推理轨迹哈希被绑定进父记录的签名中（防止事后替换），同时以独立的推理签名支持内容的独立验证。基于 SD-JWT 的选择性披露支持依机密性驱动的涂黑。REASONING_REQUIRED 约束类型让组织得以为合规流程强制要求推理记录，其执行强度沿验证梯度递进（在 STANDARD 为咨询性，在 FULL 为强制）。

执行与运营

执行：StrictEnforcer 用于生产环境（阻止未授权行为、暂留以待人工审查），ShadowEnforcer 用于观察模式（记录将被阻止的内容而不打断流程）。挑战 - 应答机制支持代理能力的运行时验证。Python 装饰器为任意异步函数提供三行代码集成。执行的参考架构是代理执行模式：一个具备 EATP 感知能力的代理位于代理与其作用对象之间，拦截每一项行为，在转发到目标系统前运行 VERIFY，并在执行完成后运行 AUDIT。这把信任执行与代理逻辑、目标系统实现都解耦，从而可以在不修改任一者的情况下集成 EATP。

消息传递：代理间消息传递具备加密签名、验证与防重放保护。代理通过带封装鉴权的类型化通道交换消息。

级联吊销：基于推送的广播式吊销，自动向下游传播。当任意层级的信任被吊销时，从该源持有委派权限的所有代理都将收到通知并被作废。

密钥轮换：加密密钥轮换支持对活动记录的自动重新签名，可在不中断信任谱系的情况下进行密钥生命周期管理。

多签：支持对委派记录的多方签名要求，使得组织策略可以要求多名人类权威共同批准高风险委派。

断路器：当错误率超过可配置阈值时，自动降级信任姿态或暂停代理操作的容错机制。

存储与审计

存储后端：内存（用于测试与开发）、文件系统（用于单机部署）与 PostgreSQL（用于生产），全部包含在独立 EATP 包内。存储接口是抽象的；可以针对 TrustStore 协议实现额外的后端。

仅追加审计存储：以 PostgreSQL 为后端的审计存储，附带完整性验证，提供对所有信任操作的持久化、可检测篡改的记录。

默克尔树审计验证：以 O(log n) 复杂度生成证明，可在不遍历整条链的情况下高效验证审计链完整性，作为对线性哈希链的补充。

信任评分：基于委派链属性、约束遵守历史与运行行为模式的定量信任评分计算。

互操作与集成

六种凭证格式：信任谱系可与 JWT（RFC 7519）、W3C 可验证凭证 2.0、去中心化标识符（DID）、UCAN v0.10.0、SD-JWT（选择性披露）以及受 Biscuit 启发的衰减令牌互相导入导出。W3C VC 与 DID 导出支持跨组织信任交换。VerificationBundle 格式提供自包含的导出包，包含完整链条、审计锚与验证元数据，从而支持在无法访问原始信任存储的情况下进行离线或跨系统验证。VerificationBundle 与上述凭证格式互补（后者服务于运行时授权），主要服务于审计、合规与监管报送场景。

Google A2A 协议集成：为 A2A 代理网络自动生成 EATP 能力卡，支持使用 Google 代理对代理协议的多代理系统建立跨代理信任。

MCP 服务器：MCP（模型上下文协议）服务器，公开 5 个信任工具与 4 个资源模板。使用兼容 MCP 框架的 AI 代理可以通过标准的 MCP 工具调用建立信任、验证能力与记录审计条目。

企业系统代理（Enterprise System Agent，ESA）框架：用于数据库系统（PostgreSQL、MySQL、SQLite）的具备信任感知能力的代理（proxy agent），附自动的基于能力的访问控制。ESA 在不修改底层系统的情况下，将 EATP 约束执行包裹在既有数据基础设施之上。

代理注册中心：以 PostgreSQL 为后端的注册中心，记录代理元数据、能力声明与信任谱系状态，支持在组织网络中发现可信代理。

CLI：eatp 命令提供完整生命周期管理：init、establish、delegate、verify、revoke、status、audit、export、verify-chain 与 version。

治理引擎

策略引擎、限速器与成本估算器使组织治理策略可被表达为机器可执行的规则，运行在单个约束包络之上，支持跨所有活跃信任谱系的组织级预算、限速与成本预测。

CARE 平台示范

CARE 平台（55 个模块、11,334 行源代码，附 20,472 行测试代码、1,304 个自动化测试）以多代理团队配置演练 EATP 全部操作。一个由五代理组成的决策团队使用 EATP 信任谱系进行权限委派、约束执行与审计轨迹生成。该示范说明该协议支持真实的多代理协调，而非孤立的信任操作。

SDK 不包含的内容

企业级密钥管理（HSM 集成）与协议形式化验证（ProVerif、Tamarin）不在当前 SDK 范围内。跨组织联邦治理，即组织在建立相互信任时所需的双边协议与信任解析策略，被推迟到未来工作；不过，该协议的 W3C VC、DID 与 A2A 集成提供了可在其上构建联邦的互操作性底座。

本协议未解决的内容

任何隐藏其局限的框架都不值得信赖。EATP 有其根本性的局限。

对手非目标

EATP 不防御以下情形：被攻陷的人类委托人故意创建恶意委派；约束规避（通过一系列各自被允许的行为达成被禁止的结果）；被攻陷的信任存储（信任存储的完整性被假定）；针对加密实现的旁路攻击；多代理共谋，即两个或更多被攻陷的代理协调以绕过对任一被攻陷代理仍然成立的约束（注意：具有委派权限的非叶子节点代理一旦被攻陷，可向受对手控制的代理创建新委派，由此从单代理被攻陷有效地产生多代理被攻陷；非叶子节点被攻陷的影响半径因此大于单代理模型所暗示的范围）；以及针对信任存储或验证基础设施的拒绝服务攻击（例如以无效委派请求泛洪，或触发过量吊销通知）。

约束规避

这是最重要的局限。代理可能通过一系列各自被允许的行为达成被禁止的结果。

代理无法直接转账，却可以批准虚假发票，通过应付账款流程实现资金转移。代理无法直接访问个人数据，却可以生成筛选条件极窄、足以识别个体身份的聚合报告。代理无法终止合同，却可以不断修改条款，使其变得对对方极为不利，从而促使对方主动终止。

这不是缺陷，而是基于边界的治理的根本局限。一个能够完全防止规避的约束系统将需要：完整指定所有不良结果，对从允许行为到结果的因果链进行推理，以及预测对抗性代理行为。这等价于 AI 安全中的对齐问题。EATP 并不解决它。

EATP 提供的是：用于检测的审计轨迹、用于限制重复利用的累积约束，以及用于侦测涌现模式的人在回路之上监控。组织必须提供的是：基于结果的异常主动监控、事件调查、基于已检测模式的约束细化，以及承认这是一项没有终极解的持续工作。

起源权威被攻陷

如果信任根处的人类被攻陷、被胁迫、被收买、疏忽或仅仅判断错误，整条链都将继承这一缺陷。EATP 鉴别链条的真实性，但无法评估创建链条之人的明智程度。这是层级化信任模型的固有性质。

更具体地说，如果该权威的签名密钥被攻陷，所有下游链条都将作废，攻击者可以创建看起来合法的任意委派。部分缓解措施包括：多签起源（要求两名或更多委托人达成一致）、时间延迟机制（在权威生效前提供审查窗口）以及独立见证人共同签署。这些是叠加在协议之上的运营实践，而非协议特性。

正确但不明智的约束

EATP 验证约束被遵守。它不验证约束被明智地设定。一个把约束设得过于宽松的组织，其代理仍将在那些约束内运行，且仍可能造成损害。约束的好坏只取决于设定它们的人类判断。

实现漏洞

协议的安全性取决于实现的正确性。验证代码、密钥管理或加密操作中的缺陷会造成任何协议设计都无法防止的漏洞。参考 SDK 尚未经过独立安全审计。

密钥吊销与轮换

规范并未定义密钥轮换协议。参考实现通过时间约束支持密钥过期，但协议未定义密钥吊销机制（例如等价于 CRL 或 OCSP 的机制）。如果委派者的密钥在签署委派之后被攻陷，该委派在到期前仍然有效。生产环境中，被攻陷的代理密钥应触发对所有以该密钥为根的委派进行级联吊销。SDK 在运营层面实现了级联吊销，但该机制在协议规范中未被形式化。

社会工程

信任谱系中的人类可能被欺骗去创建本不会创建的委派或约束。EATP 治理技术链条，但无法治理其中的人。

跨组织信任

SDK 提供了跨组织信任交换的互操作机制：用于可移植信任谱系表示的 W3C 可验证凭证、用于跨域代理身份的去中心化标识符，以及用于代理网络间能力卡交换的 Google A2A 协议集成。这些格式使组织 A 可以把 EATP 信任谱系导出为 W3C VC，组织 B 可以独立验证。

仍未规定的是联邦治理层：组织在大规模建立相互信任时所需的双边协议、信任解析策略与密钥发现协议。互操作底座已存在；跨组织边界运营该底座的治理框架则被推迟到未来工作。

跨组织信任为推理轨迹引入了具体挑战。当信任谱系跨越组织边界时，可能适用相互冲突的机密性策略：组织 A 可能将推理分级为 confidential，而组织 B 的合规要求披露。预期有三种解决方法：（1）最高分级胜出，把推理轨迹分级为两者之高；（2）由发起方控制，由发起组织的分级决定；（3）双边协议，组织间在联邦安排中协商分级处理。该协议的设计原则是「机密性在导入时只能被收紧，永远不能放松」，与治理委派链的约束收紧原则一致。完整的跨组织机密性协商协议被推迟到未来工作。

推理轨迹的完整性

推理轨迹记录的是某项决策陈述的理由，而非决策本身的质量。代理可以记录天衣无缝的推理，仍然作出错误的判断。事后合理化（在决策已经作出之后才写出令人信服的理由）是一项现实风险，结构性验证可以缓解，但无法消除。

推理轨迹采用双重绑定签名模型：reasoning_trace_hash 被纳入父记录的签名负载中，把推理在创建时与委派绑定。替换推理轨迹会使父签名失效，从而防止同一签名者进行替换。然而，被授权的签名者总可以以不同推理创建一条新的委派记录，这是任何由获授权方颁发记录的系统都具有的性质，不属于协议层漏洞。需要检测未经授权再委派的组织，应实施仅追加存储，并监控带有不同推理的重复委派。

REASONING_REQUIRED 约束要求的是存在，不是质量。一条最小化的推理轨迹（例如一个词的 decision 与 rationale）即可满足协议层检查。有意义的质量执行，例如最小字段长度、非空证据、实质性理由，是部署的责任。出于监管合规使用 REASONING_REQUIRED 的组织，应在协议层之上实施内容质量校验。

机密性分级体系（PUBLIC 至 TOP_SECRET）是由协作系统执行的咨询性分级，而非协议层的加密强制。SECRET 与 TOP_SECRET 要求静态加密，这是部署责任，不是协议保证。在诉讼中，详细的推理轨迹是可被取证的记录；组织必须在合规收益与对方律师可获取该推理所带来的法律风险之间权衡。

形式化验证

协议的约束逻辑尚未经形式化验证。尽管设计较为简洁（单调约束收紧、哈希链接的审计链），但未产生关于正确性的形式化证明。安全关键领域的生产部署应委托独立的形式化分析。

为何开放标准与开源至关重要

在这里，机构性论证转化为经济性论证。

企业 AI 信任基础设施不能是专有的。如果治理 AI 问责的协议归单一供应商所有，则使用它的每个组织都依赖于该供应商的存续、善意与商业决策。那不是信任基础设施，那是披着治理外衣的供应商依赖。

EATP 规范以 CC BY 4.0 发布。任何人都可以阅读、实现、扩展或构建竞争性实现。参考实现以 Apache 2.0 发布。任何人都可以使用、修改或在其上构建商业产品。Apache 2.0 许可证文件位于项目仓库（https://github.com/terrene-foundation/）：永久、不可撤销，并依其第 3 节包含自动专利授予。

为何选择这种结构而非纯粹的专有？ 因为信任基础设施的经济学不同于应用软件。信任基础设施通过广泛采纳创造价值。被一个组织使用的信任协议价值有限；被整个行业使用的信任协议则是关键基础设施。专有归属限制采纳；开放标准则加速采纳。

没有什么比 Apache 2.0 许可证就在仓库里更具说服力。这是可获得的最具体的信任信号：不是承诺、不是治理结构、不是未来意向，而是已经生效的法律工具。

监管对齐

EATP 被设计为支持但不保证与新兴 AI 治理框架的合规。

欧盟 AI 法案

要求	条文	EATP 支持
人类监督	第 14 条	信任姿态支持渐进式人类介入
风险管理	第 9 条	约束包络编码风险边界
记录留存	第 12 条	审计锚维持完整的行为记录
透明度	第 13 条	信任谱系使授权可见
问责	第 26 条	委派链识别负责的人类

上述条款适用于法规所定义的「高风险 AI 系统」。具体部署是否构成高风险取决于用例。组织应取得独立法律评估。

NIST AI 风险管理框架

在较高层面，EATP 映射到 NIST AI RMF 的四项功能：治理（Govern，起源记录确立组织治理）、映射（Map，能力证明描述代理功能）、度量（Measure，审计轨迹提供性能证据）、管理（Manage，约束包络实施风险控制）。该映射是提示性的而非精确对应；NIST 的功能比任何单一协议操作都更宽泛。

NIST 框架对有据可查的授权链、风险边界与可审计决策记录的强调，与 EATP 的五要素在结构上对齐。EATP 是 NIST 推荐治理路径的一种具体协议实现。

行业标准

EATP 的设计旨在补充 SOC 2 审计要求、ISO 27001 信息安全控制以及 GDPR 数据处理问责义务。

可追溯性的区分

有一项区分必须以绝对清晰加以表述，因为弄错它会颠覆整个论题。

EATP 提供可追溯性，而非问责。

可追溯性是把任意 AI 行为通过一系列委派追溯回人类授权的能力。EATP 提供这一点。

问责则要求人类理解 AI 做了什么以及为何这样做、评估在情境下该行为是否适当，并对其授权的 AI 行为之后果承担责任。EATP 不提供这些。任何协议都无法提供。

可追溯性是问责的必要条件，但不是充分条件。它提供证据基础：谁授权了什么、在何种约束下、产生了什么结果。组织是否构建出把可追溯性转化为实际问责的实践，是组织问题，而非技术问题。

EATP 提供基础设施。问责要求人类去使用它。

安全建议

对于评估或实施 EATP 的组织：

加密最低要求：使用 SHA-256 进行哈希；使用 Ed25519 进行签名；为起源与委派签名密钥使用 HSM（硬件安全模块）存储。规范与参考 SDK 仅使用 SHA-256 与 Ed25519。如组织策略需要，实现可改用 SHA-3 或 ECDSA P-256，但与参考 SDK 的互操作性要求 SHA-256 与 Ed25519。

参考 SDK 通过 PyNaCl 使用 Ed25519 进行所有签名与验证操作。提供密钥生成、序列化与管理。生产部署应评估默认密钥存储（文件系统或 PostgreSQL）是否满足其安全要求，或是否需要 HSM 集成。

生产实现应接受独立安全审查（Anderson，2020）。协议规范描述架构，并不验证具体实现。

已考虑的其他方案

学术诚实要求承认还考虑过哪些方案以及为何被搁置。

基于行为的信任：根据观察到的行为而非预先建立的链条来信任代理；无法确立初始问责，且可被规避。

基于联盟的验证：由多个独立方对每项行为进行验证；增加的延迟与协调复杂度，对企业用例可能超过其安全收益。

基于结果的问责：以结果而非授权来评判行为；只能事后回顾，并产生扭曲的激励。

基于保险的治理：让保险人为 AI 风险定价并设定要求；要求 AI 责任市场存在，而该市场尚未成形。

监管授权：等待监管者定义所需治理；意味着在监管落后于技术之时无治理地运行。

我可能低估了联邦化信任模型、基于能力的安全、持续学习约束以及去中心化自主治理。这些替代方案值得社区继续探究。

这为何重要

AI 时代不是要求组织把同样的事做得更快。它要求组织做根本不同的事。问题不是「我们如何把流程自动化？」，而是「我们如何构建使 AI 驱动的运营值得信任、可被问责、具有经济价值的机构性结构？」

EATP 处理这一问题中的一个部分：把自主 AI 行为连回人类授权的信任基础设施。它不是完整答案，而是若无之则其余答案无从构建的证据基础。

问责缺口是真实的。组织正以变通方法填补它：审批队列、审查委员会、与采纳 AI 的初衷相违背的限制性政策。这些变通无法规模化。终有一刻，组织必须在有意义的 AI 自主与有意义的人类问责之间作出选择。EATP 的论题是：这是一个伪选择。如果你建立了正确的基础设施，二者可以兼得。

该论题是否成立是一个实证问题。如果基于约束的验证被证明不充分，即组织一致发现约束合规与实际问责之间的差距无法由运营实践弥合，则该论题失败。如果信任谱系管理（密钥管理、约束工程、审计存储）的开销超过其带来的治理价值，该论题也将失败。这种对可被检验的承诺，正是把一种框架与一份销售推销区分开来的所在。

与 Kailash 的关系

EATP 定义开放标准。Kailash 是开源参考实现，由 Terrene Foundation（泰睿基金会）以 Apache 2.0 许可发布。

整个技术栈被设计为：让具备深入领域专长的小型团队也能构建出企业级质量的 AI 产品，这是 AI 时代根本性改变企业软件创建经济学这一更广洞见的结果。预制构件、开放标准与 AI 协助开发，意味着以往需要企业级预算的事项，现在对任意规模的组织都触手可及。

两项专利申请正在审查中（PCT/SG2024/050503 与 P251088SG；已收到正面 IPRP，目前在新加坡与美国进入国家阶段；尚未授予专利）。依据 Apache 2.0 第 3 节，参考实现的所有用户均获得永久、免版税的专利许可，附用户发起专利诉讼时的防御性终止条款。作者承诺：若 Apache 许可证第 3 节中的 Apache 2.0 专利授予被收窄、撤销或附加额外限制，本组申请中的全部专利权利要求将不可撤销地奉献给公众。

EATP 作为标准的价值并不依赖任何单一实现。

参考文献

基础性系统

Dennis, J. B., & Van Horn, E. C. (1966). Programming Semantics for Multiprogrammed Computations. Communications of the ACM, 9(3), 143-155.
Blaze, M., Feigenbaum, J., & Lacy, J. (1996). Decentralized Trust Management. Proceedings of the 1996 IEEE Symposium on Security and Privacy, 164-173.
Blaze, M., Feigenbaum, J., Ioannidis, J., & Keromytis, A. D. (1999). The KeyNote Trust-Management System, Version 2. IETF RFC 2704.
Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., & Ylonen, T. (1999). SPKI Certificate Theory. IETF RFC 2693.
Haber, S., & Stornetta, W. S. (1991). How to Time-Stamp a Digital Document. Journal of Cryptology, 3(2), 99-111.
Merkle, R. C. (1980). Protocols for Public Key Cryptosystems. Proceedings of the IEEE Symposium on Security and Privacy, 122-134.
Miller, M. S., Yee, K.-P., & Shapiro, J. (2003). Capability Myths Demolished. Technical Report SRL2003-02, Systems Research Laboratory, Johns Hopkins University.
Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., Vrable, M., & Lentczner, M. (2014). Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. Proceedings of the 2014 Network and Distributed System Security Symposium (NDSS).
Pang, R., Caceres, R., Burrows, M., Chen, Z., Dave, P., Germer, N., Golynski, A., Graney, K., Kang, N., Kissner, L., Korn, J. L., Parmar, A., Richards, C. D., & Wang, M. (2019). Zanzibar: Google’s Consistent, Global Authorization System. Proceedings of the USENIX Annual Technical Conference (ATC), 33-46.
Cutler, J. W., Disselkoen, C., Eline, A., He, S., Headley, K., Hicks, M., Hietala, K., Ioannidis, E., Kastner, J., Mamat, A., McAdams, D., McCutchen, M., Rungta, N., Torlak, E., & Wells, A. M. (2024). Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization. Proceedings of the ACM on Programming Languages, 8(OOPSLA1). 另见 arXiv:2403.04651.

基础设施标准

IETF RFC 6749. The OAuth 2.0 Authorization Framework.
SPIFFE. Secure Production Identity Framework for Everyone. https://spiffe.io
UCAN Working Group. (2023). UCAN Specification v0.10.0. https://ucan.xyz
Biscuit. (2023). Biscuit Authorization Token Specification. https://www.biscuitsec.org
Cloud Native Computing Foundation. Open Policy Agent (OPA). https://www.openpolicyagent.org

同时代的 AI 代理信任协议

South, T., Marro, S., Hardjono, T., Mahari, R., Whitney, C. D., Greenwood, D., Chan, A., & Pentland, A. (2025). Authenticated Delegation and Authorized AI Agents. arXiv:2501.09674.
Goswami, A. (2025). Agentic JWT: A Secure Delegation Protocol for Autonomous AI Agents. arXiv:2509.13597.
Bodea, T., Misono, M., Pritzi, J., Sabanic, P., Sommer, T., Unnibhavi, H., Schall, D., Santos, N., Stavrakakis, D., & Bhatotia, P. (2025). Trusted AI Agents in the Cloud. arXiv:2512.05951.
Zhu, G., Wang, C., Wang, Z., Li, Z., & Li, Q. (2026). OpenPort Protocol: A Security Governance Specification for AI Agent Tool Access. arXiv:2602.20196.

治理框架

European Union. (2024). Regulation (EU) 2024/1689 (AI Act).
National Institute of Standards and Technology. (2023). AI Risk Management Framework (AI RMF 1.0).
Irving, G., Christiano, P., & Amodei, D. (2018). AI Safety via Debate. arXiv:1805.00899.
Anderson, R. (2020). Security Engineering. 3rd Edition. Wiley.

配套论文

Hong, J. (2026). “Constraint Theater: Governance Without Wealth Effects.” Submitted to American Economic Review. 理论基础；EATP 实现五项机构性前提中的归因机制。
Hong, J. (2026a). “CARE: A Core Thesis.” White Paper Series, Version 2.1. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/CARE-Core-Thesis.pdf。配套论文，提供 EATP 所运营的治理哲学框架。
Hong, J. (2026c). “CO: A Core Thesis.” White Paper Series, Version 1.1. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/CO-Core-Thesis.pdf。配套论文，定义构建人机协作的领域无关方法论。
Hong, J. (2026d). “COC: A Core Thesis.” White Paper Series, Version 1.1. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/COC-Core-Thesis.pdf。CO 在软件开发上的领域应用。
Hong, J. (2026e). “The Constrained Organization: An Organizational Model for Enterprise AI Governance.” White Paper Series, Version 1.0. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/Constrained-Organization-Thesis.pdf。配套论文，论及面向 AI 治理责任承担的组织设计。
Hong, J. (2026f). “PACT: Principled Architecture for Constrained Trust — A Core Thesis.” White Paper Series, Version 0.8. Terrene Foundation. https://github.com/terrene-foundation/publications/blob/main/PACT-Core-Thesis.pdf。配套论文，论及可问责 AI 委派的组织架构。

关于本文如何产生的说明

本文是用其所描述的过程写就的。

初稿由一组 AI 代理生成：

研究分析代理探索知识库与源代码仓库，撰写结构化草稿，并将主张与锚点文档进行交叉核对。
一个独立的对齐 - 批评代理对输出进行红队测试，识别出八处问题，包括事实错误、过度声明以及与源材料的不一致。
一个辩论 - 专家代理挑战草稿的论点，并标记不可验证的主张。

作者主导每一轮迭代。指示包括：

删除无法验证的主张
移除对尚不存在结构的引用
把披露简化为朴素事实
为非技术读者解释技术术语
确保本文读起来像一份标准提案，而不是营销

作者在过程中对语气、措辞与实质进行了直接编辑。多轮修订接续进行，每一轮都缩小代理产出与作者所判断的「诚实而有用」之间的差距。

AI 代理起草。作者定义边界、评估输出、捕捉代理遗漏之处，并决定保留什么。这就是「人在回路之上」的实践，不是理论模型，而是产生本文的过程。

所用工具是 Claude Code（Anthropic）以及用于研究、对齐检查与对抗性审查的专用子代理。完整对话历史，包括每条指令、每次纠正以及作者拒绝的每段内容，皆保存在项目仓库中。

本文为 Hong（2026b），衍生自 Hong, J.（2026）。“Constraint Theater: Governance Without Wealth Effects.” 中的理论基础。EATP 实现了被列为五项机构性前提中第一项的「归因机制」。另见：Hong, J.（2026a）。“CARE: A Core Thesis”，关于治理哲学；Hong, J.（2026c）。“CO: A Core Thesis”，关于方法论；Hong, J.（2026d）。“COC: A Core Thesis”，关于开发方法论；Hong, J.（2026e）。“The Constrained Organization”，关于机构设计；Hong, J.（2026f）。“PACT: A Core Thesis”，关于组织架构。

速查

信任谱系链的五要素

起源记录：组织层面的信任根；人类高管承诺承担 AI 治理问责
委派记录：带约束收紧的权限传递；委派只能收窄，永远不能扩大。可选的推理轨迹记录委派为何作出
约束包络：五维操作边界（财务、运营、时间、数据访问、通信）
能力证明：关于代理获授权能力的签名声明；防止能力漂移
审计锚：可检测篡改的执行记录；每个锚对前一个进行哈希，构成可验证链条。可选的推理轨迹记录代理为何选择此项行为

验证梯度

自动批准：在所有约束内；执行并记录
标记：接近边界；执行并标记以供审查
暂留：越过软性限制；排队等待人类批准
阻止：越过硬性限制；拒绝并给出解释

五种信任姿态

伪代理：无自主性；人在回路中
受监督：低自主性；人在回路中
共同规划：中自主性；人在回路之上
持续洞察：高自主性；人在回路之上
完全委派：完全自主性；人在回路之外（远程监控）

关键区分

可追溯性不是问责：EATP 提供可追溯性；问责需要组织实践
推理轨迹是理由，不是证明：它们记录陈述的理由，而非决策质量；事后合理化仍是风险
约束规避无法被防止：只能被检测、被追溯，并通过持续的人类监督加以缓解
性能数字是设计目标：不是基准测试；实际性能取决于实现

版本历史

版本	日期	变更
1.0	2026 年 1 月	初版论文：五要素、信任谱系链、约束维度、验证梯度
2.0	2026 年 2 月	信任姿态形式化（5 级递进）。双重绑定签名模型。诚实局限部分扩展
2.1	2026 年 3 月	SDK 与论文对齐（ConstraintType、TrustPosture 枚举重命名）。术语一致性强化
2.2	2026 年 3 月	带双重绑定加密签名的结构化推理轨迹。REASONING_REQUIRED 约束类型。机密性分级。验证梯度集成（QUICK 忽略 → STANDARD 告警 → FULL 失败）