安全模型

信任边界

信任边界沿 OpsKeeper 控制平面划界。Worker、Webhook、插件端点都在边界外。每一处跨越都要经过鉴权和审计。

• 入站：HTTP API（Bearer JWT）、MCP 插件（Bearer + HMAC）、Webhook（HMAC 签名）。
• 出站：默认只读；可变更调用需要带 seal 的提案。

安全级别

每个 Worker 声明一个 safety_level：

• L0 —— 只读，无需提案。例子：alerter、investigator、critic、reviewer、verifier。
• L1 —— 标注状态，无外部副作用。例子：reporter（只写报告，不碰基础设施）。
• L2 —— 提议但不执行。规划类 Worker 使用。
• L3 —— 配合提案 + 人工审批人做可变更操作。当前唯一的 L3 Worker 是 repairer。

Manager 拒绝派发安全级别高于阶段允许值的 Worker。

提案契约

提案就是契约。控制平面仅在下列条件全部满足时才派发恢复：

1. 资源、命令、payload 哈希与审批完全一致。
2. 工具在 Worker 的 tool_allowlist 中。
3. 提案上有人工审批人签名。
4. 提案未过期（默认 TTL：30 分钟）。

否则调用默认拒绝，并追加一条审计事件。

phase: approved
proposal:
  incident_id: INC-PG-POOL-001
  worker: repairer
  blast_radius: pg.connection_pool / one-db
  ttl: 30m
guard:
  required_approval: human
  exact_match: [resource, command, payload_hash]
  tool_allowlist:
    - execute:approved-only
audit:
  on_dispatch: ledger.append
  on_complete: ledger.seal

审计账本

每一次派发和完成都 append 到 loop_event_log，数据库将其强制为 append-only（触发器拒绝 UPDATE/DELETE；更正是新事件）。此外，每个变更提案的跃迁都会 append 到 chat_proposal_audit，一条 SHA256 哈希链：

hash_n = SHA256(prev_hash || canonical_json(payload) || proposal_id || action)

仓库内置校验器按 created_at 顺序遍历整条链、重算每个哈希，并报告第一条被篡改的记录。把每日链根锚定到外部透明日志属于 roadmap 项，尚未发布。

威胁模型

以下缓解措施是 Manager 的一部分，不在 prompt 里。即使某个 Worker 彻底被攻陷也仍然生效。

漏洞披露

披露时间表与联系方式见仓库里的 SECURITY.md。