Advanced AI SocietyのProof-of-Control、エージェントセキュリティの新たな戦線を開く

Advanced AI Societyは9月17日、草案のバージョン、対象範囲、完成度をめぐる未解決の疑問が残る中、Proof-of-Controlを公開レビューに付した。提案された標準は、AIエージェントに対し、管理対象の各アクションが認可された境界内に収まっていたことを示す改ざん検知可能な証拠の生成を求めるものだ。また、エージェントセキュリティをベンダーの非公開ログへの信頼から切り離すことも目指している。

この転換は重要だ。エージェントはテキスト生成の範囲を超えつつある。ツールを呼び出し、記録にアクセスし、ソフトウェアを変更し、外部サービスと通信し、取引を開始できる。四半期ごとの監査では、各判断をリアルタイムに観測することはできない。また、エージェントの運用者が管理するログでは、独立した保証に限界がある可能性がある。

Advanced AI Societyによれば、80人を超えるセキュリティリーダーがそのアプローチの策定に協力した。同団体はこの取り組みをLinux Foundation Decentralized Trustに置いており、プロジェクトには技術ガバナンスの中立的な場が与えられる。ただし、中立的なガバナンスが草案を完成させるわけではなく、暗号学的証拠が組織による適切な統制の選択を保証するわけでもない。

議会も別の角度から同じ問題に取り組もうとしている。超党派の下院提案は、継続的な検証、セキュリティ評価、インベントリ、改ざん耐性を備えた記録を対象とするエージェントセキュリティの実務をNISTに策定させる内容だ。任意のオープン標準と政府支援の要件が交差する点にこそ、本当の焦点がある。

Advanced AI SocietyのProof-of-Controlは単なる会員発表以上のものだ

重要なのは、それを取り巻く会員資格の見出しではなく、検証可能なエージェント検証提案が公開されたことだ。

Advanced AI Societyは9月の発表で、Linux FoundationおよびLF Decentralized Trustへの参加を明らかにした。しかしLinux Foundationの記録によれば、同組織は2026年4月21日にLF Decentralized Trustのアソシエイトメンバーとなっている。したがって今回の発表は、以前の会員資格に関する動きと、Proof-of-Controlおよび関連ラボの公開を組み合わせたものだ。

この区別は重要である。会員資格は組織を協働ネットワークの中に位置付けるが、組織が公表するすべての主張や技術設計を正当化するものではない。重要なのは、提案された検証標準を、外部の協力者が検証し、異議を唱え、拡張できる財団の環境へ持ち込むことだ。

4月の会員記録では、Advanced AI Societyは新たに加わった2つのアソシエイトメンバーの一つとして記載されている。9月の発表通知では、Proof-of-ControlをLF Decentralized Trustのラボとして紹介し、公開コメントを募っている。

Proof-of-Controlは直接的な問いを軸に設計されている。独立した第三者は、AIエージェントが割り当てられた統制の範囲内にとどまったことを検証できるのか。統制には、承認なしの送金をエージェントに禁じること、アクセスできる顧客記録を制限すること、タスク中に利用可能なツールを限定することなどがある。

この提案は、エージェントがツールを呼び出す、または外部に影響を及ぼす行為を作り出そうとする時点であるアクション境界に焦点を当てる。そのアーキテクチャでは、その境界に独立した介入ゲートウェイを配置する。ゲートウェイは提案されたアクションを評価し、宣言されたポリシーの範囲外にあるアクションをブロックし、その判断に関する証拠を出力する。

この設計は、責任あるAIに関する従来の約束より具体的だ。どこで執行が行われるか、どのような証拠を生成すべきか、別の当事者がその証拠をどのように検証できるかを示している。Advanced AI Societyは、来歴、プライバシー、可搬性、認可、アイデンティティ、セキュリティという6つの検証領域も挙げている。

