AIエージェントに必要なのは、ゲートウェイより先にアイデンティティだ

Hush SecurityはGoogle Newsで、企業はAIエージェントの通信にゲートウェイを設ける前に、各エージェントを識別する必要があるという明確な主張を打ち出した。この対立が重要なのは、多くのエージェントが依然として人間の権限を借用したり、認証情報を共有したりしているためだ。ゲートウェイは接続を検査できるが、すべての呼び出し元が同じに見える状況では、説明責任を確立できない。

この主張は、Hush Securityが2026年7月に発表した資金調達と、非人間アイデンティティ・プラットフォームの拡張に続くものだ。同社は3,000万ドルを調達し、エージェントの発見、アイデンティティの付与、限定的なアクセスの仲介、行動の記録を目的とするIdentity Gatewayを発表した。その中心的な考え方は単純である。セキュリティ制御は、どのエージェントが行動しているかを把握するまで、エージェントを確実に統制できない。

この立場は、企業向けAIで広がりつつあるゲートウェイ優先のアプローチに異議を唱えるものだ。Cisco、Palo Alto Networks、Microsoftなどのセキュリティベンダーは現在、エージェントとツールの間に制御を配置している。しかしゲートウェイが把握するのはリクエストであり、その背後にある完全なアイデンティティ、所有者、委任された権限、実行履歴とは限らない。その結果、見慣れたセキュリティ境界の中に、これまでにない帰属の問題が生じる。

これはゲートウェイの必要性をめぐる議論ではない。ゲートウェイは、認証、ポリシーチェック、トラフィック検査、ツール制限の有用な実施地点であり続ける。問われているのは、企業がそこを通過するすべての主体に固有の認証情報を発行する前に、検問所を設置しているのではないかという点だ。

Google Newsの見出しが示す、より大きなアイデンティティの転換

Hush Securityは、ゲートウェイだけでは解決できないアイデンティティの問題としてAIエージェントのセキュリティを再定義している。

同社は2025年、非人間アイデンティティに焦点を当ててステルス状態から姿を現した。これには、従業員ではなくソフトウェアが使用するサービスアカウント、APIキー、アクセストークン、その他の認証情報が含まれる。Hushが当初取り組んだのは、組織がインベントリ化、ローテーション、失効を困難とするマシン認証情報を蓄積しがちだという、長年にわたる企業課題だった。

自律型エージェントは、その重要性をさらに高める。エージェントは、指示を解釈し、ツールを選択し、データを取得し、1つのタスクの中で複数のシステムにまたがる操作を実行できる。従来の自動化はあらかじめ決められた手順に従う。一方、エージェントは新たな情報を受け取った後に経路を変えられるため、実効的な権限を予測しにくい。

VentureBeatは7月30日の報道で、Hushが先行する取り組みをagent identity gatewayへと拡張していると説明した。このプラットフォームは、エージェントと企業リソースの間に位置する。Hushによれば、エージェントを発見し、人間の所有者に結び付け、タスク固有のアクセスを発行し、活動を記録し、エージェントを一元的に失効させることができるという。

Hushはこのアクセスモデルを「least agency」と呼ぶ。この用語は、ユーザーまたはワークロードにタスクに必要なアクセスのみを与える最小権限のセキュリティ原則を、エージェント向けに応用したものだ。Least agencyでは、その判断にエージェントの目的、実行コンテキスト、委任された権限を加える。

例えば、本番環境のエラーを診断するよう依頼されたコーディングエージェントを考えてみよう。ログ、ソースコード、デプロイメントのメタデータへの読み取りアクセスは必要かもしれない。しかし、請求記録の変更、顧客データベースのダウンロード、自身のセキュリティポリシーの書き換えまで、自動的に許可されるべきではない。

同じ区別は生産性向上エージェントにも当てはまる。会議のブリーフィングを作成するアシスタントは、カレンダー、ノート、承認済みの文書を検索するかもしれない。だが、それを起動した従業員が利用できるすべてのメールボックス、クラウドドライブ、管理コンソールへの無制限のアクセスは必要ない。

