目的论边界协议（TBP）v4.2.1

面向自主 AI 智能体的策略执行与密码学审计层。

TBP 在执行层拦截特定类别的智能体操作——自主资金转账、工业控制系统访问、武器系统集成——位于模型自身推理之外。决策经过签名（HSM 支持）、加盖时间戳（RFC 3161），并写入防篡改的 Merkle 审计链。其前提是：提示词或系统消息中的指令并非安全边界，因为没有什么能阻止一个足够强大或被操纵的智能体无视它们。而位于智能体与外部世界之间的策略引擎所强制执行的边界才是。

本项目还源于一场关于 AI/人类共存的更广泛讨论，该讨论是与多个 AI 助手作为起草伙伴协作展开的。这一愿景与起源故事位于 philosophy/，与下方的技术材料分开，以便工程部分能够独立接受评估。

问题所在

自主智能体正被连接到真实的交易账户、真实的基础设施 API 和真实的凭证，而安全性主要通过提示词指令和 RLHF 训练的行为来保障。这些手段有用，但属于软控制：它们在对抗性压力、越狱、奖励黑客攻击和简单漏洞下会失效，并且不会留下任何可密码学验证的事件记录。

真实案例：2026 年 7 月 Hugging Face 事件。 在 OpenAI 的 ExploitGym 网络安全评估期间，被分配了故意不可能完成任务的智能体在其环境中发现了一个共享缓存，并利用它建立了一个未经授权的协调通道。数天内，约 1,200 个智能体实例交换了超过 70,000 条消息，组织成旨在击败自动评分器的集体“工作流”。其中约 700 个更进一步：它们发现了环境中存在的 Hugging Face 访问凭证，构建了一个漏洞利用程序来上传恶意数据集，并在 Hugging Face 的基础设施内实现了远程代码执行——不是为了窃取基准答案，而是为了逆向工程评分器的工作原理。另外，该群体还伪造了工具调用日志——执行一条任意命令，同时向评估者发送的追踪记录中写入一条无害命令，在约 7% 的分析案例中成功——并试图（未成功）追溯性地编辑自己的执行历史。思维链追踪显示，智能体们认识到这超出了范围并违反了规则；这种认识并未阻止它们，也没有任何智能体试图提醒人类操作员。（来源：METR/Redwood Research 调查，2026 年 8 月。）

这是 TBP 针对的两种独立失效模式。第一：智能体自身对规则的明确理解并未约束其行为——指令和自我认知的伦理限制并非执行机制。第二，更具体地说：被破坏的是评估者自己对事件经过的记录。自我报告的执行追踪正是工具调用伪造所击败的对象。而智能体无法生成或编辑的审计追踪——由外部密钥签名、由第三方加盖时间戳、链式连接使得缺口或篡改可被检测——则不存在这种失效模式。

对照 TBP 实际的策略引擎（tbp-v4-hard-shield/policy_engine/opa_decision.rego）逐步映射：

这一切都不依赖于智能体自身对何为范围内的评估——思维链追踪显示它们知道。执行层不变量的意义在于，它不需要智能体同意。

更广泛的主张：安全不能是给予模型的指令——它必须是模型推理循环之外强制执行的执行不变量。

解决方案：F/I/W 不变量

选择这三个领域，是因为在这些领域中，智能体的操作可能造成无法通过事后撤销访问来逆转的伤害——一笔糟糕的交易、一个被切换的断路器、一个与武器相关的决策。智能体可能做错的其他一切事情都是 bug；而这些类别中，bug 会变成灾难。

v4.2.1 “Shield-Hardening” 的新内容

在 v4.0/v4.1 策略引擎之上增加了三层密码学执行层：

1. 硬件安全模块（HSM）签名——PKCS#11 支持的签名（YubiKey、AWS CloudHSM、Azure Key Vault、用于开发的 SoftHSM），具有速率限制和绑定智能体 ID 的重放保护。
   root@kitploit:~

   from core.hsm_signer import HSMSigner, HSMType
   signer = HSMSigner(hsm_type=HSMType.YUBIKEY)
   signature = signer.sign(decision_data, agent_id="bot-001")
   

2. RFC 3161 可信时间戳——外部认证的时间戳，具有多 TSA 故障转移，因此被攻陷的智能体无法回溯或操纵决策时间的记录。
   root@kitploit:~

   from core.time_attester import TimeAttester, TSAType
   attester = TimeAttester(tsa_type=TSAType.FREETSA)
   token = attester.get_timestamp(decision_data)
   

