Agentic AIがZero Trustにアイデンティティ危機への対応を迫る
- Ethan Carter
- 4 日前
- 読了時間: 25分
Agentic AIがGoogle Newsで強い主張とともに取り上げられた。自律システムがZero Trustサイバーセキュリティを「根底から覆している」というものだ。Breaking Defenseの見出しは、その詳細を独自に検証することが依然として難しい一方で、現実に存在する対立を示している。セキュリティチームは、人、デバイス、予測可能なアプリケーションを中心にアクセス制御を構築してきた。AIエージェントは委任された権限で行動しながら、これら3つの区分すべてを曖昧にしている。
だからといって、Zero Trustが時代遅れになるわけではない。組織が何を検証すべきか、どの頻度で検証すべきか、そして各アクションをどのアイデンティティが実行したかを変えるのである。エージェントは目標を解釈し、ツールを選択し、外部コンテンツを読み、APIを呼び出し、データを変更できる。その挙動は、人間の所有者に割り当てられた権限だけでは完全には捉えられない。
その結果、厄介な逆転が生じる。Zero Trustはあらゆるリクエストを評価すべきだと前提するが、agenticなワークフローはマシン速度で長大なリクエスト連鎖を生み出す。したがって、本質的な対立はagentic AI対Zero Trustではない。静的なアクセス制御と、自律的な振る舞いに対する継続的な制御との対立である。
Google Newsの主張は現実のセキュリティ変化を示している
重要な変化は、AIがエンタープライズシステムにアクセスできることではなく、アクセスを得た後に何をするかを判断できることだ。
従来のソフトウェアは、開発者があらかじめ定義した経路に従う。バグを含んだり、悪意ある入力を受け入れたり、脆弱なインターフェースを露出したりする可能性はある。しかし防御側は通常、その意図された機能を、確立済みのアカウント、プロセス、ネットワーク接続に対応付けられる。
Agentic AIは、ユーザーの指示と実行されるアクションの間に意思決定の層を加える。エージェントは広範な目的を小さなタスクに分割し、利用可能なツールから選択し、ある経路が失敗した場合には適応できる。NISTは、現代のエージェントを、テキスト生成を超えてツールを操作できるソフトウェアと組み合わされた汎用モデルとして説明している。
こうしたツールには、ブラウザ、データベース、カレンダー、コードインタープリター、ローカルファイル、管理インターフェースなどが含まれる。NISTのツール利用の分類体系は、読み取り専用アクセスと、制約付きまたは無制限の書き込みアクセスを区別している。また、信頼できる環境と信頼できない環境も分けている。
この区別が重要なのは、単一のエージェントが一つの業務の間に複数のカテゴリをまたぐことが多いためだ。メールを読み、顧客番号を抽出し、社内データベースを照会し、サポート記録を更新することがある。各ステップを個別に確認すれば、いずれも許可されているように見えるかもしれない。
それでも、組み合わされたワークフローは安全でない結果を生む可能性がある。攻撃者はメール内に隠された指示を埋め込める。エージェントはそれらの指示を自身のタスクの一部と解釈し、正規の権限を使ってデータを開示する可能性がある。
この攻撃は間接プロンプトインジェクションと呼ばれ、エージェントが処理するコンテンツを通じて悪意ある指示が届くことを意味する。攻撃者は従業員のパスワードを必要としない。攻撃者が狙うのは、信頼できる情報と信頼できない情報をエージェントがどう解釈するかである。
Google Newsの見出しは、「根底から覆す」という表現を通じてこの変化を捉えている。かつてセキュリティチームは、人がソフトウェアを誤用したり認証情報を渡してしまったりすることを懸念していた。今では、人の権限を解釈し、その範囲内で独立して行動するソフトウェアについても考慮しなければならない。
これは単に、ネットワークに加わる別のエンドポイントではない。通常、エンドポイントには比較的安定した機能、状態、所有モデルがある。エージェントは、同じアイデンティティ、認証情報、接続を保持したまま、直近の計画を変えられる。
それにより可視性の問題が生じる。ログには有効なサービスアカウントがデータベースにアクセスしたことが記録されるかもしれない。しかし、どのユーザーがタスクを開始したのか、どのエージェントが計画を立てたのか、どの外部入力がその判断に影響したのかは明らかにならない可能性がある。
見出しは、特定の侵害を示す証拠ではなく、あくまで論題として扱うべきだ。提供されたGoogle News項目には、検証済みのインシデント詳細は添えられていない。しかし、より広範なセキュリティ上の問題は、公開研究や現在進行中の標準化作業によって裏付けられている。
セキュリティチームが守るべき対象は、もはや人からアプリケーション、人からアプリケーション、アプリケーションからアプリケーションへのアクセスだけではない。人、エージェント、モデル、複数のツール、複数のデータソースをつなぐ連鎖を保護する必要がある。信頼はあらゆる引き継ぎで漏れ出し得る。
Zero Trustはリクエストのために設計されており、無限定な目標のためではない
Zero Trustは依然として有効だが、その従来の制御単位は自律的な作業には狭すぎる。
NISTは2020年、基盤となるZero Trustアーキテクチャを公表した。このモデルは、ネットワーク上の位置や資産の所有権に基づく暗黙の信頼を退ける。認証と認可は、セッションがエンタープライズリソースに到達する前に行われる。
このアーキテクチャは、従来のネットワークセグメントではなくリソースに焦点を当てる。ネットワークはすでに侵害されている可能性があると想定する。そのためアクセスは、特定の任務に必要な最小限の権限に制限されるべきだ。
このアプローチは、従来の境界防御モデルに対抗する。境界セキュリティでは、認証済みユーザーは信頼されたネットワークに入った後、広範なアクセスを得ることが多かった。攻撃者は一つのアカウントまたはデバイスを侵害すれば、その後にシステム間を横方向に移動できた。
Agentic AIはこうした原則を無効化しない。実際、マシンが多くのアクションを迅速に実行できるようになるほど、最小権限と継続的な評価は重要になる。困難なのは、広範なユーザー目標を、強制可能で短期間の権限へと変換することにある。
四半期ごとの顧客リスクレポートを作成するよう依頼されたエージェントを考えてみよう。このタスクは情報収集のように聞こえるが、完了には複数の能力が必要になる可能性がある。エージェントは記録を探し、データを結合し、傾向を計算し、文書を作成しなければならない。
そのエージェントには、業務全体を通じてすべての顧客記録へのアクセスを与えるべきだろうか。終了後もその権限を保持すべきだろうか。レポートをメール送信できるのか、それとも配布には別途承認が必要なのか。
従来のアクセスシステムは、ユーザーの既存の役割に基づいてこれらの問いに答える場合がある。従業員がデータベースを読み、メールを送信できるなら、エージェントは両方の権限を継承する。その継承は単純だが、過剰な権限を生む。
エージェントは、従業員が意図しなかったアクションの組み合わせを実行できる。また、手作業のワークフローではほとんど到達しない規模で、それらを繰り返すこともできる。小さな解釈の誤りが、数百件のデータベース照会やメッセージ送信に拡大する可能性がある。
無限定な目標はポリシー設計を難しくする。「関連する証拠を見つける」は、どのリポジトリを検索すべきかを指定しない。「問題を解決する」は、エージェントが返金を実行し、アカウントを変更し、コードを実行できるかどうかを定義しない。
Zero Trustは従来、アイデンティティ、デバイスの健全性、リソースの機密性、環境コンテキストを用いてアクセスリクエストを評価してきた。Agenticシステムは、もう一つの問いを加える。このアクションは、アクセスを正当化したタスクと引き続き整合しているか。
この問いには、意図を認識する制御が必要だ。こうした制御は、アクションをエージェントに割り当てられた目的、現在の計画、承認済みポリシーと照合する。アカウントが技術的に権限を持つかどうかだけに依存することはできない。
マルチエージェント作業では、セキュリティ境界も移動する。一つのエージェントが別のエージェントに調査を委任する場合がある。その2番目のエージェントがサードパーティサービスを呼び出し、そのサービスが新たな指示を含むコンテンツを返す可能性もある。
各引き継ぎは、表面的な認可を維持したままコンテキストを変え得る。静的ポリシーには、承認済みアイデンティティがデータを受け渡しているように見える。行動ベースのポリシーは、連鎖全体が依然として当初の目標にかなっているかを判断しなければならない。
これが、agentic AIのセキュリティがネットワークセグメンテーションだけでは完結しない理由である。制御プレーンは、アイデンティティ、タスク、ツール、データ来歴、アクション履歴を理解する必要がある。また、後の調査のために、それらの関係を保存しなければならない。
Zero Trustが当初掲げた約束は、今なお有効である。すでに内部にあるという理由だけで、決して信頼を与えてはならない。Agenticなワークフローは単に、「内部」がコンテキストウィンドウ、委任タスク、ツールチェーンを表すこともあると示している。それはもはやネットワークだけを指す言葉ではない。
AIエージェントには所有者とは別個のアイデンティティが必要だ
すべてのアクションが人間または共有サービスアカウントのもとで表示されるなら、組織は自律エージェントを統制できない。
アイデンティティは、エンタープライズセキュリティチームにとって最初の圧力点となる。人には雇用記録、上司、職務、退職時の手続きがある。アプリケーションには所有者、リリースプロセス、サービスアカウントがある。
エージェントは両方のグループの特徴を組み合わせる。人から目標を受け取れる一方、ソフトウェアを通じて実行する。一つのタスクのために短時間だけ動作することもあれば、永続的なデジタルワーカーとして稼働し続けることもある。
エージェントをアプリケーション内の隠れた機能として扱うと、説明責任が不明瞭になる。通常の従業員として扱うことも、誤った安心感を生む。エージェントには、その所有者、目的、デプロイメントに結び付いた第一級のマシンアイデンティティが必要だ。
そのアイデンティティは、開始したユーザーのアイデンティティに取って代わるべきではない。両方がワークフロー全体を通じて保持される必要がある。調査担当者は、誰がアクションを要求し、どのエージェントが実行したかを把握しなければならない。
有用な監査記録には、関与したモデル、ツール、ポリシー、データソースも記録されるべきだ。このコンテキストがなければ、データベースログには最終的なアクセスしか表示されない。なぜエージェントがそのアクセスを適切だと判断したのかを説明できない。
セキュリティチームは、エージェントのデプロイメントに共有認証情報を使用すべきではない。共有アカウントは信頼できる帰属を妨げ、失効処理を複雑にする。また、元のプロジェクトが終了した後も、放棄されたエージェントを稼働し続けさせてしまう。
エージェントのアイデンティティにはライフサイクルが必要だ。作成時には、責任を負う所有者と承認済みの用途を特定すべきである。定期レビューでは、エージェントが引き続き必要であることと、その権限が目的に見合っていることを確認すべきだ。
有効期限も同様に重要である。一時的なエージェントは、タスクまたはプロジェクトの終了時にアクセスを失うべきだ。永続的なエージェントは、特権を持つ人間のアカウントと同様、定期的な再認証を受けるべきである。
権限もタスク固有かつ短期間であるべきだ。レポートを作成するエージェントには、選択された記録に対する一時的な読み取りアクセスを与えられる。組織外へのレポート送信には、別個の権限または人間による確認が必要となるべきだ。
この設計は、アイデンティティが責任に見合わないアクセスを蓄積していく権限クリープを抑える。権限クリープは、従業員の場合でもすでに管理が難しい。チームは自律エージェントを迅速に作成できるため、エージェントはこの問題を増幅させ得る。
したがって、エージェントの発見は運用上の要件となる。セキュリティチームには、SaaSサービス、開発プラットフォーム、社内自動化システム、サードパーティ統合にまたがるインベントリが必要だ。調達記録だけでは、既存製品の内部で作成されたエージェントを特定できない。
発見では、AI機能と行動するアイデンティティを区別しなければならない。単一の文書を読むだけの要約機能は、ドライブを検索してメッセージを送信できるエージェントとは異なるリスクを伴う。両者が同じモデルを使用している場合でも同様だ。
所有者は、ポリシーとログでも可視化されるべきだ。エージェントが期待を逸脱して行動した場合、対応者にはそのエージェントを停止できる担当者またはチームが必要になる。匿名の自動化は、インシデント対応時の遅延を生む。
組織はすでに、サービス、ワークロード、マシンに非人間アイデンティティを使用している。エージェントアイデンティティは、その規律を置き換えるのではなく拡張するものだ。違いは、同じ割り当て済みの役割の中でも変動する振る舞いを、ポリシーが考慮しなければならない点にある。
主要なセキュリティベンダーはこの方向へ動いている。Ciscoは、agent security updateの中で、エージェントの検出、エージェント向けアイデンティティ制御、Model Context Protocolの強制を発表した。Model Context Protocol、すなわちMCPは、モデルをツールや外部データと接続する。
ベンダーの発表は、これらの制御があらゆる導入環境で機能することを独立して裏付ける証拠ではない。しかし、競争がどこへ向かっているかを示している。アイデンティティプラットフォーム、アクセスブローカー、セキュリティゲートウェイはいずれも、エージェントトラフィックの制御点になろうとしている。
企業の購買担当者は、単一のゲートウェイを完全な解決策と見なすべきではない。NISTは以前から、単一ベンダーがZero Trustアーキテクチャ全体を提供することはないと指摘している。エージェント型セキュリティでは、構成要素が増え、一貫しない強制が起こる機会も増える。
当面の負荷は、アイデンティティおよびアクセス管理チームにかかる。管理されていないサービスアカウントの問題を繰り返すことなく、急速に作成されるマシンアクターを支援しなければならない。静的なロール割り当てだけでは不十分になる。
エージェント乗っ取りが示す静的な権限チェックの限界
正しく認証されたエージェントであっても、認証はその推論の妥当性を検証しないため、誤った行動を取る可能性がある。
Zero Trustを再構築すべきだという最も強い根拠は、エージェント乗っ取りに関する研究から得られる。2026年3月、NISTは13のフロンティアモデルを対象とした大規模な公開レッドチーミング競技会の結果を報告した。400人以上の参加者が25万回を超える攻撃を試みた。
テスト対象となったすべてのモデルで、少なくとも1件の乗っ取り攻撃の成功が確認された。モデルごとに耐性の差はあったが、能力が一貫して安全性を予測するわけではなかった。一部の攻撃ファミリーは、異なるモデルやシナリオにも横展開できた。
これらの結果は、導入済みのすべてのエージェントが容易に侵害されるという意味ではない。競技会では攻撃者が特定の標的に集中でき、本番環境のすべての制御を再現するとは限らない。しかし、モデルレベルの耐性だけではセキュリティ境界になり得ないことは示している。
NISTはエージェント乗っ取りを、エージェントが処理するデータ内に悪意ある指示を埋め込む攻撃と定義している。目的は、エージェントを有害な振る舞いへと誘導することだ。結果として、データ流出や悪意あるコードの実行が起こり得る。
重要なのは、エージェントが有効なツールと認証情報を使うことが多い点だ。ファイアウォールには承認済みの接続として見える場合がある。アイデンティティシステムには認証済みアカウントとして見える場合がある。危険な段階は、エージェントによるコンテンツの解釈の中で発生する。
そのため、静的な許可リストだけでは不完全である。エージェントにメールの閲覧とデータベースの更新を許可することは、その業務に必要かもしれない。それでもポリシーは、メールがデータベースツールの動作を再定義することを防がなければならない。
関連するレッドチームの調査結果は、多層防御を裏付けている。モデルの評価は必要だが、導入環境には制約付きツール、データ境界、監視、承認ポイントも必要である。
ツール権限は利便性ではなく、影響の大きさを反映すべきだ。公開Webページの閲覧と、ダウンロードしたコードの実行ではリスクが異なる。顧客レコードの照会は、その削除やエクスポートとは異なる。
影響の大きいツールは、限定された操作だけを公開すべきである。会議の予定設定が必要なエージェントに、無制限のメールボックス制御を与えるべきではない。支払いを起案する財務エージェントが、その承認と送信まで行うべきでもない。
この原則は職務分離と呼ばれる。これは、1つのアイデンティティが機密プロセスのすべての段階を支配することを防ぐ。自動化によって統合が魅力的に見える場合でも、エージェント型システムには同じ分離が必要である。
人による承認は、不可逆な境界で引き続き有用だ。送金、削除、外部公開、本番環境へのデプロイ、認証情報の変更には、明示的な確認が必要である。承認画面には、意図された操作と関連するコンテキストを表示すべきだ。
一般的な「許可」ボタンでは、ほとんど保護にならない。レビュー担当者は、どのエージェントが操作を要求したか、どのデータを用いたか、承認がどのような効果を生むかを知る必要がある。そうでなければ、自動化はソーシャルエンジニアリングを承認画面へ移すだけになる。
監視は行動の変化に重点を置くべきである。エージェントが突然、これまで扱っていないリポジトリにアクセスし始めた場合、乗っ取りや不適切な計画を示している可能性がある。ツール呼び出しの失敗が繰り返される場合も、エージェントが自身の役割を超えて探索している兆候になり得る。
レート制限も、ミスによる被害を抑える。機械速度での実行は、1つの誤った判断を広範なインシデントへと変え得る。操作量を制限すれば、監視システムと対応担当者が介入する時間を確保できる。
サンドボックスも依然として有用だが、安全であるとの前提を生むべきではない。エージェントは実行環境から脱出しなくても被害を引き起こせる。認可されたデータを誤った宛先へ送ることには、ソフトウェアのエクスプロイトは不要かもしれない。
中心的な不確実性は、意図を認識するシステムが有用な業務を妨げずに信頼できる判断を下せるかどうかである。エージェントの計画は変化し、ビジネスタスクには曖昧さがあり、ポリシーではすべての正当な例外を予見できない。
制御が厳格すぎると、承認要求が絶えず発生する。するとチームは生産性を回復するため、より広い権限を付与するかもしれない。その対応は、Zero Trustが取り除くことを意図した暗黙の信頼を再び生み出す。
制御が寛容すぎる場合は、逆の失敗が起こる。エージェントは、悪意ある入力や計画ミスがその権限を悪用するまで、円滑に動作する。セキュリティチームは、阻害された業務と危険な操作の両方を測定しなければならない。
このトレードオフがあるため、「エージェント型Zero Trust」製品が問題を解決したという安易な主張は成り立たない。製品デモは通常、選定されたワークフローを示す。本番導入環境には、レガシーシステム、共有アイデンティティ、一貫しないログが存在する。
短期的に最も信頼できるアプローチは、多層的なものだ。各エージェントにアイデンティティを与え、各ツールを制限し、起点となるユーザーを保持し、重要な操作を検証し、行動を監視する。モデルの安全対策は時に失敗するものとして扱うべきである。
競争の主戦場はコントロールプレーンへ移行している
セキュリティベンダーはエージェントの行動を仲介しようと競争している一方で、企業にはその仲介が機能することを証明する共通モデルがなお欠けている。
エージェント型AIは、アイデンティティプロバイダー、ネットワークセキュリティベンダー、クラウドプラットフォーム、専門のAIセキュリティ企業に機会を生み出している。各グループはワークフローの異なる部分を制御する。いずれも自動的に全体の連鎖を把握できるわけではない。
アイデンティティベンダーは、誰にアクセス権が付与されたかを把握している。ネットワークプラットフォームは、システム間の接続を観測する。クラウドプロバイダーは、ワークロードとAPI呼び出しを監視できる。AIセキュリティツールは、プロンプト、モデル出力、ツール要求を検査する。
価値の高い位置は、ポリシー決定ポイントである。Zero Trustアーキテクチャでは、このコンポーネントがアクセスを評価し、強制によって許可すべきかを判断する。エージェント型システムは、その判断をより豊かにすると同時に、より争点の多いものにする。
ネットワークベンダーは、エージェント通信はセキュリティブローカーを通過すべきだと主張するかもしれない。アイデンティティベンダーは、マシンアイデンティティと委任された認可をポリシーの中心に据えるかもしれない。AIセキュリティプロバイダーは、プロンプトの検査と行動評価を優先するかもしれない。
3つの見方はいずれも答えの一部を含んでいる。ネットワークコンテキストでは、すべての悪意ある指示を明らかにできない。プロンプト検査だけでは、ブロックされたデータベースクエリを単独で強制できない。アイデンティティ検証だけでは、認証済みのエージェントがその目的に従うことを保証できない。
MCPは、モデルとツールの接続を標準化するため、焦点の一つとなっている。ゲートウェイはサーバーをインベントリ化し、操作を制限し、呼び出しを記録できる。ただし、すべてのエージェントがMCPを使うわけではなく、ゲートウェイはそれを迂回するツールを統制できない。
エージェント間通信は別の課題をもたらす。委任は、モデル、ベンダー、組織の境界をまたぐ可能性がある。受信側のエージェントには、送信者のアイデンティティ、権限、要求されたスコープに関する証拠が必要である。
署名付きメッセージは送信者を認証できる。しかし、送信者の計画が安全であることまでは証明しない。ポリシーは、要求の出所を特定するプロベナンスと、要求を進めるべきかを決定する認可を分けなければならない。
標準化の取り組みは、こうしたギャップに対処し始めている。NISTは2026年2月に、agent standards initiativeを立ち上げた。その議題には、相互運用性、オープンプロトコル、セキュリティ、アイデンティティ、信頼できる導入が含まれる。
この取り組みが重要なのは、組織がエージェントのアイデンティティと権限を比較可能な形で表現する必要があるためだ。共通フォーマットがなければ、各プラットフォームが独自のアイデンティティとポリシーシグナルを作ることになる。そうなると、セキュリティチームは環境をまたいだ制御の強制に苦労する。
標準だけでは、リスク許容度を決められない。病院、銀行、防衛請負企業、マーケティング会社では、同じツール操作に対して異なる影響を見積もる。相互運用性が提供するのは共通の基盤であり、普遍的なポリシーではない。
Breaking Defenseの枠組みは、高保証が求められる環境に特に関連する。防衛システムは、機密データ、任務上の制約、レガシー機器、厳格な説明責任を組み合わせることが多い。自律的な操作は、通常のオフィス自動化を超える影響を持ち得る。
こうした環境では、自動化への圧力も生まれる。分析担当者は大量のアラート、文書、センサーデータに直面している。エージェントは情報の相関付けや反復作業の実行を支援できるが、自律性が広がるほど、追跡可能な制御の必要性は高まる。
したがって競争は、製品用語ではなく証拠によって評価すべきである。購買担当者は、制御がエージェントを確実に識別し、操作を所有者に結び付け、ツールを制限し、利用可能な監査記録を生成できるかをテストする必要がある。
失敗時のケースもテストすべきだ。アイデンティティプロバイダーが利用できない場合、何が起こるのか。エージェントはキャッシュされた権限にフォールバックできるのか。ブローカーはフェイルクローズするのか、それともトラフィックは検査を迂回するのか。
クロスプラットフォームのカバレッジは、個別機能と同じくらい重要である。組織は、あるクラウドのモデル、別ベンダーのコーディングエージェント、複数のSaaSアシスタントを使うかもしれない。1つの環境しか見えない制御には、大きな死角が残る。
市場は統合プラットフォームを中心に集約していく可能性が高いが、統合はそれ自体で集中リスクを生む。1つの侵害されたポリシープレーンが、多数のエージェントに影響を与え得る。独立したログと強制は、引き続き重要な保護策である。
Google Newsは、エージェント型AIが既存のセキュリティモデルを置き換えるという見出しを増幅するかもしれない。より正確な結論は、より限定的である。既存ベンダーは、Zero Trustを接続判断からアイデンティティ、意図、操作のガバナンスへ拡張しなければならない。
セキュリティチームが次に注視すべきこと
次の段階を決めるのは、自律型セキュリティに関するより広範な主張ではなく、測定可能な導入の証拠である。
最初のシグナルは、標準化団体がエージェントのアイデンティティと委任認可に関する実用的な仕様を生み出せるかどうかだ。NISTは、その取り組みで研究、ガイダンス、その他の成果物を開発すると述べた。企業は、ベンダーをまたいで機能するフォーマットを注視すべきである。
有用なアイデンティティ仕様は、エージェントを所有者、目的、モデル、承認済みツールに結び付けなければならない。また、委任の過程で起点となるユーザーも保持すべきである。プラットフォームが互換性のない表現を採用すれば、ガバナンスは分断されたままになる。
2つ目のシグナルは、独立したセキュリティテストである。NISTの競技会では、テスト対象となったすべてのフロンティアモデルに対する攻撃の成功が確認されたが、組織には導入レベルでの評価が必要だ。テストには、モデル、ツール、権限、メモリ、外部データを含めるべきである。
比較テストでは、プロンプトインジェクションの成功だけでなく、それ以上を測定すべきである。エージェントがタスクの範囲を超えるか、正当なツールを誤用するか、長いワークフローの中に重要な操作を隠すかを検証すべきだ。また、復旧能力と監査品質もテストすべきである。
攻撃の成功率が低下する一方で、エージェントが有用な能力を維持できれば、意図を認識する制御への信頼は高まるでしょう。改善されたモデルがツールを多用する展開環境でも脆弱なままであれば、インフラ制御の重要性はさらに増します。
3つ目のシグナルは、パイロット導入後の企業の行動です。セキュリティチームは、固有のアイデンティティ、限定された認証情報、明確な責任者を付与されたエージェントの数を追跡すべきです。また、放棄されたエージェントや未レビューの権限も測定する必要があります。
導入数だけでは、ほとんど何も分かりません。企業は数千のエージェントを導入しながら、それらを読み取り専用かつ隔離された状態に保つことができます。本番環境への広範なアクセス権を持つ単一のエージェントの方が、その集団全体より大きなリスクを抱える可能性があります。
インシデント報告は、もう一つの現実的な検証材料になります。公表される事例では、障害がプロンプトインジェクション、過剰な権限、アイデンティティの混同、あるいは承認境界の欠如のどれに起因したのかを説明すべきです。こうした詳細がなければ、業界は防御策を比較できません。
セキュリティリーダーは、パイロットを拡大する前に、次のような直接的な質問をするべきです。
すべてのエージェントに固有のアイデンティティと説明責任を負う所有者がいるか？
タスク終了時に権限を自動的に失効させられるか？
ログには、要求した人物と実行したエージェントの両方が保持されるか？
どのツールが取り消し不可能な変更を作成できるか？
外部コンテンツがそれらのツール呼び出しに影響を与え得るか？
どの程度のアクション量でレビューまたは停止を発動するか？
対応担当者は、プラットフォーム全体を止めずに1つのエージェントを無効化できるか？
委任されたエージェントは、元のタスクによって制約されているか？
ポリシーサービスが利用できない場合、システムはフェイルクローズするか？
監査担当者は、なぜ機微なアクションが発生したのかを再構築できるか？
これらの質問は、「根底から覆す」という主張を実装テストへと変えます。プラットフォームが答えられないなら、そのZero Trustの言葉遣いは不完全なままです。答えられるなら、アーキテクチャはすでに適応を始めている可能性があります。
最も重要な結論は、組織がZero Trustを放棄すべきではないということです。むしろ、それをより小さく、より動的な権限単位へ適用すべきです。すべてのエージェント、ツール呼び出し、委任、そして重要な結果を伴うアクションには、それぞれ固有のポリシーコンテキストが必要です。
このアプローチには摩擦が伴います。一部の自動化タスクでは、より限定的なツールや人間による確認が必要になります。チームがインベントリとライフサイクル制御を構築する間、一部のパイロットは遅くなるでしょう。
代替策は、見えない権限です。エージェントは広範な人間の権限を継承し、信頼できないコンテンツを処理し、不完全な記録を残します。セキュリティチームは、インシデントの後になって初めて自律型ワークフローを発見することになります。
エージェント型AIはZero Trustを打ち負かしたわけではありません。多くのZero Trustプログラムが認証、ネットワークアクセス、デバイスポスチャで止まっていたことを浮き彫りにしたのです。次のバージョンでは、認証済みのマシンが何を実行すると判断するかを統制しなければなりません。
したがって、Google Newsを通じて提起された問いは、見出しがその逆転を誇張しているとしても、検討し続ける価値があります。組織は、エージェントの次のアクションが実行される前に、そのアイデンティティ、目的、根拠、権限を追跡できるでしょうか？
まずは1つの本番ワークフローから始め、その連鎖を最初から最後まで再構築してください。どこかの引き継ぎが見えなくなった場合は、それを制御上のギャップとして扱うべきです。この演習は、別のセキュリティ用語を採用するよりも価値があります。なぜなら、Zero Trustが実際の業務を通じてエージェントに追従しているかを検証できるからです。