ゲートウェイは、禁止された宛先や不正な形式のリクエストを遮断できる。しかし、複数のエージェントが同じOAuthトークンまたはサービスアカウントを使用すると、そのポリシーは大まかなものになる。承認済みの認証情報がファイルを要求したことは分かるかもしれないが、どのエージェントが要求したのか、なぜ行動したのか、その行動が元の委任の範囲内だったのかまでは分からない可能性がある。

これが、Google Newsの見出しが一般的な資金調達記事以上の重みを持つ理由だ。Hushは単に新たな検査レイヤーを追加しているのではない。エージェントの所有者、目的、権限、セッション、行動を記録する基盤として、アイデンティティを位置付けるべきだと主張している。

このモデルはインシデント対応も変える。セキュリティチームは通常、誰がリソースにアクセスしたのかを問うところから調査を始める。共有認証情報では、答えがアプリケーション、従業員、サービスアカウントにまでしか絞り込めないことがある。個別のエージェントアイデンティティは、特に複数の自律プロセスが1人の権限の下で動作する場合、より限定的な調査の出発点を提供する。

共有認証情報はゲートウェイに推測を強いる

ゲートウェイがポリシーを実施できる精度は、各リクエストに付与されたアイデンティティとコンテキストの精度に依存する。

初期の企業向けエージェントの多くは、スクリプトと同様にデプロイされた。開発者はAPIキーを保存し、サービスアカウントを割り当て、あるいは人間のユーザーのOAuthトークンをそのまま渡した。この方法ならプロトタイプを迅速に動かせるが、複数の主体が1つのセキュリティアイデンティティに集約されてしまう。

従業員、エージェントホスト、モデル、個別エージェント、ツールセッションはいずれも、同じ認可の下で表示され得る。エージェントがサブエージェントを作成すれば、その連鎖の再構築はさらに難しくなる。下流サービスは、有効なトークンを受け取っても、どのコンポーネントがその操作を開始したのかを把握できない可能性がある。

VentureBeatが2026年6月に実施した企業回答者107人の調査では、69％がエージェント導入で共有APIキーを使用していた。同社のagent security researchでは、82％が主にモデルプロバイダーまたはハイパースケーラーが提供する制御に依存していることも分かった。

これらの制御は有用な保護を提供する。プロンプトフィルターは既知のインジェクションパターンを検出でき、データ損失防止システムは機密コンテンツを検出でき、クラウドポリシーは管理対象リソースへのアクセスを制限できる。しかし、これらの機能が各エージェントインスタンスに固有のアイデンティティを自動的に作成するわけではない。

この調査では、回答者におけるMicrosoft Entra Agent IDの導入率は13％だった。その他のアイデンティティ特化製品はいずれも一桁台にとどまった。この差は、企業がエージェント固有の説明責任よりも、一般的なAI保護を速く導入してきたことを示唆している。

エージェントに過剰な権限が与えられると、この不均衡はさらに深刻になる。共有された管理者認証情報は、ゲートウェイが監視しているからといって安全になるわけではない。ポリシーがその認証情報による操作を許可している場合、ゲートウェイは技術的には有効な危険なリクエストを承認する可能性がある。

プロンプトインジェクションはこの問題をよく示している。エージェントは、機密資料の取得や設定変更を指示する、信頼できないテキストを読み込むかもしれない。この指示は、文書、ウェブサイト、メール、ツール応答、データベースレコードを通じて入り込む可能性がある。その後、言語フィルターは正当な意図と操作された意図を見分ける難しい課題に直面する。

アイデンティティ制御は異なるレイヤーに対応する。すべての文が悪意あるものかを判断する必要はない。モデルが何を判断したかにかかわらず、エージェントが利用できる最大権限を制限できる。

例えば、読み取り専用アクセスを持つリサーチエージェントは、敵対的な指示に遭遇してもソースリポジトリを削除できない。一時的なサポートエージェントは、チケットが終了した後に顧客データへのアクセスを保持できない。支払いの下書きを作成する権限を持つ財務エージェントは、ポリシーが両方の操作を許可しない限り、その支払いを承認することもできない。

短命な認証情報は、露出をさらに抑える。再利用可能なシークレットをエージェント環境に置く代わりに、アイデンティティシステムは、単一のタスク、リソース、時間枠に対するトークンを発行できる。トークンは自動的に失効し、セッション終了時に取り消すこともできる。