このフレームワークの中心的な考え方は、同じ運用者が実行と記録保持の両方を管理している場合、エージェントの実行時ログは依然として主張にとどまるというものだ。侵害されたシステムは、アクションを省略し、記録を書き換え、あるいはログ記録を迂回する可能性がある。したがって、有用な検証メカニズムは改変を明らかにし、その証拠が依存する前提を特定しなければならない。

このプロジェクトは複数の保証階層を提案している。低い階層は運用者の表明や監査人のアクセスに依存する。高い階層では、独立して検証可能な記録、または対応する証拠なしには管理対象アクションを実行させない実行ゲートを目指す。

これにより、アクションを観測することと、それを制約することの間に意味のある区別が生まれる。改ざん検知可能な記録は、インシデント後に何が記録されていたかを調査者が確認する助けとなる。正しく実装された実行ゲートは、認可条件が満たされない場合に対象アクションを防止できる。

Proof-of-Controlは、基盤となるモデルが安全、正確、または整合的であるかを判断するとは主張していない。また、企業がエージェントに過大な権限を与えたかどうかも判断しない。これは、宣言された統制が、明示されたスコープに含まれるアクションを統治していたかを確立しようとするものだ。

このより限定的な目標は、実装者に検証可能な対象を与えるため強みとなる。同時に、プロジェクト最大の制約の源でもある。エージェントが弱いポリシーに従ったという証拠は、その弱いポリシーへの準拠しか示さない。

議会はエージェント検証を調達の問題へと変えつつある

エージェントセキュリティは技術的な選好から、規制対象の買い手や連邦政府と取引するための条件へと移行しつつある。

提案されているStop Rogue AI Actは、National Institute of Standards and Technologyに対し、安全なエージェント導入に関する標準、ガイドライン、ベストプラクティスの公表を指示するものだ。報じられた法案の詳細によれば、この取り組みは継続的なエージェントインベントリ、セキュリティ評価、改ざん耐性を備えたログ、エージェントのアクションの検証を対象とする。

この提案は、ニュージャージー州選出の民主党所属Josh Gottheimer議員と、ニューヨーク州選出の共和党所属Mike Lawler議員によるものだ。大半の組織は、結果として得られるNISTの実務を任意で利用することになる。新規案件をめぐって競争する連邦請負業者には、それらを満たすようより強い圧力がかかるだろう。

この仕組みは、広範な規制上の宣言よりも重要だ。調達要件は、すべての民間組織に単一の必須アーキテクチャを課すことなく、技術市場に影響を与え得る。個別のセキュリティシステムを維持するとコストと複雑性が増すため、ベンダーはしばしば政府向けの統制を自社製品全体に採用する。

NISTは下院提案が浮上する前から、この分野に取り組んでいた。2月には、相互運用性、アイデンティティ、認可、セキュリティを対象とするエージェント標準イニシアチブを発表した。また、導入者、開発者、研究者、インフラ提供者から意見を募った。

Proof-of-Controlとの重なりは明白だ。両方の取り組みは、永続的なアイデンティティ、明確に定義された権限、観測可能なアクション、そしてエージェント自身の説明を超えて存続する証拠に焦点を当てている。いずれも、エージェントがツール、認証情報、サービスインターフェースを通じて既存システムと相互作用することを認識している。

ただし、その役割は異なる。NISTは連邦標準プロセスを通じてガイダンスを策定し、調達上の期待に影響を与え得る。Advanced AI Societyはオープンコミュニティを通じて実装志向の標準を提案しており、その周辺で独立検証ツールが発展することを目指している。

下院提案は3つの集団に圧力をかける。エージェントベンダーは、各エージェントをどのように識別し、その権限をどのように制約するかを説明しなければならない。企業の導入者はインベントリを維持し、どのシステムが重大なアクションを実行できるかを判断する必要がある。セキュリティ提供者は、外部の評価者が調査できる証拠を生成しなければならない。

連邦請負業者は、最も明確な強制力に直面する可能性がある。ベンダーは通常の商業市場への販売において、オープン検証を任意と扱うかもしれない。しかし大口の買い手が機械可読なインベントリ、継続的な記録、独立して検証可能な統制を求めるようになれば、その立場を維持するのは難しくなる。

