9月20日 技術レーダー：AIの権限分離と耐量子暗号

AIに資格情報を使わせること、通信相手の実行環境を確認すること、長く使う機器の暗号を更新すること。今日のレーダーでは、この3つに関係する技術文書を取り上げます。

確認したのは、いずれも2026年9月19日付のInternet-Draftです。確定した標準としてではなく、設計の方向と今後の確認点を読むための資料として紹介します。以下の「編集部の視点」は、資料から考えられる実務上の論点であり、製品の動作検証結果ではありません。

AI・デジタルID：依頼するエージェントと、承認するウォレットを分ける

Agent-to-Wallet Protocol（A2WP）の初版は、ソフトウェアエージェントがデジタル資格情報の取得や提示をウォレットへ依頼する仕組みを提案しています。資格情報の選択、開示、承認、暗号処理はウォレット側が管理します。

対象はやり取りの情報モデルやHTTPSでの接続方法です。エージェント自体の身元確認や権限委譲の方式は対象外なので、この文書だけで認可設計が完成するわけではありません。現時点では個人提出のドラフトで、IETFが承認した標準ではありません。一次資料：A2WP -00

編集部の視点： AIが「社員証を提示して」と判断したとしても、誰に何を見せるかは別の場所で確認できる設計が必要です。自社のエージェントを点検するときは、依頼の生成と開示の許可が同じ処理に集まっていないかを確認する出発点になります。

セキュリティ：実行環境の証明を、いまの通信につなぐ

Remote Attestation with Exported Authenticatorsの第4改訂は、実行環境についての証拠や評価結果を、RFC 9261のExported Authenticatorsを使って交換する方法を提案しています。

狙いは、アテステーションの情報を通信チャネルに結び付けることです。文書は、その情報をハンドシェイク後の認証メッセージに含める拡張も定義しています。こちらも個人提出のドラフトで、最終的な標準ではありません。一次資料：Remote Attestation -04

編集部の視点： 「環境の証明書がある」だけでは、それが接続中の相手についての証明かという疑問が残ります。機密データを預けるサービスを評価する際には、証明の内容に加えて、現在の接続との対応をどのように確認するかを質問すると、設計の違いが見えやすくなります。

IoT・暗号：軽量な鍵交換にも耐量子暗号の選択肢

LAKEの耐量子暗号スイート案は、鍵交換にML-KEM、署名にML-DSAを利用する方式を示しています。RFC 9528のEDHOCを拡張し、名称や暗号方式の登録情報を更新する提案です。LAKEワーキンググループの文書ですが、まだドラフトの段階です。

文書は、鍵や署名の大きさによる負荷に加え、個別の暗号方式の分析だけではプロトコル全体の耐量子安全性を主張できないことも記しています。一次資料：LAKE PQ Suites -01

編集部の視点： 導入判断では「耐量子暗号を搭載できるか」と「対象機器で無理なく運用できるか」を分けて確認したいところです。まず機器ごとの更新可能性、通信量、メモリーの制約を整理しておけば、仕様や実装が進んだときの比較材料になります。

次の検証につなげる3つの問い

• AIの権限： エージェントからの依頼を、独立した仕組みで承認・拒否できるか。
• 実行環境の確認： 提示された証拠と、現在の接続相手との対応を説明できるか。
• 暗号の更新： 対象機器の制約と、置き換える暗号の範囲を把握しているか。

今回の3件は、採用を急ぐための完成仕様ではありません。既存設計で曖昧になっている判断箇所を見つけ、次に何を検証するかを決める材料として追っていきます。

資料の状態は2026年9月20日の確認時点です。リンク先は改訂されるため、本文に記した版番号と合わせて参照してください。