要約

  • GRP 改訂 01 は、発行者とセッションを検証した後、(publisher_id, event_id) が現在のセッションですでに受理済みかを調べる手順を追加した。
  • 重複は ALE-064 / duplicate_event_id として記録し、影響評価、再試行、フォールバック、人へのエスカレーションを繰り返す前に破棄する。
  • 受理済みペアの集合は制御状態になるため、再起動後の保持、複数ノード間の整合、最初の措置との原子性を実装側が示す必要がある。

再送は偽造でなくても危険になる

エージェントが外部サービスに依存して作業している最中に、認められた発行者が可用性の変化を通知したとする。受信側は登録鍵で署名を確認し、session_nonce の一致を見て、代替経路へ切り替える。ところが受信確認だけが送信側に届かず、同一イベントがもう一度配送される。

二通目にも不正な点はない。署名対象の内容は変わらず、nonce はセッション中ずっと同じである。時刻も署名されている。しかし、それらは「この受信側がすでに一度認めたか」を答えない。正しいメッセージを新しいメッセージと取り違えると、一つの障害が二つの措置を生む。

この区別を明文化したのが、The Governed Remediation Protocol (GRP) for Agentic AI Systems の改訂 01 である。Datatracker 上は活動中の個人 Internet-Draft だ。本文は Standards Track を意図すると述べるが、個人草案は IETF の承認、合意、実装、相互運用性を意味しない。評価対象は新たに提案された制御手順である。

GRP の change event は、稼働中のエージェント・セッションに関係する依存先、資源、任務条件の変化を構造化して伝える。必須項目には event_id、publisher_id、発行者種別と署名、session_nonce、時刻、変更種別、対象コンポーネント、重大度がある。イベント ID は発行者のストリーム内でグローバルに一意でなければならない。

改訂 00 にも、発行者の資格と署名を確かめ、nonce の不一致を拒否する手順はあった。改訂 01 は、その後に受理履歴との照合を足している。nonce 自体がセッション中に一定であり、正当な新規イベントと処理済みイベントの再送を区別できないと本文が説明する。

ペアの記憶が行動権を一度にする

新しい手順は、現在のセッションで (publisher_id, event_id) がすでに受理されたかを調べる。該当すれば ALE-064 の理由 duplicate_event_id を残し、影響評価や是正措置を繰り返さずに捨てる。最初の受理で必要な監査記録と措置は作られているため、二通目は真の no-op になる。

ペアであることにも意味がある。イベント ID の一意性は発行者のストリームを単位に定義される。発行者検証は「誰の主張か」、nonce は「どのセッションか」、受理集合は「その発行者のその主張が、もう行動権を得たか」を答える。一つの検証結果を別の層へ流用してはならない。

また、判定位置は影響評価より前でなければならない。フォールバック API を呼んだ後や、人へ通知した後に重複を記録しても、効果はすでに二度発生している。メッセージから措置へ移る直前こそ、再送を無害化できる最後の境界だ。

草案はリプレイと remediation loop も区別する。リプレイは捕捉した一つの正当なイベントを再利用する。ループは、正当に発生した一時障害が何度も新しい事象として現れる。完全一致の重複排除は前者を止められるが、異なる ID の事象が同じ根因かどうかまでは判断できない。

署名方式は受信側の経験を保存しない

RFC 7515 の JWS は JSON 署名を、RFC 7517 の JWK は鍵表現を定める。引用された RFC 9846 は TLS 1.3 の通信条件を与える。これらは完全性、鍵、経路を支えられるが、個々の GRP 受信側が過去に何を受理したかは保持しない。

署名が有効とは、ある鍵の下で内容が検証できるという意味だ。正しい nonce は現在のセッションへの関連を示す。署名付き時刻も、比較する受理窓と状態がなければ再利用防止にはならない。初回かどうかだけは、権威ある履歴との照合で決まる。

発行者鍵が侵害された場合の残余リスクもある。攻撃者は新しい ID を付けたイベントを正しく署名できるため、既存ペアには一致しない。今回の規則が防ぐのは捕捉済みメッセージの再利用であり、侵害された発行元の信頼回復ではない。

受理集合をどこまで耐久化するか

改訂 01 は、現在のセッション中にペアを追跡するよう求める。一方、確認した本文では、保存媒体、クラッシュ後の復元、複数受信側の収束、セッション終了時の破棄、最初の受理と最初の措置を結ぶトランザクションまでは定めていない。これは実装と調達で解くべき問いであり、草案の欠陥を断定する材料ではない。

それでも実効性を左右する。メモリだけなら再起動で履歴が消える。別々の集合を見る二ノードは同時に初回だと思える。先にペアを書いてから停止すれば未完了の措置をどう再開するかが問題になり、先に措置を実行して後で書けば二重実行の窓が開く。

確認できた証拠は草案本文と改訂履歴までである。実装、独立検証、相互運用試験、導入事例、攻撃、事故、性能値は示していない。SOOS の役割名や ALE 番号は提案の語彙であって、運用実績ではない。

出典