保険会社と監査人も別の圧力源となる。支払いを開始できるエージェントを評価する保険会社には、ポリシー文書以上のものが必要だ。どのアイデンティティが行動し、どの権限が存在し、どの統制がリクエストを評価し、結果としての記録が完全性を保ったかを示す証拠が必要となる。

同じ問題は医療にも現れる。エージェントは医療記録を取得し、症例を要約し、オーダーを準備できる。病院は、記録の完全性を確認することと、臨床判断が適切だったことを確認することを区別しなければならない。Proof-of-Controlが扱うのは前者であり、後者は依然としてガバナンスと専門家によるレビューが決定する。

開発者は統合ポイントで変化を感じることになる。セキュリティは、もはやモデルエンドポイントの保護だけで完結しない。チームは、エージェントが到達できるあらゆるサービスにまたがる認証情報、ツール権限、委任チェーン、データアクセス、副作用を考慮する必要がある。

これが、エージェントセキュリティが機能比較ではなく調達の問題になりつつある理由だ。買い手には、ベンダーをまたいでも意味を保つ証拠が必要である。独自のダッシュボードは運用者が自らのシステムを管理する助けとなるが、監査人、保険会社、規制当局、顧客のための共通の保証言語を自動的に生み出すわけではない。

オープン検証はベンダー管理のログに挑む

主要な争点は、可搬性のある第三者向け証拠と、評価対象のベンダー自身が管理し続けるセキュリティ記録との間にある。

従来のエンタープライズログが無用というわけではない。これらはインシデント対応、監視、デバッグ、コンプライアンスを支える。問題は、ログの価値が誰によって生成されたか、関連するすべての経路を捉えているか、後から誰かが変更できたかに依存することだ。

AIエージェントは、こうした問いをさらに難しくする。そのアクションは、変化するコンテキスト、取得データ、モデル出力、ツール応答、委任された権限に依存し得る。システムは最終的なツール呼び出しを記録できても、その呼び出しがなぜ認可されたかを示すのに十分なコンテキストを保持していない可能性がある。

Proof-of-Controlは、インシデント後に再構成されるのではなく、実行中に生成される証拠を提案する。また、異なる当事者が運用者の環境全体への特権アクセスを得ることなく解釈できる、可搬性のある記録を目指している。

プロジェクトが公開した標準の概要では、証拠をバイナリで、同時代的で、改ざん検知可能であり、残存する信頼の前提を明確にするものと説明している。バイナリとは、管理対象のアクションが宣言された境界内にとどまったか、そうでなかったかのいずれかであることを意味する。より広い結果が正しかったことを意味するわけではない。

企業が定めた上限未満の発注を許可された購買エージェントを考えてみよう。検証レイヤーは、エージェントのアイデンティティ、委任された権限、評価された金額、ポリシーの結果を記録できる。また、その上限を超える注文を拒否することもできる。

しかし、この証拠は、その購入が必要だったこと、サプライヤーが信頼できること、価格が妥当な価値を示していたことまでは立証しない。これらは別個のビジネス上の判断である。検証が示すのは、明示的な統制が守られたかどうかであり、組織が妥当な統制を設計したかどうかではない。

この分離は不可欠である。なぜなら、セキュリティに関する表現は複数の異なる主張を一つにまとめがちだからだ。ベンダーは、権限、監査ログ、人間による承認オプションを備えていることを理由に、エージェントを安全だと説明するかもしれない。しかし、これらの機能は、バイパス経路が存在しないことも、すべての重大なアクションが制御点を通過することも証明しない。

Proof-of-Controlが提案するアクション介入ゲートウェイは、この問題の解決を目指している。これはエージェントのプロセス外部に配置され、制御対象のツール呼び出しを仲介する。このアーキテクチャが機能するには、エージェントがゲートウェイを回避できる代替の認証情報やネットワーク経路を持たないことが必要である。

