Vishal Sharmaのゼロトラスト警告：AIエージェントには制御の証明が必要
Vishal Sharmaは、広く受け入れられてきたセキュリティ上の約束に疑問を投げかけている。AIエージェントにルールを守るよう指示しても、そのルールが実際に守られたことの証明にはならない。Vishal Sharmaのゼロトラスト警告が対象とするのは、モデルとソフトウェアツールを使って目標に向けて行動するAIエージェントだ。Queen’s University Belfastの研究者であるSharmaは、エージェントが情報を削除した、制限を尊重した、あるいは認可されたタスクを完了したと主張する際、どのような証拠が残るのかを問うている。
この議論は、企業の購買担当者と開発者に対し、協力と強制可能な制御を区別するよう迫る。成功を報告するエージェントは回答を提示している。一方、関連する操作を独立して記録するシステムは、購買者が調査できるものを提示している。これらの出力に同じ水準の信頼を置くべきではない。
歴史的な参照点となるのは、ネットワーク上の位置や所有関係に基づく自動的な信頼を退けるセキュリティ手法、NISTのゼロトラストアーキテクチャだ。Sharmaの問題提起は、エージェントが情報を解釈し、作業を委任し、タスク間でコンテキストを持ち運ぶとき、この原則がどのように維持されるかに関わる。中心となるトレードオフは明確だ。有用な自律性にはアクセスが必要だが、説明責任を伴う自律性には、モデルが誤りを犯しても有効であり続ける境界が必要となる。
Vishal Sharmaのゼロトラスト警告は、欠けている証拠から始まる
IEEE Spectrumが掲載した、Sharmaの大学支援によるエージェントセキュリティ分析は、組織がエージェントの行動をどのように検証するかを問い直している。スポンサーの存在は重要だ。読者はこれを、商用セキュリティシステムを独立して検証したものではなく、議論への機関による寄与として受け止めるべきである。
記事は、タスクを調整するソフトウェアであるオーケストレーターのもとで動作するエージェントを説明している。また、後続のプロンプトによって、以前に忘れるよう指示された情報をエージェントが取得する可能性を提起している。さらに、エージェントがオーケストレーションしたデオーセンティケーション攻撃が2〜3秒で実行されたという、Queen’s University Belfast内の実験も報告している。デオーセンティケーション攻撃は、デバイスの認証済み無線接続を中断する攻撃だ。
この記事の最大の貢献は証拠を求めている点にある一方、実験上の主張が広範な結論を支えるには、さらに詳細が必要である。
公開された説明には、一般的な攻撃速度のベンチマークを確立するのに十分な方法論が示されていない。コンテキスト回復に関する議論も、物理的に消去された情報が再構築されたことを立証するものではない。ワークフローのどこかで情報にアクセスできる状態が残る問題と、もはや存在しないデータを復元する問題は異なる。
この区別は対応の方向性を定めるべきだ。忘却に関する声明には、メッセージ、保存記録、アクセス可能な文書、あるいはモデルが学習した振る舞いといった、対象を明確に定義する必要がある。その定義がなければ、組織は削除の成功がどのような状態を指すのかについて合意できない。
仮に、顧客プロファイリング支援ツールを考えてみよう。あるユーザーが、以前のインタビューを使用する許可を撤回する。支援ツールはそのインタビューを考慮しないと確認した後、以前の評価に似た推奨を生成する。その類似だけでは、支援ツールがインタビューを取得したのか、要約を保持していたのか、あるいは独立して同じ結論に至ったのかは判断できない。
調査では、システムが実際に何を保持し、何にアクセスしたかを検証する必要がある。生成された説明は手がかりを提供するかもしれないが、その説明自体では問題を決着できない。争点となる行動は、どの記録が利用可能なままだったかを含む、回答の周囲にある仕組みに関わるためだ。
購買者にとって、これは求めるべき証拠を変える。洗練されたデモンストレーションは、準備されたセッション中に支援ツールが正しく応答することを示せる。管理された失敗テストは、予期しない要求に対して制限が維持されるかを明らかにできる。これらのデモンストレーションは、異なる調達上の問いに答える。
ニュースとしての価値は、この重点の移動にある。Sharmaは、口頭の約束が運用上の主張へと変わる地点に注意を向ける。エージェントが機密情報や重大な行動を扱うようになれば、その地点は明示的な検証に値する。
これはベンダーにとっても、より公平な基準を生む。サプライヤーは、自社モデルが望ましくない応答を決して生成しないと約束する必要はない。その代わり、デプロイメントの限界を説明し、その限界に見合う証拠を提示できるべきだ。
ゼロトラストは依然として有効だが、IDだけでは意図を判断できない
2020年8月に公開されたNISTのゼロトラストアーキテクチャは、信頼された社内ネットワークを前提とするのではなく、リソースに保護の焦点を当てる。その説明では、IDを確立する認証と、許可されたアクセスを決定する認可が区別されている。
ソフトウェアが自然言語を解釈できるようになったからといって、この枠組みが時代遅れになるわけではない。有用な出発点を提供している。組織内に存在するエージェントであっても、それだけで組織のリソースへのアクセスが正当化されるわけではない。
分析上の課題は、認証済みのエージェントに、進行中のタスクのためにどこまでの権限を与えるべきかである。
サプライヤー比較表を作成する権限を持つ支援ツールを想定してみよう。承認済みの提案書を読むことは、その任務に合致する。同じ支援ツールが技術的にメールを送信できたとしても、機密の交渉概要をサプライヤーに送ることは別の問題を提起する。
認証に成功すれば、どのアカウントが送信を試みたかは確認できる。しかし、それだけでは、ユーザーがその特定の開示を意図していたことは立証できない。したがって、セキュリティの議論では、要求された行為と、それを裏付ける権限を検討する必要がある。
ここで、エージェントのデプロイメントは従来の企業判断を複雑にする。人間による指示は、あらゆる中間操作を列挙せずに結果を示すことができる。「比較を準備して」という指示には解釈の余地がある。組織は依然として、その解釈によってどの操作まで認可できるかを決めなければならない。
ここから、妥当な調達上の問いが導かれる。支援ツールが不要な手順を選んだ場合、何が起きるのか。答えには、その操作を許可または拒否する責任を担うコンポーネントを示す必要がある。支援ツールが通常は適切な手順を選ぶという約束は行動について述べているが、購買者が尋ねているのは権限についてだ。
同じ考え方は委任にも当てはまる。調整役の支援ツールが別のエージェントにサプライヤーの履歴を調査するよう依頼したとする。その依頼には機密契約を調べる許可が含まれるのか。さらに委任することは許可されるのか。元の制限のうち、どれが受信側のサービスに見え続けるのか。
これらは仮説的な設計上の問いであり、すべてのエージェントプラットフォームが委任を誤って扱っているという指摘ではない。目的は、購買者が広範なアクセスを与える前に前提を明らかにすることにある。権限モデルの仕様が不十分なままでも、デプロイメントは整然として見えることがある。
その結果、セキュリティチームはスコープの問題に直面する。エージェントを単一のアプリケーションとして評価すると、読み取り、編集、送信、削除の間にある重要な違いを見落とす可能性がある。無害な操作をすべて手作業で評価すれば、別の負担が生じる。有用な評価は、その両極端の間にある。
したがって、プロダクトチームは、タスクの意図と実行可能な権限の関係について質問されることを想定すべきだ。その関係を求める顧客は、単なる追加のモデル指示ではなく、システムの性質を求めている。
Vishal Sharmaのゼロトラスト警告は、この観点から読むと最も有用である。これは、既存のアクセス制御原則がすべて失敗したと主張することなく、組織に対して前提を検査可能なものにするよう促している。
メモリはこのトレードオフを無視しにくくする
OWASPのAIエージェントセキュリティガイダンスでは、メモリの分離、有効期限、機密データの取り扱い、そしてエージェントのコンテキスト外での認可が扱われている。コンテキストとは、モデルが応答を生成する際に提供される情報を指す。
このガイダンスはまた、後続の行動に影響を与える悪意ある情報が永続すること、すなわちメモリ汚染を特定している。この懸念は、各応答を孤立した事象として扱うのではなく、保持された情報と将来の行動を結び付ける。
企業の購買者にとって未解決のトレードオフは、支援ツールがどれほどの有用な履歴を、誰の継続的な権限のもとで保持すべきかという点にある。
インタビューをプロジェクト概要に変換する仮想的なリサーチワークフローを考えてみよう。履歴メモは、支援ツールが同じ質問を繰り返すことを避け、意思決定を保持するのに役立つ。これらの利点は、情報を保持する正当な理由となる。同時に、撤回要求の評価をより複雑にする。
仮に、インタビュー参加者が機微な発言の削除を求めたとする。購買者は、製品がどの約束を提供するのかを知る必要がある。元の文字起こしを削除すること、将来の検索対象から除外すること、派生した概要を改訂することは、それぞれ区別される結果だ。
意味のある契約では、適用される結果を明記する必要がある。デモンストレーションでは、その結果を直接テストすることになる。支援ツールにその発言を覚えているか尋ねることは、争点となっている振る舞いを示すのと同じインターフェースに依存するため、より弱い証拠となる。
この区別は、日常的なナレッジワークにも重要だ。パーソナルナレッジベースを選ぶ人は、収集、検索、削除がどのように関係するのかを理解する必要がある。利便性はこれらの問いへの答えにはならず、製品カテゴリーもセキュリティ保証を確立するものではない。
調査と最小化の間には緊張関係もある。組織は、重大な推奨を説明するために十分な履歴を求めるかもしれない。同時に、不必要な個人情報を保持しないことも望むかもしれない。支援ツールが作業を担っても、どちらの目的も消えるわけではない。
仮説的な調査は、その難しさを示す。基礎となるインタビューが削除された後、顧客がある推奨に異議を唱える。調査担当者は、どの認可済みの証拠がその判断に影響を与えたのかを把握する必要がある。すべての原記録を永久に保持すれば削除の約束を損ない、何も保持しなければ調査が難しくなる。
編集上の示唆は、「メモリ」にはより正確な製品表現が必要だということだ。購買者は、関係する記録と、それぞれに付随する保証についての説明を期待すべきである。「忘れる」と表示された単一のスイッチでは、相容れない期待が入り込む余地が大きすぎる。
商業的な圧力は、プロジェクトをまたぐ継続性を販売するベンダーにかかる。その継続性が有用になるほど、機密性の高い作業を評価する顧客にとって、その境界は重要になる。メモリ機能の価値と、そのガバナンス要件はともに大きくなる。
したがって、Sharmaの問いは、異例の攻撃シナリオを超えて広がる。会話が進んだ後にも、組織が情報の取り扱いを検証できるかという、基本的な購買上の問題を露呈させている。
ブラウザー研究は、アーキテクチャが重要性を変える理由を示す
University of Washingtonの研究者Franziska RoesnerとDavid Kohlbrennerは、7種類のエージェント型ブラウザーにおけるブラウザーのオリジン境界を調査した。彼らの研究は、相互に信頼できないウェブサイトを分離するブラウザー規則である、同一オリジンポリシーに関するものである。
同社の2026年4月の報告は、1月下旬から2月上旬に実施した実験について述べている。そこでは、Agent ModeのChatGPT Atlasを対象としたクロスオリジン攻撃の実証が報告された。その他の複数の製品については、同等の完了済み攻撃ではなく、攻撃の前提条件が特定されている。
このシナリオは、プロンプトインジェクションの成功を含む特定の条件、すなわちエージェントに信頼できないコンテンツを指示として扱わせようとする試みに依存している。テストされたバージョンや構成も重要である。これらの知見を、現在提供されているすべてのブラウザリリースについての裏付けのない主張にしてはならない。
より広いアーキテクチャ上の問いは、アシスタントのアクセス権が、通常のウェブサイトコードには存在しない経路を生み出すかどうかである。
購入者にとって、この問いはモデルの知能を一般的に順位付けすることより、有用な比較軸となる。有能なアシスタントであっても、狭いアクセス境界の中で動作する場合がある。別の導入では、アシスタントの判断により強く依存する一方で、より広範な情報にアクセスできる可能性がある。
こうした構成は、実演が似て見えても異なる購買判断をもたらす。どちらもページを問題なく要約できるかもしれない。しかし、その作業中に各アシスタントが追加でどの情報へ到達できるかは、詳しく調べなければ分からない。
公開されている仕入先ページの要約を依頼する架空の従業員を考えてみよう。意図された出力はそのページに関するものだ。ワークフローが非公開の業務資料へのアクセスも許可するなら、評価者はなぜそのアクセスが存在するのか、また利用を何が制約するのかを理解する必要がある。
従業員の依頼は有用な基準点となる。それは、追加アクセスを評価する際の業務目的を定義する。要約が成功したことは、システムが割り当てに必要な以上の情報を公開したかどうかという問いには答えない。
これが、比較に慎重な表現が必要な理由でもある。研究者が害につながり得る経路を特定したなら、調査に値する事実が確立されたことになる。しかし、ある設計上の特徴を共有するすべての製品に対する攻撃の成功まで、必ずしも立証されたわけではない。
購入者は、ベンダーの回答にも同じ規律を適用すべきである。パッチを適用した例は、実証された経路を閉じることはできても、関連するすべての経路が消えたことを示すものではない。逆に、過去の研究結果を、今日も未解決の脆弱性として自動的に提示すべきではない。
現在の議論から得られる教訓は方法論にある。セキュリティ上の主張は、テストした境界、関係した条件、観測された結果を明示するとき、より有益になる。製品名だけでは、その説明を担えない。
これはSharmaの証拠を求める主張を支持しつつ、重要な限界も加える。証拠は、それを生んだシステムと状況に結び付けたままにすべきである。さらに広げるには、より強いレトリックではなく追加のテストが必要だ。
より良いモデルの振る舞いだけでは、封じ込めの問題は解決しない
Anthropicが2025年11月に発表したprompt injection defensesに関する説明は、ブラウザ利用に向けた訓練、検出システム、敵対的テストを扱っている。同社は、ブラウザエージェントが依然として脆弱であることを明確に認めている。
2026年5月のagent containmentに関する議論では、モデルの防御と、エージェントが動作する環境に対する制限を区別している。封じ込めとは、システムが到達または実行できることを制限することを意味する。Anthropicは、モデルの振る舞いを改善するための対策と並行して、環境上の境界を利用していると説明している。
これらは同社のアプローチに関するベンダー自身の説明である。すべての導入が意図した保護を達成しているという独立した証明ではなく、同社が掲げるセキュリティ上の根拠を示すものだ。
重要な比較は、エラーの可能性を下げることと、エラーが起きた際の影響を制限することの間にある。
架空の文書アシスタントは、この違いを具体的に示す。より良い判断力があれば、提案書内の欺瞞的な指示を拒否できるかもしれない。アクセス制限があれば、その指示をどう解釈したかにかかわらず、無関係な機密文書の取得を防げる可能性がある。
これらの結果は別々の問いに答える。顧客は、正当な業務の最中に適切に振る舞うことを求める。同時に、失敗時に何が起こるかについて、防御可能な説明も求めている。徹底した評価は両方を検討すべきである。
これは調達プレゼンテーションに実務上の課題を生む。モデルのデモは目に見える振る舞いを示すため理解しやすい。環境上の制限は、評価者がシステムに禁止された境界を越えさせようとするまで、印象に残りにくい場合がある。
説得力のある実演では、その越境の試みを可視化する必要がある。評価者はその後、何がそれを阻止したのか、どのような証拠が残ったのか、正当な割り当てを継続できたのかを検討できる。拒否自体は結果の一部にすぎない。
評価では、制限のコストも考慮すべきである。厳しく制限されたアシスタントは、追加のユーザー入力を必要としたり、本来は妥当なタスクを完了できなかったりする可能性がある。それは制限が誤りであることを意味しない。その運用上の影響が購買判断の一部になるということだ。
同様に、頻繁な中断が優れたセキュリティの証拠になるとは限らない。中断に注意を払うべきなのは、それが人に重要な結果を理解させ、承認できるようにする場合である。曖昧な承認要求では、根底にある判断が同じように不明確なまま残るかもしれない。
したがって、購入者にとって有用な問いは具体的だ。誰の権限を待っているどの提案アクションなのか、そして承認後に正確には何が変わるのか。答えは、事業成果に責任を負う人にも理解できるものであるべきだ。
この枠組みは、より賢いモデルとより強い境界の間に人工的な競争を作らない。顧客は両方から利益を得るが、各要素が何をもたらすのかを供給者に説明させるべきである。一つの領域の改善は、他のすべての領域の改善を立証するものではない。
また、競争圧力を明確にする。より広い自律性を販売するベンダーには、自社製品が求める権限に見合う証拠が必要である。誤った行動の結果が大きくなるほど、その負担も増す。
Vishal Sharmaのゼロトラストに関する警告は、この議論を決着させることなく、その中に位置付けられる。問題は、協調的な振る舞いだけでは足りなくなったとき、導入環境が信頼できる統制の説明を提供できるかどうかである。
次に必要な証拠は失敗テストから得られるべきだ
今後3か月で最も有用な兆候は、再現性、強制力、そして現実的な失敗条件下での振る舞いに関するものとなる。これらは編集上の注目点であり、発表済みのリリース予定ではない。
最も強い証拠は、何が失敗し、何が保護されたままで、正当な業務がなお完了したかを説明する。
第一に、Queen’s University Belfastの実験について再現可能な報告に注目したい。より完全な発表では、報告された攻撃速度を評価するために、機材、構成、計時方法、比較基準が理想的には特定されるべきである。
独立したチームが明示された条件下で同等の結果を得られれば、その証拠は実験上の主張を強める。より限定的な結果でも、有益であり得る。それにより読者は、特定の実験室での観測と、エージェント支援型攻撃に関する一般的な主張を区別できるようになる。
同じ基準はコンテキストの回復にも当てはまる。有用なテストでは、どの情報が削除され、どこに存在していたのか、どの取得経路が残されていたのかを定義する必要がある。これらの詳細がなければ、一見した想起にはあまりに多くの説明が残される。
第二に、権限の境界を検査しやすくする製品リリースに注目したい。関連する兆候は、テスト可能な制限に結び付いた文書化された変更である。新たなセキュリティラベルだけでは、その証拠にはならない。
たとえば、架空のリリースでは、アシスタントが外部メッセージを準備できる一方、その送信は別のコンポーネントが制御することを実演できるかもしれない。評価者はなお、その制限が対象とする受信者、内容、承認条件を検討する必要がある。
そのような証拠は、ベンダーが一般的なセキュリティ原則を導入可能な統制へ変換しているという根拠を強める。単に別の指示を追加するだけのリリースは、独立して強制される制限についての主張を支える材料としては弱い。
第三に、攻撃耐性と並行して回復をテストする独立評価に注目したい。望ましくない操作を阻止することには価値がある。購入者は、試行を繰り返さず、承認された作業を失わず、過度な介入を必要とせずにシステムが回復できるかも知る必要がある。
架空の評価では、同じ割り当てをアクセス制限の前後で比較できる。結果は、禁止されたアクションと正当な完了の両方を説明すべきである。そうでなければ、ほとんど何も達成しないシステムが、役に立たない理由で安全に見えてしまう可能性がある。
被害が限定され、承認済みの業務が成功していることを示す結果は、実用的な自律性の根拠を強める。有用な完了に広範で説明の不十分なアクセスが必要であることを示す結果は、継続するトレードオフを明らかにする。
これらの兆候が重要なのは、現在の議論がそうでなければ循環的になり得るからだ。研究者は検証を求める。ベンダーは保護措置を説明する。購入者は、それらの保証が何を対象とするかについて共通の説明なしに保証を受け取る。
より正確な証拠があれば、より限定的で生産的な意見の相違が可能になる。一つの導入は草稿作成や調査に適し、別の導入は重大な結果を伴う業務を支援するかもしれない。正当化では、各システムが自らの振る舞いについて何を確立できるのかを特定すべきである。
開発者にとって直接的な意味は、エージェントの責任を広げる前にセキュリティ上の主張をテスト可能にすることだ。企業の購入者にとっては、要求する証拠を具体的な事業上の結果に結び付けることだ。ナレッジワーカーにとっては、機密性の高い業務を任せる前に、アシスタントに付与された権限を理解することである。
次のエージェントパイロットの前に、争点となるアクションを一つ選び、それを解決する証拠を定義してほしい。承認されていない受信者、撤回された文書、あるいは当初の割り当てを超える要求を考えてみる。何が起こるのか、制限がどこで機能するのか、その後にどの記録が残るのかを供給者に示すよう求める。そして、承認されたタスクがなお完了するかを評価する。その実演は、限界を明確にした上で、その導入と構成に関する証拠として扱うべきである。Vishal Sharmaのゼロトラストに関する警告は、この対話の有用な出発点となる問いを提示している。アシスタントがルールに従ったと述べるとき、他者は実際に何を検証できるのか。
