要約

  • 11月2日の個人草案は、AIエージェントの事故対応から再稼働までを五種類の署名記録で結ぶ案を示した。
  • 再開判断には十六の証拠欄がある。各欄には証拠のダイジェストか、扱わなかった理由を明記する。空白のまま消すことはできない。
  • 記録の束が整合していても、受け手に再開を認める義務はない。承認者の独立性も受け手が確認する。

止めた人が、そのまま戻してよいのか

事故でエージェントを停止した後、業務は早く道具と認証情報を返してほしいと迫る。再開の根拠を誰が確かめるのか。11月2日の草案は、対応行為の承認（R1）、認証情報の失効調査（R2）、再開判断（R3）、組織をまたぐ共同権限（R4）、失効の到達範囲（RB）を別々の記録にする。各記録はin-toto Statementで、署名付きDSSE封筒に収める設計だ。

再開を決めるR3には、全面再開、段階的再開、制限継続、判断未成立の選択肢がある。段階的なら戻すエージェント、道具、経路、認証情報を列挙する。承認者の役割と独立性の根拠も書く。十六の欄は、根本原因、復旧資産の完全性、事故再現テスト、再開後の監視、残余リスク、上級者の承認、所有者の確認などを扱う。証拠のSHA-256ダイジェストを示すか、notAddressedと理由を書く。証拠がないこと自体が読める。

R3は先行記録をダイジェストで参照する。読む側は、各記録が一度だけ存在し、型と事故が一致し、発行順序が逆転せず、循環もないか調べる。段階的に戻す認証情報はR2の失効調査にも載っていなければならない。通過した束の判定はbundle-consistent。書類同士が合っているという意味で、稼働を認める最終判断は受け手に残る。

草案はindependenceBasisを作成者の申告として扱う。独立した承認を求める側は、名指しされた承認者を自ら確認すべきだとする。停止を命じた人が再開も承認した事実は記録できる。その集中を許すかは受け手の規則で決まる。IETFの記録では個人Internet-Draftであり、作業部会による採用や運用例は確認できない。