TBP-NETWORK

目的论边界协议（TBP） 的网络级实现—— 对 AI 代理在网络上的行为进行经证实的治理，从单台机器到企业级部署，直至 WWW 规模。

« 现有的访问控制决定你是否能进入；TBP 决定你进入后可以做什么——并加以证明。我们治理的是能力，而非模型。 »

绝不通过信任建立伙伴关系——只通过经证实的握手。 这就是目标：实体间握手（规范 §3）让互不信任的实体能够相互证明策略、历史和存活状态。握手本身尚未构建（#33）。本仓库目前包含的是握手之前的内容以及它将依赖的基础——PEP、单元代理和注册表、NAC、监督、部署指南——这将 TBP 的治理从单台机器扩展到同一组织下的小型机器网络。

试一试：在三台机器上对 TBP 进行 DEV-TEST

非生产用途。 一次性密钥、可以丢弃的机器、无真实数据。它的存在是为了让你能在生产版本发布之前尝试攻破 TBP。

TBP-NETWORK 提供了一个简单的部署方案，用于在生产版本发布之前运行和攻击。三台机器，每台由一个脚本部署：M1 单元（brokerd 及其 OPA），M2 应用服务器（pepd 和一个小型应用），M3 一个代理。它测试整个系统是否正常工作——代理通过其证书注册、通过双向 TLS 做出决策、服务器检查令牌、服务器的态势由控制器治理——使用真实的二进制文件和真实的强制执行；只有密钥仪式被简化。一个单机变体让你可以单独查看单元。

一切都在 deploy/dev-test/ 中：每台机器的用途及原因、从全新 Debian 12 机器开始的精确步骤、要测试的场景、在哪里攻击、它能证明什么和不能证明什么——以及如何向我们发送你尝试的每个环境的数据和评论，我们期待收到。任何可利用的问题请通过 SECURITY.md 报告，而非公开 issue。

TBP 是什么——不是什么

TBP 不堵住每一个漏洞；它审计每一个漏洞。 这不是需要绕过的限制，而是创始假设（规范 §1："我们不堵住每一个漏洞；我们按影响对漏洞排序并成比例地缓解——治理是分配，而非完备"）。TBP 不是一个自给自足的安全系统——它不替代 SELinux、防火墙、IAM 或操作系统级沙箱，且按设计永远不会。它所做的更窄且不可协商：没有可加密证明的决策，任何受治理的操作都不会执行；任何决策——允许或拒绝——都不会逃脱审计链，不可证明且未被篡改。TBP 是部署已有强制执行栈之上的治理和证实层，而非其替代品。

TBP 限制多少是部署选择，而非协议属性。 在全部允许（监控模式，一切记录，什么都不阻止）和全部拒绝之间，存在一个完整的谱系，由单元加载哪些 OPA 规则包、它在哪个规模（见下文）运行，以及它将计划契约、法定人数和（计划中的）风险评分层推进多远所塑造（#177–#181）。个人实验室和受监管的生产单元可以在该谱系上非常不同的位置运行相同的协议，这是设计使然，而非缺口——参见下文"下一步计划工作"中为按规模管理控制台计划的规则包/态势预设。

在该谱系的任何位置，恰好有两件事不会改变：

1. 核心协议承载的三条不可克减的不变量—— F-STABILITY（无自主价值转移/市场操纵）、 I-INTEGRITY（无自主代理控制工业/OT 系统）、 W-MONOPOLY（不整合入致命杀伤链或大规模杀伤性武器开发）——参见 tbp4.2.1/README.md。 这些是事后撤销访问无法逆转不良行为的类别；任何部署态势、规则包或规模都不会放松它们。
2. 可证明的审计——某个操作发生了，且其记录未被篡改，这在构造上始终可证明（仅哈希叶子、Merkle 锚定链，§6.2），与加载在其上的策略有多宽松或严格无关。

其他一切——允许范围有多宽、操作员接受多少摩擦、哪些组合需要人工签名——都是复杂性、运营需求和特定部署实际能运行什么之间的选择，而非协议本身的属性。

关于语言的说明：参考规范现在是 docs/spec-en-v1.0.md（英文）——这是代码和审计应依据的文档。其版本号故意重置为 1.0：这是向可引用、有版本的文档的干净重启（§13："保守地版本化；变更通过签名的、经证实的转换"），而非工作笔记自身计数的延续——编号更高的工作笔记不是更新的文档。作者的工作笔记——更密集、更非线性，适合挖掘设计理由，但不应引用——以两种语言存在： docs/spec-v1.4.10.md（英文）和 docs/spec-v1.4.10.fr.md（原始法文）。 同一约定适用于整个仓库：每个最初以法文撰写的文档现在在其原始路径都有一个英文主版本，法文原件作为 <name>.fr.md 保留在旁边。术语表 （docs/glossaire.md）仍以法文为源（法文文档的 §14 是其术语的权威来源），并附有英文注释列以便阅读——这一点未变。

从这里开始

完整规范是 docs/spec-en-v1.0.md ——它是本仓库中任何设计或配置决策的权威来源。本 README 仅总结入门所需的内容；如有疑问，以规范为准。工作笔记 （docs/spec-v1.4.10.md，法文原件的英文翻译）在内容上并未被取代——它是同一协议，先在那里开发——但它不是今后可引用的参考。

阅读它的有用路标：

• §1 原则——十条不可协商的规则。
• §13 实施顺序——应遵循的顺序（HSM → OPA → PEP → NAC → 翻译器），以及试点 P1 的确切范围。
• §9.1 摩擦预算——决定 TBP 部署是否真正有效的延迟和仲裁率阈值；在每个配置决策中都要关注这些。
• docs/glossaire.md——每个概念一个规范术语，在本仓库的代码和文档中一致使用 （参见 CONTRIBUTING.md）。

与主 TBP 仓库的关系

协议本身——规范、正式原则、对抗性审计、核心实现（HSM 签名、Merkle 审计链、OPA 策略引擎）——位于 Responsible-Alliance-Protocol， 以 Apache 2.0 许可（开放），并作为 git 子模块以特定提交固定在本仓库的 tbp4.2.1/ 中——这是一个指针，而非分支：本仓库绝不是针对该代码提交 issue 或 PR 的地方，只能针对下面的网络推广部分。本仓库是同一协议的网络规模推广：NAC、本地 PEP、单元注册表（实体间握手是目标，尚未构建）—— 将 TBP 从单台受治理机器带到受治理网络所需的部件。截至本 通知，本仓库自身的代码也是 Apache 2.0（见下文许可）——与核心协议相同的许可，两个仓库一个许可，而非两个。它在初始试点阶段曾使用闭源许可；该阶段已结束。

保持子模块最新：tbp4.2.1/ 不会自行更新—— 将其升级到 Responsible-Alliance-Protocol 的更新提交是一个深思熟虑、经审查的操作（cd tbp4.2.1 && git checkout <commit> && cd .. && git add tbp4.2.1 && git commit），绝不自动。一个悄悄落后于上游安全修复的固定子模块比没有子模块更糟——像对待任何其他依赖更新一样谨慎地升级它，并先检查核心仓库自己的变更日志。

合规映射

TBP 已对照 21 个外部安全、AI 治理和监管框架逐控制项检查——不是作为营销声明，而是作为诚实的差距分析，说明哪些已覆盖、哪些部分覆盖、哪些在结构上超出 TBP 的范围。完整分解（每个标准一个文件，附有每个 ✅ 背后确切机制的引用）位于 tbp-compliance/；此表是摘要。