このバイパス不可という条件を満たすのは難しい。現代のソフトウェア環境には、サービスアカウント、キャッシュされた認証情報、バックグラウンドプロセス、プラグイン、直接的なネットワーク経路が存在する。検証者は、ゲートウェイの出力を見るだけでなく、周辺システムをテストしなければならない。

この提案は、プライバシーとのトレードオフももたらす。検証エビデンスは、プロンプト、個人記録、モデルの重み、独自の事業データを公開せずに、有意義な結論を支えられるだけの情報を示す必要がある。暗号学的な主張は開示を抑えられる可能性があるが、その有用性は基礎となる計測と実装の品質に左右される。

ポータビリティも別の課題を生む。2つのベンダーが異なるポリシー言語、アイデンティティシステム、ランタイム、ログ形式を使用する場合がある。共有エビデンススキーマは、こうした差異の一部を正規化できる。しかし、元の制御がどのように定義・適用されたかという違いをすべて消し去ることはできない。

オープンガバナンスは、この分断に対する信頼できる対応策となる。公開仕様、テストベクター、リファレンスコード、文書化された脅威モデルは、購入者や研究者が検証できる材料を提供する。ベンダー主導の保証プログラムでは、開示内容が少なく、外部の合意なしに変更される可能性がある。

Linux Foundationは、この取り組みのための制度的な基盤を提供する。コミュニティガバナンス、知的財産に関する規則、コントリビューションプロセス、長期的な管理体制を支援できる。ただし、それは設計がエージェント封じ込めや企業導入の課題を解決済みであることを認証するものではない。

この境界は明確に保つべきだ。財団によるホスティングは、プロジェクトに協働の場があることの証拠である。すべての導入が準拠していること、すべての証明が完全であること、顧客が作成された記録を受け入れることの証拠ではない。

草案はすでに、独立したレビューが重要である理由を示している

Proof-of-Controlの初期段階における不整合は、標準を発表することと標準を確立することの違いを明らかにしている。

Advanced AI Societyの9月の発表は、このリリースを「v1.0 working draft」と呼び、パブリックコメントの受付が2026年10月30日まで続くとしている。一方、より詳細な標準ページでは、この文書を「Working Draft v0.1」と特定し、コメント期限を10月7日としている。

Linux Foundationのイベント説明も、これをProof-of-Control v0.1と呼んでいる。これらの差異は、公開作業の非同期、リリース計画の変更、あるいは関連する成果物に対する別々のラベルを反映している可能性がある。理由が何であれ、バージョンと期限の曖昧さは、何をレビューすべきかを判断するコントリビューターにとって重要な問題である。

標準は安定した識別子に依存する。実装者は、どの規範的要件が適用されるのか、テストベクターが現行テキストに一致するのか、破壊的変更がいつ発生したのかを把握する必要がある。監査担当者は、変動するラベルを基準に準拠性を評価することはできない。

これはプロジェクトの目的を無効にするものではない。むしろ、中立的なリポジトリ、リリースタグ、変更記録、公開の課題追跡がなぜ重要かを示している。オープン標準は、エージェントベンダーに同じことを求める前に、自らの来歴を検証可能にしなければならない。

予定されている公開ブリーフィングは9月23日に開催される。Linux Foundationのリーダー、Advanced AI Societyの代表者、セキュリティ投資家、アイデンティティプロバイダー、保険会社、Agentic AI Foundationが参加する。

このイベントはガバナンスを明確にする可能性があるが、公開討論だけで技術的な不確実性が解消されるわけではない。コントリビューターには、規範的な仕様、明示的な脅威モデル、適合性テスト、再現可能な実装が必要である。また、どのメカニズムが各要件を満たすかを決定するプロセスも必要になる。

プロジェクトによれば、リポジトリにはリファレンス実装、機械可読な主張定義、攻撃シナリオ、署名付きテストベクターが含まれている。実装は本番製品ではなくリファレンスとして説明されている。この注意書きは重要である。初期のコードは、運用上のセキュリティ要件を満たさなくても実現可能性を示せるからだ。