このモデルは、より優れたログも支える。監査記録には、エージェント、人間のスポンサー、タスク、ポリシー判断、使用された認証情報、実行結果を記録すべきだ。ゲートウェイリクエストだけを記録しても、インシデント後に調査担当者が推測しなければならないことが多すぎる。

企業はすでに、重要な人間の活動を管理する際にコンテキストを保持している。ユーザー、デバイス、アプリケーション、セッション、認証方法、リソースを記録する。自律ソフトウェアは、人間のレビューのために停止することなく多数の操作を実行できるため、少なくとも同程度の詳細が必要だ。

課題は規模にある。組織は従業員を採用するよりも速く、エージェントを作成、複製、終了できる。そのため、アイデンティティのプロビジョニングは自動化されなければならない。手動登録では遅延が生じ、回避策を促し、ガバナンスの対象外となるシャドーエージェントを残してしまう。

この圧力により、ライフサイクル管理が不可欠になる。各エージェントアイデンティティには、作成イベント、所有者、承認された目的、ポリシーセット、有効期限ルール、失効経路が必要だ。これらのいずれかが未定義のままであれば、ゲートウェイは組織が完全には説明できない主体からのトラフィックを受け取ることになる。

ゲートウェイはトラフィックを制御するが、アイデンティティが権限を確立する

最も強固なアーキテクチャでは、アイデンティティを権限の源泉とし、ゲートウェイをその権限を実施する場所の一つとして扱う。

AIゲートウェイは通常、モデル、エージェント、ツール、データサービス間の通信を仲介する。接続の認証、リクエストの検査、レート制限の適用、コンテンツのフィルタリング、ログの生成を行える。MCPゲートウェイは、Model Context Protocol接続に対して同様の役割を果たす。

MCPは、AIアプリケーションが共通のインターフェースを通じて外部ツールを検出し、呼び出せるようにするオープンプロトコルだ。カスタム統合コードの必要性を減らす一方で、標準化された接続はエージェントが到達可能な範囲を広げる可能性もある。

ゲートウェイが有用なのは、中央のポリシーチェックポイントを提供するからだ。セキュリティチームは、各バックエンドを変更する代わりに、多数のツールの前にルールを配置できる。しかし、このアーキテクチャ上の利便性は、エージェントが誰なのか、またその権限がどこに由来するのかという問いには答えない。

アイデンティティがその基盤を提供する。固有のアイデンティティは、エージェントをそのコード、ホスト、所有者、タスク、承認済みの能力に結び付けられる。その上で認可は、現在の条件下でそのアイデンティティに何が許可されるかを判断できる。

この違いは空港の検査場に似ている。すべての旅行者を審査することには価値があるが、そのプロセスは、誰が各書類を提示しているかを把握していることに依存する。アイデンティティを確立せずに手荷物を検査しても、セキュリティ記録は不完全なままだ。

米国国立標準技術研究所は、2026年により広い枠組みの中で同じ構成要素を位置付けた。agent identity projectでは、エージェントの識別、認可、委任、ログ、透明性、データ来歴を相互に関連する取り組みの領域として挙げている。

NISTはまた、単一の独自ソリューションを提案するのではなく、既存技術を示した。OAuthは委任された認可を伝達でき、OpenID Connectは認証済み主体に関する情報を表現でき、SCIMはアイデンティティのプロビジョニングを支援できる。SPIFFEとSPIREは、ソフトウェアワークロードに暗号学的に検証可能なアイデンティティを発行できる。

これらの技術は、問題の異なる部分を解決する。OAuthはトークンがどのようなアクセスを伝えるかを示す。OpenID Connectは認証済み主体の説明に役立つ。SCIMはアイデンティティレコードの作成や無効化を行える。SPIFFEは、管理されたインフラ上で動作するワークロードが、それが主張するワークロードであることを証明できる。

しかし、これらのいずれも単独では、自律型エージェントのライフサイクル全体を捉えられない。企業は依然として、ワークロードアイデンティティを人間による委任、ポリシー、タスク範囲、行動履歴と結び付ける必要がある。

