单人创始人紧急接班：有限授权、Break-glass 与恢复交接

单人公司常把连续性简化成“合伙人知道密码管理器主密码”。这会制造两个相反风险：创始人只是飞行十小时，接班人却能永久转账和删库；真正住院时，备用邮箱、硬件密钥或云账号又恰好都依赖本人批准。文档能告诉人怎么做，却不能回答谁在什么条件下获得哪一项权力，以及本人恢复后如何证明临时权限已经全部消失。

Agent 委派合同约束机器子任务，编程 Agent 人工交接保存一次代码任务的上下文。本篇只治理自然人接替创始人的运营连续性：支付、域名、云资源、客户通知和安全处置仍由各系统执行，接班控制面只发放受限授权并保存接受证据。

发布不可变 continuityCharter.v1

创始人与治理见证人共同签署 founder.continuityCharter.v1。它列出业务服务分级、最大可容忍停机、接班人及替补、触发证据、确认 quorum、冷静期、每项能力的范围和额度、禁止动作、租约期限、续期方式、通知对象、恢复 owner 与章程过期日。银行转账、股权、生产部署、数据导出、公开声明不能归为一个模糊的 admin 权限。

schema: founder.continuityCharter.v1
charterId: company-continuity@5
successor: person:ops-primary
quorum: 2-of-3
activationDelayHours: 12
leaseHours: 24
capabilities:
  - service: cloud-production
    verbs: [restart, scale-within-limit, read-incident]
    deny: [delete-account, rotate-root, export-customer-data]
  - service: billing
    verbs: [view-failures, retry-approved-invoice]
    amountLimit: USD1000

NIST SP 800-34 Rev.1 将业务影响分析、恢复策略、计划测试和维护放在同一连续性周期中。小团队也应先确定哪些功能必须在 4 小时恢复、哪些可以停 72 小时，而不是默认复制创始人全部权限。章程引用每个服务的 runbook digest、联系人、依赖和最近演练 receipt；任一材料修改都产生新 generation，旧签名不能授权新能力。

凭证不写进章程。NIST SP 800-63B 对认证器生命周期、恢复与绑定有明确要求；实际能力应由支持独立主体、短期凭证和撤销的系统签发。无法细分权限的遗留服务使用托管 break-glass 包：加密材料由不同保管方分片，重组必须满足 quorum，并立即触发带外告警。OWASP Secrets Management Cheat Sheet 强调最小权限、轮换、过期和完整审计，密钥管理可落实日常生命周期；连续性流程不能借“紧急”把共享 root 密钥变成常态。

激活只有一个接受点

状态从 NORMAL 进入 UNREACHABLE_SUSPECTED，完成多通道联系和证据等待后进入 ACTIVATION_PENDING。证据不足是 DISPUTED，见证人不可达是 QUORUM_BLOCKED，不能由接班人自行解释为批准。唯一接受点是 quorum 对同一个 charter digest 和 activation nonce 签发 successorActivation.v1；控制面以 CAS 将状态推进到 ACTIVE_LIMITED 并签发首批能力租约。聊天消息、日历超时、拿到恢复码或成功登录都不算接受。

每个租约绑定 activation、主体、设备/认证器、service、verbs、金额或资源上限、有效期和 revocation generation。高风险动作再要求独立批准，禁止接班人扩大自己的权限、修改章程、替换见证人或延长总期限。每项有副作用操作还要先持久化 successorEffect.v1，用稳定 effect ID 绑定 activation、业务对象、操作语义、payload digest、provider 幂等范围和 PREPARED 状态。

真正发出外部调用前，执行器以 CAS 同时确认 activation 仍为 ACTIVE_LIMITED、租约未过期且 scope 匹配、revocation generation 未变化、effect 仍为 PREPARED，再推进到 DISPATCHING。恢复撤销在同一权威 gate 提升 revocation generation 并关闭 dispatch watermark，因此撤销与 dispatch 只能一方成功。调用超时或响应丢失进入 UNKNOWN_EFFECT，禁止换 effect ID 盲重发；优先用 provider operation ID、幂等键或一致查询取得 receipt 后对账。供应商不支持幂等或条件前置时，DISPATCHING 接受即越过可逆点，恢复流程只能等待确定结果或人工隔离，不能宣称已撤销。所有控制面事件写入独立审计目的地；云控制面审计完整性提供缺口和篡改检测，不能只依赖接班人有权删除的同一云账号。

创始人恢复后先进入 RECOVERY_PENDING，完成强认证和见证确认后提升 revocation generation，停止新租约并等待在途动作到达已知结果。随后状态为 HANDOFF_RECONCILING：逐项核对账单、部署、客户承诺、工单和凭证，接班人与创始人对同一 effect ledger 签字，才进入 CLOSED。争议或未知外部效果留在 RECOVERY_EXCEPTION，不能为了结束事件删除记录。生成式 AI 事故证据保全中的只追加证据和保全思路同样适用于人类接班期间的安全事件。

演练不可绕过真实失败条件

季度桌面演练之外，每年至少一次在隔离账户执行受限恢复：注入创始人手机与邮箱同时不可用、一名见证人拒绝签名、旧 charter 被重放、时钟偏移、硬件密钥遗失、租约服务部分失败、接班设备被撤销、云控制面返回未知、在恢复 CAS 前一毫秒发起扩容，以及恶意接班人尝试自增权限。系统必须把未知动作隔离到核验队列，并证明撤销与 dispatch 竞争只有一个胜者。

接受门要求所有 Tier-0 服务均有 owner、RTO、最新 runbook 和最近 12 个月演练 receipt；章程与实际能力差异为 0，未声明 verb 成功数为 0，quorum 绕过为 0，旧 generation 重放接受为 0。激活 p95 不超过预定 RTO 的 25%，租约过期或撤销后新成功调用为 0，审计事件可归属率 100%，恢复对账未决 Tier-0 效果必须为 0。任一越权动作直接判定演练失败，速度不能抵消权限缺陷。

上线先让系统只生成能力清单和差异报告，不接触真实凭证；下一阶段仅接入只读状态页和可重复的服务重启，再逐项扩大到有额度的操作。每一 cohort 保留原人工联系树和现有恢复路径，并通过 activation generation 开关暂停新租约。发现误激活、审计缺口或收权延迟时立即回退到 NORMAL/MANUAL_ONLY，提升撤销代际并轮换暴露材料；只有两次连续演练同时通过激活和恢复门禁，才允许淘汰旧接班流程。