リファレンスゲートウェイは、ポリシーの評価方法や署名付きエビデンスの作成方法を示せる。本番用ゲートウェイにはさらに、認証情報の窃取、競合状態、リプレイの試み、不完全なテレメトリー、鍵の侵害、インフラ障害、悪意ある運用者にも耐えることが求められる。

完全性は別の難題を生む。改ざん検知可能な記録は、記録済みのエントリが変更されていないことを示せる。しかし、それだけでは、関連するすべてのアクションが記録に入ったことを証明できない。監視されていない経路を持つエージェントは、可視のエビデンスチェーンが内部的な整合性を保ったまま、記録外で行動できる可能性がある。

Advanced AI Societyが提案するより強力な階層は、実行ゲーティングを通じてこの問題に対処する。このモデルでは、対象アクションは制御を通過してエビデンスを生成しない限り実行できない。残る問題は、すべての重大なアクションが実際に対象範囲に含まれているかどうかだ。

外部への影響も状況を複雑にする。ゲートウェイは、エージェントが承認済みの支払いリクエストを送ったことを検証できる。しかし、銀行が期待どおり正確に支払いを決済したことまで自動的に証明することはできない。保証は、エージェント側のエビデンスと外部システムからの受領記録を結び付ける必要がある。

アイデンティティチェーンにも同様のリスクがある。あるエージェントが別のエージェントに作業を委任し、そのエージェントが第三者サービスを呼び出すことがある。各引き継ぎで、権限、コンテキスト、データ露出が変化する可能性がある。信頼できる標準は、1つのアイデンティティトークンがチェーン全体を説明すると仮定せずに、帰属を維持しなければならない。

制御の品質は、依然として最大の概念的な限界である。Proof-of-Controlは、選択されたルールが賢明かどうかの判断を明示的に避けている。この分離により技術的な準拠性は扱いやすくなるが、組織が準拠性をより広範な安全性の証拠として売り込む可能性はある。

購入者はこの近道に抵抗すべきである。検証済みのエージェントであっても、安全でないポリシーに忠実に従う可能性がある。また、誤ったモデル推論に基づいて承認済みのアクションを生成することもある。ランタイム検証は、テスト、人間による監督、リスク分析、インシデント対応を補完するものであり、それらに取って代わるものではない。

したがって、プロジェクトが最も責任ある形で主張できるのは、狭い範囲に限られる。宣言された制御が対象アクションを統制していたかどうかに関するエビデンスを改善しようとしているのである。完全なエージェント安全性、規制準拠、責任の排除に関する主張は、このエビデンスが示す範囲を超える。

標準は実際のエージェントスタック全体で機能することを証明しなければならない

導入は、Proof-of-Controlが別の孤立したコンプライアンス層を作ることなく、ホスト型モデル、ローカルシステム、マルチベンダーのワークフローをまたいで動作できるかに左右される。

企業のエージェントスタックが単一のサプライヤーから提供されることはめったにない。企業は、ホスト型モデル、社内のオーケストレーションフレームワーク、第三者のアイデンティティプロバイダー、クラウドデータベース、複数ベンダーの専門ツールを利用する場合がある。各レイヤーは異なる制御とテレメトリーを提供する。

Proof-of-Controlは、アクション境界モデルがオープン構成とクローズド構成の両方で機能できると主張している。モデルプロバイダーは、必ずしも重みやトレーニングデータを開示する必要はない。検証レイヤーはその代わり、オーケストレーションシステムが外部機能を呼び出す際の制御対象アクションを観測する。

このアプローチは、自らのエージェントループを制御する組織に有利である。そうした組織はゲートウェイを挿入し、認証情報を制限し、ツール呼び出しを定義済みの境界に通すことができる。管理型エージェントサービスの場合、ベンダーがオーケストレーション環境を制御し、どのエビデンスを公開するかを決めるため、より困難になる。