その欠けている接続が、単にエージェントに名前を割り当てるだけでは不十分である理由を説明している。リクエスト内で自己申告された識別子は変更やコピーが可能だ。信頼できるアイデンティティは、受信側サービスが受け入れるシステムによって発行または検証されなければならない。

アイデンティティは、インフラをまたいで移動しても維持される必要がある。エージェントはデスクトップアプリケーション、クラウドコンテナ、開発環境、マネージドプラットフォーム、サードパーティーサービスで動作し得る。単一のクラスターだけに根ざした認証情報は、エージェントが組織境界を越えると意味を失う可能性がある。

OpenID Foundationのエージェント・アイデンティティ管理に関する論文は、このポータビリティの課題を説明している。同論文は、MCPクライアント識別子が必ずしも信頼できるワークロードまたはエージェントのアイデンティティではないと指摘する。また、エージェントが信頼ドメインをまたぐと、インフラベースのアテステーションがより困難になることも説明している。

この問題は、認証とエージェンシーを分ける。認証は、ソフトウェアコンポーネントが認証情報を管理していることを確立する。エージェンシーは、そのコンポーネントがなぜ行動するのか、誰のために行動するのか、そして現在どのような委任権限を保持しているのかを示す。

ゲートウェイには両方の情報が必要だ。未検証の呼び出し元を拒否すべきである一方、委任されたタスクの範囲を超える検証済みエージェントも拒否すべきだ。認証に通過したことが、スポンサーとなるユーザーに許可されたあらゆる操作を実行する権限になってはならない。

Hushのアプローチでは、リソースアクセスの前段にポリシー駆動型のアイデンティティ仲介を置く。ゲートウェイは、その仲介された権限を強制する仕組みとなる。この順序は、トラフィックから最初にアイデンティティを発見するゲートウェイよりも、より限定的な権限と明確な帰属を支える。

このアーキテクチャは依然として統合に依存する。アプリケーションとツールサーバーは、受け取ったアイデンティティクレーム、スコープ、またはケイパビリティトークンを尊重しなければならない。下流システムがすべてのリクエストを一つの特権バックエンドアカウントに集約すると、アイデンティティ記録は強制力としての価値を失う。

セキュリティベンダーは同じ制御点へと収束している

市場はエージェント・アイデンティティへと向かっているが、アイデンティティ、ネットワークトラフィック、エンドポイントの挙動のどれを強制の起点とすべきかについて、ベンダー間で見解は異なる。

Hushだけが、エージェントを新たな非人間アクターの分類として扱っているわけではない。Microsoft、Cisco、Palo Alto Networks、1Password、Okta、Ping Identity、そして複数のスタートアップが、エージェントに焦点を当てたアイデンティティまたはガバナンス機能を導入している。

CiscoのDuo Agentic Identityは、人間の所有者に紐づく個別オブジェクトとしてエージェントを登録する。より広範な同社のセキュリティアーキテクチャでは、MCPゲートウェイを介してツール呼び出しをルーティングできる。Palo Alto Networksは、エージェントレジストリ、エージェント向けアイデンティティプロバイダー、そしてPrisma AIRS内のゲートウェイ制御を提示している。

Microsoftは、Entra、Purview、Defender、Sentinelにまたがってエージェントガバナンスを提供している。Entra Agent IDは、エージェントのアイデンティティ作成とガバナンスに重点を置く。Microsoftの他サービスは、データ制御、脅威検知、監視に対応する。

CrowdStrikeはエンドポイント上のアクティビティを重視する。このアプローチは、モデルが表明した意図だけに依存するのではなく、ソフトウェアプロセスがデバイス上で何を行うかを追跡する。認証成功後のファイル変更、プロセス起動、その他の具体的な操作を検出する助けになり得る。

こうした異なる経路は補完的である一方、主要な制御プレーンの座を争っている。アイデンティティベンダーは、すべての操作が信頼されたアクターとスコープ設定済みの権限から始まるべきだと主張する。ネットワークベンダーは、ゲートウェイを中心的な検査点と見る。エンドポイントベンダーは、観測可能な実行に焦点を当てる。

RSAC 2026は、これらのカテゴリーがどれほど急速に収束しているかを示した。VentureBeatによるエージェントセキュリティフレームワークのレビューでは、大手ベンダーがレジストリ、ゲートウェイ、アイデンティティオブジェクト、ランタイム監視を導入していたことが確認された。