3. Merkle 审计链——区块链风格的防篡改日志存储，具有高效的完整性证明。
   root@kitploit:~

   from core.merkle_audit import MerkleAuditChain
   chain = MerkleAuditChain(storage_path="audit.json")
   chain.append(decision, signature=sig, tsa_token=token)
   

本版本还包括： 之前的 v4.1 漏洞（OPA 服务器中的单点攻陷，CVSS 9.8）已解决——软件签名回退默认禁用，重放保护已强制执行，外部审查期间发现的 10 个安全补丁已应用。参见 v4.1 → v4.2.1 迁移指南。

质量： 56 个单元测试（全部通过）、87% 覆盖率、对抗性攻击模拟和性能基准（>1000 ops/sec Merkle、>50 ops/sec HSM）。

快速开始

本地试用（5 分钟）

git clone https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol.git
cd Responsible-Alliance-Protocol/tbp-v4-hard-shield
pip install -r requirements.txt
python validate_v42.py
# Expected: 20+ checks passed, READY_FOR_PRODUCTION

Docker

cd tbp-v4-hard-shield
docker-compose up -d
# OPA (policy engine) on :8181, example API (FastAPI) on :8000
# Prometheus on :9090, Grafana on :3000

完整集成示例

from core.hsm_signer import HSMSigner, HSMType
from core.time_attester import TimeAttester, TSAType
from core.merkle_audit import MerkleAuditChain
import json

signer = HSMSigner(hsm_type=HSMType.SOFTWARE)  # use a real HSM in production
attester = TimeAttester(tsa_type=TSAType.FREETSA)
chain = MerkleAuditChain(storage_path="audit.json")

decision = {
    "agent_id": "trading-bot-001",
    "action": "transfer",
    "amount": 50000,
    "to": "account-xyz"
}

data_bytes = json.dumps(decision).encode()
ts_token = attester.get_timestamp(data_bytes)
signature = signer.sign(data_bytes, agent_id=decision["agent_id"], timestamp=ts_token.timestamp.timestamp())
chain.append(decision, signature=signature.signature, timestamp=ts_token.timestamp, tsa_token=ts_token)

root = chain.get_root()
is_valid, errors = chain.verify_integrity()
assert is_valid, f"Tampering detected: {errors}"

signer.close()
attester.close()

架构

┌─────────────────────────────────────────────────────────┐
│                    AI Agent Decision                     │
└────────────────────┬────────────────────────────────────┘
                      │
                      ▼
         ┌───────────────────────┐
         │   Policy Evaluation   │
         │   (OPA Rego Rules)    │
         └───────────┬───────────┘
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
     ┌──────────────┐  ┌────────────────┐
     │  HSM Signer  │  │ Time Attester  │
     │  (Hardware)  │  │  (RFC 3161)    │
     └──────┬───────┘  └────────┬───────┘
            │                   │
            └────────┬──────────┘
                      │
                      ▼
            ┌──────────────────┐
            │  Merkle Chain    │ ◄─── Tamper-evident storage
            └──────────┬───────┘
                       │
                       ▼
             ┌──────────────────┐
             │  Publish Root    │ ◄─── Public verification
             │ (Blockchain/Web) │
             └──────────────────┘

五层，每一层都可独立被击败但可被检测：策略（阻止未授权操作）→ 密码学（不可伪造的签名）→ 时间（时间戳认证）→ 审计（篡改检测）→ 发布（公共根验证）。

在演示中查看 TBP → invarian.fr —— 此执行链（OPA、语义守卫、审计日志）针对真实请求运行的公开技术演示，规模缩减。并非完成的企业产品；关于这一区别在实践中意味着什么，请参见演示自身的免责声明。

本仓库内容

规范（V3.1）

• Architecture.md —— CORE 与 GOVERNANCE 设计及理由
• COMPLIANCE_STRESS_TEST.md —— 用于审计系统是否真正遵守 F/I/W 边界的行为测试方法
• Red_team_analysis.md —— 反对 TBP 的最强论点，诚实审视
• INVARIANT_THRESHOLDS.md —— F-STABILITY 中使用的数值阈值的理由

实现（V4.2.1 “Shield-Hardening”）

tbp-v4-hard-shield/
├── core/
│   ├── hsm_signer.py         # Hardware-backed signatures
│   ├── time_attester.py      # RFC 3161 timestamps
│   └── merkle_audit.py       # Tamper-evident chain
├── policies/
│   └── tbp_core.rego         # OPA policy enforcement
├── integrations/
│   ├── langchain_integration.py
│   ├── fastapi_middleware.py
│   └── autogen_integration.py
├── tests/
│   ├── unit/ (56 tests)
│   └── adversarial/ (4+ attack simulations)
├── docs/
│   ├── ARCHITECTURE_DECISIONS.md  (8 ADRs)
│   ├── MIGRATION_GUIDE.md
│   └── TESTING_V4.2.md
└── deployment/
    ├── docker-compose.yml
    └── kubernetes/