この違いにより、アーキテクチャは購入基準となる。管理型エージェントを評価する顧客は、独立して検証可能なエビデンスを出力するか、エビデンスが関連するすべてのツール呼び出しを対象とするか、運用者が宣言された経路をバイパスできるかを問わなければならない。

財務チームは具体的なテスト例となる。あるエージェントが請求書を作成し、会計記録を更新し、銀行振込を開始すると仮定する。検証システムは、元帳の閲覧、支払いの提案、承認の取得、最終指示の提出を区別できなければならない。

各アクションには、アイデンティティ、権限の発生源、適用ポリシー、時刻の参照、結果が必要である。システムは、口座データを公開検証記録に漏らさずに、ツール間でそのチェーンを保持しなければならない。また、実行中の承認取消しやポリシー変更にも対応する必要がある。

ソフトウェアエンジニアリングエージェントは別のテストを生む。非公開コードを調査し、ファイルを修正し、テストを実行し、デプロイを要求できる。Proof-of-Controlは、エージェントがどのリポジトリにアクセスしたか、デプロイに指定された承認が必要だったかを検証できる可能性がある。

それでも標準は、間接的な影響を考慮する必要がある。認可ゲートを通過したコードでも、後からデータを公開したり、本番環境の挙動を変えたりする可能性がある。ランタイムエビデンスは、エージェントがどのように境界を越えたかを示す一方、ソフトウェアレビューとセキュリティテストは、エージェントが生成した成果物を評価する。

医療分野では、プライバシーと専門的権限が試される。エージェントは、臨床医からの委任の下で患者記録を取得し、承認のために指示書の草案を送るかもしれない。エビデンスは、基礎となる医療情報を開示せずに、アクセスが付与範囲内にとどまったことを証明しなければならない。

こうしたシナリオに必要なのは、単なる汎用的な署名付きログ以上のものだ。アイデンティティ、権限、ポリシー評価、エビデンス保持、障害時の挙動について、共通の意味体系が必要になる。ある検証者と別の検証者で解釈が異なる記録は、相互運用性を生まない。

したがって、適合性テストがプロジェクトの信頼性を左右する。独立したチームが別々の実装に対して同じテストスイートを実行し、一貫した結果を得られるべきである。ネガティブテストでは、記録が改変された場合、アクションがゲートウェイをバイパスした場合、権限が失効した場合にシステムがどのように失敗するかを示す必要がある。

パフォーマンスも重要になる。エージェントは1つのタスクの間に複数回のツール呼び出しを行うことが多い。継続的なエビデンス生成は、署名、保存、検証、ポリシー評価の負荷を加える。企業は代表的な導入から、レイテンシーと運用に関するデータを必要とする。

Proof-of-Controlの公開資料は、人間によるレビューではエージェントの実行速度に追いつけないため、機械速度の検証を強調している。この前提は妥当だが、自動化は欠陥のあるルールも機械速度で繰り返し適用できる。したがって、制御の変更はコード変更と同じほど慎重に管理されなければならない。

運用上の所有権も未解決の問題である。セキュリティチームがベースラインポリシーを定義し、アプリケーションチームがゲートウェイを統合し、アイデンティティチームが委任を管理し、コンプライアンスチームがエビデンスを保持する場合がある。統一された単一の所有者を前提とする標準は、大規模組織の内部で苦戦するだろう。

プロジェクトは、唯一のエージェントセキュリティ標準にならなくても成功できる。そのエビデンスモデルは、NISTのガイダンス、ベンダーAPI、保険の質問票、調達テンプレートに情報を提供できる。実装が異なっていても、共有概念が市場に影響を与える可能性はある。

より大きなリスクは、儀礼的な導入である。ベンダーは、一部のアクションしか対象にしていないにもかかわらず整合性を主張したり、独立テストを提供せずにオープン検証の言葉を用いたりする可能性がある。明確な適合性レベルと機械検査可能な要件は、この行動を減らせる。

オープン検証がインフラになるかは3つのシグナルで決まる

次の3つの試験は、仕様の一貫性、独立実装、規制当局による採用である。