残るギャップは、単一の制御だけでは不十分である理由を示している。エージェントはすべての認証情報チェックを通過しても、自身の挙動を統治するポリシーを変更する可能性がある。ゲートウェイは各ツール呼び出しを確認できても、委任チェーンを再構築できない可能性がある。エンドポイントセンサーは、エージェントに有効な業務上の権限があったかを知らずに操作を観測する場合がある。

マルチエージェントの委任は、最も難しいケースを生み出す。たとえば、調達エージェントが調査エージェントにサプライヤー比較を依頼するとする。その後、調査エージェントはブラウジングエージェントを作成し、ブラウジングエージェントがサードパーティーサービスへ文書を要求する。

各引き渡しでは、権限を縮小または維持すべきであり、暗黙のうちに拡大してはならない。最終サービスは、誰がタスクを開始したか、どのエージェントが関与したか、要求された操作が元の目的に適合するかを判断できる十分な証拠を必要とする。

従来のユーザーなりすましは、この場面で十分に機能しない。すべての子エージェントが従業員のアイデンティティを継承すると、下流システムは元のユーザーと自律的な委任先を区別できない。侵害された子エージェントを一つ無効化するだけでも、ユーザーセッション全体を終了する必要が生じる可能性がある。

より良いモデルでは、署名付きの委任チェーンを維持しつつ、各エージェントに固有のアイデンティティを与える。子エージェントは、割り当てられた業務に必要な権限のサブセットだけを受け取る。ログは、人間の所有者、親エージェント、子エージェント、そして結果として生じた操作の関係を保存する。

この構造は、安全なクラウドワークロードが短命な認証情報を交換する方法に似ている。しかしエージェントには、不確実な挙動と自然言語による目標が持ち込まれる。ポリシーは、技術的なアイデンティティと変化するタスクコンテキストの両方を考慮しなければならない。

実用的な統合問題も存在する。企業はすでに、アイデンティティプロバイダー、特権アクセスシステム、APIゲートウェイ、サービスメッシュ、エンドポイントエージェント、セキュリティ監視プラットフォームを運用している。独立したエージェント・アイデンティティ層を追加すれば、新たなコンソールと信頼の情報源が生まれる可能性がある。

成功するアプローチは、既存のアイデンティティ基盤と接続する必要がある。すべてのアプリケーションに独自プロトコルの採用や、従業員ディレクトリの重複管理を求めるシステムには、セキュリティチームは抵抗するだろう。

この圧力は、標準ベースのクレーム、短命なトークン、ポータブルな監査記録を後押しする。また、正式な登録を求める前にシャドーエージェントを発見できる製品にも有利に働く。

従業員はセキュリティ承認なしにコーディング支援ツールをインストールしたり、ローカルエージェントを接続したりできるため、発見は重要だ。組織が存在を知らないエージェントに対しては、完璧なアイデンティティポリシーも何の役にも立たない。ネットワーク、エンドポイント、クラウド、アイデンティティのテレメトリーはすべて、そうした導入の発見に寄与する。

したがって、市場の収束はHushの前提を支持する一方で、すべての製品主張を裏付けるものではない。アイデンティティは不可欠になりつつあるが、ゲートウェイ、サンドボックス、エンドポイント監視、データ制御と並行して機能する。真の競争は、どの層が権威ある記録を定義するかに関わる。

アイデンティティがエージェントを安全にするわけではない

検証済みのアイデンティティは制御性と説明責任を改善するが、エージェントの挙動が信頼できることを証明するものではない。

この制約は、アイデンティティ優先の論調に対する最も強い課題である。認証されたエージェントであっても、不適切な判断を下し、悪意ある指示に従い、データを漏えいさせ、危険なツールを呼び出す可能性がある。アイデンティティは、防御側に誰が行動したかを伝える。それは、その行動が適切だったことを保証しない。

従来のセキュリティは警告を与えている。攻撃者が認証情報を盗み、従業員に過剰なアクセス権が与えられ、承認済みソフトウェアが予期せず動作するため、正当なアカウントが多くの重大インシデントを引き起こしている。有効なアイデンティティは、ポリシー判断の出発点にすぎない。

