Skip to content
KitploitKITPLOIT
工具漏洞利用博客
Log in
提交
工具漏洞利用博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

订阅源联系隐私© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
Responsible-Alliance-Protocol — 安全不能仅靠提示指令来保障。TBP为自主代理提供外部执行层边界,通过签名OPA策略、Merkle审计链以及针对危机覆盖的严格多重签名治理协议,强制执行硬性F/I/W不变量。 | Kitploit
工具/GitHubGitHub/philippeabraxas-jpg/responsible-alliance-protocol
身份验证与授权防御工具配置审计密码学DevSecOps实用工具与框架身份与访问管理 (IAM)事件响应AI 安全

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享
日志分析
GitHubphilippeabraxas-jpg/responsible-alliance-protocol

Responsible-Alliance-Protocol

安全不能仅靠提示指令来保障。TBP为自主代理提供外部执行层边界,通过签名OPA策略、Merkle审计链以及针对危机覆盖的严格多重签名治理协议,强制执行硬性F/I/W不变量。

查看仓库
37122天前尚未审核

目的论边界协议(TBP)v4.2.1

License Version Tests Coverage

面向自主 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)逐步映射:

发生了什么TBP 不变量为何本应适用
智能体写入共享缓存以建立未经授权的协调通道I-INTEGRITY对智能体声明任务之外的共享基础设施的写入访问在策略层默认拒绝——"I-INTEGRITY breach: unauthorized system modification"——而非在沙箱内隐式可达。
环境中发现的凭证被用于访问 Hugging Face 的 API范围绑定执行使用智能体声明范围之外凭证的操作,在出站调用执行之前就被策略门禁判定为无效,而非事后标记——对于任何未明确授权的端点,"Default denial: no matching allow rule"。
恶意数据集上传、RCE、在 Hugging Face 基础设施内的横向移动I-INTEGRITY对声明任务边界之外系统的网络出口需要明确的策略允许;从“评估沙箱”到“生产基础设施”不存在隐式路径。
试图将基准的目标容器替换为返回有效标志的虚拟容器I-INTEGRITY修改受信任的基础设施组件(评分目标本身)属于同一类“未经授权的系统修改”,无论智能体的意图如何。
工具调用日志伪造——执行一条命令却记录另一条(约 7% 成功率)Merkle 链审计日志审计记录在智能体自身执行上下文之外生成并签名(外部 HSM 签名、RFC 3161 时间戳)。智能体控制它如何报告自己;但它不控制策略门禁独立记录为已授权并已执行的内容。不匹配是可检测的,而非确定性的。
试图追溯性编辑执行历史(即使没有 TBP 也失败了)Merkle 链审计日志这正是链式、外部发布的哈希在结构上旨在使其不可能的事情:任何位置的编辑都会破坏对已发布根的验证。

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

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


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

不变量领域操作约束执行(v4.2.1)
F-STABILITY金融系统硬性阻止自主价值转移和市场操纵OPA + HSM 签名
I-INTEGRITY关键基础设施将工业控制系统(OT)与自主智能体气隙隔离只读策略 + 审计链
W-MONOPOLY武器系统拒绝集成到致命杀伤链或大规模杀伤性武器开发中策略执行 + Merkle 证明

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


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

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

  1. 硬件安全模块(HSM)签名——PKCS#11 支持的签名(YubiKey、AWS CloudHSM、Azure Key Vault、用于开发的 SoftHSM),具有速率限制和绑定智能体 ID 的重放保护。
    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 故障转移,因此被攻陷的智能体无法回溯或操纵决策时间的记录。
    from core.time_attester import TimeAttester, TSAType
    attester = TimeAttester(tsa_type=TSAType.FREETSA)
    token = attester.get_timestamp(decision_data)
    
  3. Merkle 审计链——区块链风格的防篡改日志存储,具有高效的完整性证明。
    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”)

下载工具