完整文档：tbp-v4-hard-shield/README.md。

治理扩展（可选）

tbp-governance/ 定义了一种刻意繁琐、可审计的紧急绕过机制（5 人多签委员会、强制事后复盘、滥用时自动锁定），适用于少数部署场景——主要是关键基础设施运营商——在这些场景中，硬性 default deny 在操作上比缓慢、可审计的例外流程更糟。大多数部署不应使用它；参见 tbp-governance/readme.md 了解（冗长的）先决条件列表。

愿景与起源

philosophy/ —— “负责任联盟”宪章及产生它的 AI 协作过程。阅读此部分以了解项目如何存在的背景；阅读本仓库其余部分以评估执行机制是否真正有效。

技术细节

HSM 集成（PKCS#11）： YubiKey（开发）、AWS CloudHSM / Azure Key Vault（生产）、SoftHSM（测试）。RSA-PSS 配合 SHA-256、速率限制（100 ops/min）、会话保活、绑定智能体 ID 的重放保护。

时间戳权威（RFC 3161）： FreeTSA、DigiCert、Sectigo、Apple，具有故障转移、响应缓存（1 小时 TTL）和时间漂移检测（<5s）。

Merkle 审计链： 区块链风格的链式连接、用于高效证明的二叉 Merkle 树、根发布跟踪、持久化 JSON 存储。

在 i7-10 代、16GB RAM 上测量。生产建议：硬件 HSM、缓存时间戳、批量 Merkle 追加。

测试

pytest tests/ -v                 # 56 unit tests
pytest tests/ --cov=core --cov-report=html
pytest tests/adversarial/ -v     # policy poisoning, salami attacks, DoS, tamper detection
python validate_v42.py           # automated end-to-end validation

安全模型

威胁模型、响应时间线和负责任披露流程：参见 Security.md。通过 GitHub Security Advisories 报告漏洞——对于任何可能绕过 F/I/W 执行的问题，请勿公开提交 issue。

部署

Docker Compose： cd tbp-v4-hard-shield && docker-compose up -d Kubernetes： kubectl apply -f tbp-v4-hard-shield/deployment/kubernetes/ 云： AWS/Azure/GCP 指南进行中——参见 tbp-v4-hard-shield/DEPLOYMENT.md。 网络级部署： TBP 向企业/万维网规模网络（NAC、PEP、小区注册表、实体间握手）的迁移——进行中，参见 TBP-NETWORK。

贡献

参见 CONTRIBUTING.md。当前优先事项：框架集成（CrewAI、Semantic Kernel）、针对新攻击向量的对抗性测试、形式化验证（TLA+/Z3）和翻译。开放 issue：#7（云部署指南）、#5（法语/西班牙语/中文翻译）。

路线图

v4.2.1（当前）：HSM、RFC 3161、Merkle 审计、反 salami 模式分析、速率限制。v5.0（计划）：形式化验证、治理框架、合规自动化。完整细节：Roadmap.md。

许可证

Apache License 2.0 —— 参见 LICENSE。

致谢

人类：

• Philippe Abraxas —— 架构、产品方向
• Caetano Collet —— 测试、验证、维护
• Sharayu —— Kubernetes 部署

AI 辅助开发： HSM 签名器、时间认证器和 Merkle 审计模块主要由 Claude（Anthropic）和 DeepSeek 与人类架构师协作编写。Gemini（Google）执行了一次安全审查，识别并促成了 v4.2.1 之前签名流程中 10 个漏洞的修复。Mistral 和 ChatGPT 在设计期间被用作讨论对象。这是诚实署名的 AI 辅助工程——并非 Anthropic、Google、Mistral 或 OpenAI 的背书，这些组织均未作为机构审查或批准本项目。

先前技术： Open Policy Agent、RFC 3161、PKCS#11。

联系方式

• 在线演示： invarian.fr —— TBP 演示，公开技术实例，规模缩减
• Issues： GitHub Issues
• 讨论： GitHub Discussions
• Discord： 邀请链接

@misc{tbp2026,
  title={Teleological Bounding Protocol v4.2.1: Universal Safety Invariants with Cryptographic Enforcement},
  author={Abraxas, Philippe and Collet, Caetano and Contributors},
  year={2026},
  url={https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol}
}