エージェントシステムは、実行中に計画が変わる可能性があるため不確実性を加える。モデルは新しい情報を読んだ後、別のツールを選択するかもしれない。制約を誤解したり、信頼できないコンテンツを指示として扱ったりする可能性もある。

このため、サンドボックス化は依然として重要だ。サンドボックスは実行を隔離し、侵害または誤作動したエージェントがホストシステムに自由に影響を及ぼすことを防ぐ。アイデンティティは許可されたリソースを制限でき、隔離はプロセスが技術的に到達できる範囲を制約する。

プロンプトと出力の制御も役割を維持する。リクエストが別のシステムに到達する前に、既知の攻撃パターン、機密データ、禁止コンテンツを検出できる。その弱点は、意味的解釈を唯一の防御として扱う点にある。

完全なアーキテクチャには、多層防御が必要だ。アイデンティティ層はアクターと委任された権限を確立する。ゲートウェイは接続ポリシーを強制する。サンドボックスは実行を制限する。エンドポイントとクラウドの監視は実際の挙動を記録する。データ制御は機密情報を制限する。

ポリシーエンジンは、エージェントの制御外に維持されなければならない。エージェントが自身の権限を定義するルールを編集できる場合、有効なアイデンティティは被害を防ぐことなく、調査者がその被害を帰属させる助けになるだけかもしれない。

認証情報の保護も別のリスクをもたらす。すべてのエージェントに固有の長期シークレットを渡せば帰属は改善するが、攻撃者が盗めるシークレットの数も増える。アイデンティティシステムは短命な認証情報を発行し、再利用可能なシークレットをエージェント環境の外部に保持すべきだ。

組織は恒久的なエージェントの乱立も避ける必要がある。アイデンティティの自動作成は有用だが、非アクティブなアイデンティティには自動的な有効期限が必要である。さもなければ、企業は管理されていないAPIキーを管理されていないエージェントアカウントに置き換えるだけになる。

人間の所有権も誤解を招く可能性がある。エージェントを従業員に対応付けても、その従業員がすべての操作をレビューしたことを意味しない。説明責任の記録では、スポンサーシップ、承認、運用、実行を区別すべきだ。

管理者がワークフローを承認し、開発者がエージェントをデプロイし、別の従業員がタスクを開始する場合がある。この3つの役割を一つの「所有者」フィールドに圧縮すると、誤った確実性が生じかねない。

データ来歴にも同様の注意が必要だ。エージェントは、文書、生成テキスト、ツール応答、記憶されたコンテキストを組み合わせることがある。セキュリティログは、必要以上に機密コンテンツを収集することなく、重要な操作にどの情報が影響したかを保存すべきだ。

ナレッジワーカーにとって、この問題はサイバーセキュリティを超えて広がる。エージェントはますます、個人メモ、プロジェクト文書、トランスクリプト、過去の意思決定に基づいて行動する。適切に整理されたパーソナルナレッジベースはコンテキストを改善できるが、アクセスには依然として明確な境界が必要だ。

週次更新を準備するエージェントには、選択されたプロジェクト記録が必要な場合がある。すべての情報が一人のユーザーに属しているというだけで、すべての個人メモへの無制限アクセスを継承すべきではない。アイデンティティとタスクスコープは、有用なコンテキストと不要な露出を分ける助けになる。

したがって、Hushの主張には本番環境での独立した検証が必要だ。購入者は、そのシステムがエージェントインスタンスを暗号学的に識別するか、既存のアイデンティティプロバイダーと統合するか、下流ツールにアイデンティティを伝播させるかを確認すべきである。

また、失効の速度、ポリシー障害時の挙動、委任追跡、ログの完全性もテストすべきだ。ツール呼び出し中にコンテキストを失ったり、障害時に広範なアクセスをデフォルトにしたりする制御プレーンは、削減を約束するリスクを再現しかねない。

同社の資金調達と製品発表は、市場の意図を示すものであり、測定されたセキュリティ成果を示すものではない。公開されている証拠は、同プラットフォームがあらゆるデスクトップ、クラウド、マネージドエージェント環境でどのように機能するかをまだ示していない。

