要約

  • 2026年9月7日付のdraft-kuehlewind-audit-architecture-01は、「In-Band Record Storage」を追加した。各エージェントが自らのAudit Storeを動かし、通常の対話に使う接続で記録を交換できる。
  • 草案は外部ストアの代替案として位置づけ、置き換えとはしていない。併用も可能だが、エージェントとストアを同じ主体が運用する場合、その主体への信頼が増えると明記する。
  • 保管と監査は同義ではない。Recorder、Auditing Service、Attestation、透明性登録、Auditor、Verifierは別の機能として記述される。
  • 文書は現在も個人Internet-Draftである。Datatrackerは、IETFの承認を受けておらず、標準化プロセス上の正式な地位もないと表示している。
  • Daniel Kadeは、各機能の運用者を示す「保管トポロジー受領証」を提案する。これは草案の要件ではなく、本稿独自の分析である。

新しい近道には信頼コストが書かれている

第01版で最も目を引く追加は、わずか一段落である。新設された3.2節によれば、記録をすべて独立した外部Audit Storeへ書き出す代わりに、各エージェントが自分のStoreを運用できる。対話相手のエージェントが持つStoreへ、既存の通信接続を再利用して記録を送り、別の帯域外チャネルを設けなくてもよい。

この方式には現実的な利点がある。短時間だけ動くエージェントでも、相手とはすでに認証済みの接続を持つことがある。そこに記録を同伴させれば、追加統合を減らし、分散した処理の経路に沿って証拠を残しやすい。草案も自前ストアを唯一の答えとはしていない。外部Storeの代替であって置換ではなく、両方を組み合わせられる。そして代償も隠していない。同じ主体がエージェントとStoreを運用する構成は、独立した外部Storeよりも、その主体を強く信頼する。

第00版には、この帯域内保管の節がなかった。したがって今回のニュースは、以前からあった一般論の言い換えではなく、版の差分として確認できる。

「監査済み」という一語では役割が消える

帯域内保管そのものを無効と決めつけるべきではない。問題は、複数の行為を「このエージェントは監査されている」の一言で束ねることだ。第01版が挙げる役割を追うと、その危うさが分かる。

主要な当事者は、それぞれ異なる視点から記録を作る。利用者側は依頼や承認を残せる。エージェントは行為、委任、認可状態の変化に関する信号を出す。ツールや外部サービスは、効果が発生する境界で自らが見た要求を記録できる。Audit Recorderは信号を取り込み、あるいは変換する。Audit Storeは記録を保持し、取得可能にする。Auditing Serviceは観測可能な記録を正規化し、自身の識別子に結びついた鍵で署名し、透明性ログへ登録する。Auditorはポリシーに照らして証拠を判断し、Verifierは個別の主張を評価する。

保管が答えるのは、後でどこから記録を得られるかだ。署名は、どの鍵が声明を承認したかを示す。Attestationは生成環境についての主張を支え得る。透明性の受領証は、ある時点で声明が登録され、矛盾した履歴を見せられていないかを検証する材料になる。Auditorの独立性は、誰が判断するかに関わる。どれか一つがあっても、全当事者が漏れなく真実を記録した証明にはならない。

しかも草案は役割の集約を認める。役割は機能であり、別々の装置や企業を意味しない。一つの主体が複数を担える。エージェントのホストプロセスがRecorderを兼ねる構成も可能だ。導入は簡単になる一方、草案はRecorderとの共謀リスクを挙げ、独立Recorderまたは透明性登録による否認困難性を緩和策として示す。別の箇所では、説明責任の性質には独立したAuditing Serviceが必要だとする。

用語を正確に使えば、これは矛盾しない。同じ主体のStoreが輸送と保管を担い、独立サービスが正規化や外部コミットメントを担う構成はあり得る。第三者がStoreを提供しても、監査判断を行うとは限らない。反対に、外部製品であっても、同じ企業集団、管理者、鍵保有者に支配されているかもしれない。「外部」は配置の話であり、「独立」は統制と利害の話である。

ストアの所在地は保管支配を証明しない

二つの例を考える。一方はエージェントのプロセス内にStoreを置くが、別主体のサービスが直ちに署名済みコミットメントを、運用者が単独で書き換えられない透明性システムへ登録する。もう一方はクラウドのログ口座へ記録を転送するものの、その口座をエージェント運用チーム自身が管理し、外部コミットメントの前なら原本と転送先の双方を変更できる。

後者は地理的には外部である。前者の方が、履歴に早く制約をかけている可能性がある。もちろん、この例だけで完全性や適合性は証明できない。ネットワーク図やベンダー数を、保管履歴の代わりにしてはいけないということだ。

RFC 9334も、リモートAttestationで機能を分ける。AttesterがEvidenceを作り、Verifierが評価し、Relying Partyが自分のポリシーを適用する。RFC 9943も、署名済み声明、透明性サービス、受領証、利用側の判断を区別する。部品名が保証水準を生むのではない。役割、ポリシー、鍵、証拠の経路が信頼範囲を決める。

制度上の位置づけも誇張できない。DatatrackerにはRFCストリーム、担当Area Director、Working Group採用が示されず、個人Internet-DraftにIETFの承認はないとの注意がある。新しい保管方式は開発中の提案であって、IETFが定めたエージェント監査規則ではない。

情報源