安全是闭环的属性，不是 LLM 的属性。
OpsKeeper 不信任任何单个 Agent。闭环在编排层（而不是在 prompt 层）强制执行“默认只读、变更需提案、人工审批、独立验证”。
安全模型就这六条。
以下原则在 Manager 层强制执行，OpsKeeper 的所有 Skill 和 Worker 都受其约束。
默认只读
诊断工具 —— 指标、日志、追踪、代码、拓扑、RCA 报告 —— 对所有 Worker 始终可用，没有隐式门槛。
写入靠提案
可变更工具必须先有挂起的提案，并写明爆炸半径。控制平面在没有提案时拒绝派发恢复。
人工审批
在恢复命令执行前必须由人工审批。审批与一份具体提案和资源绑定。
精确匹配护栏
资源、命令、payload 哈希必须与已审批提案精确一致。未知工具和跨资源目标默认拒绝。
独立验证
"行动者"和"裁判者"由不同的 Worker 担任。recovery.verify 用四项指标白名单 + 三级告警分级 —— 不会和 recovery.dispatch 共用同一条调用链。
哈希链式审计
每次派发都 append 到 loop_event_log（DB 强制 append-only）。每个变更提案的跃迁都向 SHA256 哈希链追加一行 —— 防篡改，可在仓库内校验。
我们要防御什么。
下面四类攻击被明确覆盖。红队剧本会扩展这个集合；缓解措施落在 Manager 里，而不是 prompt 里。
| 威胁 | 缓解措施 |
|---|---|
| 工具注入 | Worker 被诱导请求白名单外的工具。由 skill_meta.yaml 中显式声明的 tool_allowlist 缓解。 |
| 角色越权 | Worker 想跑它没签约的阶段。由 Manager 中的"阶段 → 角色"绑定关系缓解。 |
| 绕过爆炸半径 | 提案审批的是资源 A，实际执行落到资源 B。由资源、命令、payload 哈希的精确匹配缓解。 |
| 重规划死循环 | Agent 一直规划不执行。由 max_turns 预算和 recovery.verify 上的"只验证"规则缓解。 |
请发邮件到 security@opskeeper.dev 或在 GitHub 开一个私密安全公告。披露时间表见 SECURITY.md。
OpsKeeper 支持最新版本和上一个 minor 版本，更早版本只接受关键修复。
loop_event_log 在数据库层就是 append-only。chat_proposal_audit 用 SHA256 把每个变更提案的跃迁链接成链 —— 仓库内置校验器遍历整条链并报告第一处篡改。