最初の注目点は、Advanced AI Societyが草案のバージョンとコメント締切の矛盾を解消するかどうかだ。公開リリースタグは、規範文書、スキーマ、テストベクター、リファレンス実装、変更履歴を結び付けるべきである。

その措置は、このプロジェクトの中核的な主張を強化するだろう。検証可能な来歴は、標準そのものから始まるべきだ。成果物のラベル付けに一貫性がなければ、企業はそれらを前提とした統制や契約の構築をためらうことになる。

2つ目の注目点は、独立した実装である。設立組織のリファレンスコードは、著者が記述したものを実際に構築したことを示せる。別のチームが、互換性のある証跡と検証結果を生み出せるだけの詳細を仕様が伝えていることを示さなければならない。

有益な実装報告は、成功だけでなく失敗も記録すべきだ。レイテンシー、統合の負担、未対応のエージェントフレームワーク、プライバシー上の制約、テスト中に見つかった回避経路を特定する必要がある。本番環境での主張には、著者の直接的な管理外にある環境からの証拠が必要だ。

3つ目の注目点は、NISTと議会がエージェント検証の要件をどう定義するかである。連邦政府のガイダンスが継続的なインベントリ、改ざん耐性のある記録、帰属可能なアイデンティティ、独立してテスト可能な統制を求めるなら、Proof-of-Controlは明確な調達ニーズに応えることになる。

連邦政府の請負業者や規制対象の買い手が、ベンダーのスクリーンショットではなくポータブルな証拠を要求すれば、このプロジェクトはさらに勢いを得るだろう。その要件は相互運用性を後押しし、複数の検証プロバイダーが参入する余地を生む。

反対の結果になれば、共有エコシステムを支持する根拠は弱まる。政府機関が従来型のログや定期監査を受け入れる可能性もあれば、議会が基礎となる法案を前進させられない可能性もある。その場合、企業はオープンな検証を任意のセキュリティ実験として扱うかもしれない。

ワシントンにおけるAIを巡る幅広い議論は、依然として決着していない。議会の指導者たちはガードレールについて議論する一方で、規制を軽く保つ方針や中国との競争も強調してきた。この緊張関係により、包括的なAI法よりも、対象を絞った技術標準の方が実現可能性は高い。

法案と成立法の違いは明確に保たなければならない。下院のエージェントセキュリティ提案は、確立された連邦政策ではない。NISTの既存イニシアチブは進行中だが、最終ガイダンスと市場への影響はなお発展途上にある。

したがってAdvanced AI Societyには、新たに形成されつつある用語体系に影響を与えるための限られた時間しかない。調達ルールが固まる前に実装可能な統制を示せれば、その定義は買い手がランタイム保証をどう表現するかを形作る可能性がある。

開発者は、一般的なエージェントフレームワークがポータブルな証拠へのネイティブ対応を追加するかを注視すべきだ。企業の買い手は、統制対象のすべてのアクションと、強制を回避できる経路をベンダーに特定するよう求めるべきである。セキュリティチームは、証拠の完全性と証拠の網羅性を比較すべきだ。

ナレッジワーカーも無関係ではない。個人のメール、文書、カレンダー、金融口座に対して行動するエージェントは、ユーザーが確認する前に結果を生じさせる可能性がある。ユーザーには、自らがどの権限を付与し、エージェントがそれを使って何を行ったかについて、理解可能な記録が必要だ。

Advanced AI SocietyのProof-of-Controlイニシアチブは、そのニーズに対する真剣な答えを提示している。しかし、まだ初期草案にとどまる。その価値は、テスト済みの相互運用性、正確な適用範囲、そして作成者以外の関係者による精査にも耐える証拠から生まれる。

次に取るべき行動は、この標準がエージェントの安全性を解決すると決めつけることではない。買い手と構築者は草案を精査し、回避不可能という要件をテストし、公開レビューの期間中に具体的な実装上の失敗を提出すべきだ。独立した参加者がその主張を再現し、限界を特定できて初めて、オープンな検証はインフラとなる。