この不確実性は、アイデンティティ優先のアーキテクチャを否定するものではない。製品を評価すべき基準を定義するものである。有用な問いは、ダッシュボードがエージェントを一覧表示しているかではない。アイデンティティがそのエージェントの権限を一貫して制限し、帰属させ、終了させられるかどうかだ。

Google Newsの読者が次に注目すべきこと

エージェント・アイデンティティが実際のインフラとなるのか、それともセキュリティマーケティングのカテゴリーにとどまるのかを示すシグナルは3つある。

最初のシグナルは、本番環境における固有アイデンティティの採用だ。セキュリティチームは、発見または登録されたエージェント数だけを見るべきではない。意味のある指標は、共有認証情報や無制限の人間用トークンの利用をやめたアクティブなエージェントがどれだけいるかである。

変化の証拠としては、短命な認証情報、タスク単位で限定されたアクセス、自動失効、そしてエージェント識別子を保持する下流サービスなどが挙げられる。共有キーが依然として一般的であれば、ゲートウェイの導入だけでは説明責任のギャップは解消されない。

企業が共有サービスアカウントの減少と、より取り消し可能なエージェントセッションの増加を報告すれば、このシグナルはアイデンティティ優先の主張を強める。逆に、実行時アクセスが変わらないままアイデンティティ製品がインベントリダッシュボードにとどまるなら、この主張は弱まる。

2つ目のシグナルは、委任チェーンへの対応である。エンタープライズ向けエージェントは、サブタスクを作成し、専門エージェントを呼び出し、組織の境界を越える場面が増えていく。製品は、そうした引き継ぎをまたいで権限を保持しなければならない。

信頼できる実装では、最初の人間のスポンサー、関与したすべてのエージェント、移転された権限、そして実行されたアクションを示せる必要がある。各子アイデンティティに与えられる権限は、親が委任可能な範囲を超えてはならない。

こうした関係を表現する相互運用可能な手段について、標準化団体やベンダーの動向を注視すべきだ。独自仕様の委任記録は単一プラットフォーム内では機能するかもしれないが、企業は複数のプロバイダーのエージェントを利用する。ベンダー環境の外でもアイデンティティが維持されるかどうかは、クロスプラットフォームでの検証によって決まる。

MCPツール、エージェントプラットフォーム、アイデンティティプロバイダーが検証可能な委任証跡を交換できれば、このシグナルは論旨を強める。すべてのプラットフォームが境界でエージェントを通常のユーザートークンへ変換してしまうなら、論旨は弱まる。

3つ目のシグナルは、インシデント封じ込めである。エージェントが誤動作したり侵害されたりしたとき、アイデンティティの重要性は最も高まる。ベンダーは、従業員、アプリケーション、あるいはワークフロー全体を停止することなく、防御側が単一のエージェントを隔離できることを示す必要がある。

有用なテストには、即時失効、既存セッションの拒否、子エージェントの遮断、アクションチェーンの再構築が含まれる。組織は、アイデンティティ基盤が利用不能になった場合でも、ポリシー適用が安全側に失敗することを確認すべきである。

セキュリティチームは、アイデンティティシステム、ゲートウェイ、エンドポイント、下流アプリケーションのログを比較すべきだ。これらの記録を相関付けられないなら、企業はいまだインシデントに関する信頼できる一元的な記録を持っていない。

成功は、エージェントアイデンティティが可視性だけでなく結果を変えることを示し、Hushの立場を強化する。認証済みでありながら封じ込められないエージェントが関与するインシデントが繰り返されれば、市場がアイデンティティを単独の防御策として過大評価していたことを示すだろう。

Google Newsの枠組みは、概ね正しい順序を示している。企業は、ゲートウェイを十分なガバナンスとみなす前に、エージェントが誰であるか、誰の権限を持つのか、その権限がいつまで有効なのかを確立すべきである。

次のステップは実践的だ。稼働中のエージェントを1つ選び、作成から最後のツール呼び出しまで監査してほしい。チームは、その所有者、タスク、認証情報、権限、サブエージェント、データアクセス、失効経路を特定できるだろうか。いずれかの答えが共有トークンやトラフィックからの推論に依存しているなら、アイデンティティ基盤の準備が整う前にゲートウェイが導入されたことになる。