VentureBeatの調査で、企業の54%がAIエージェントのセキュリティインシデントを経験している一方、依然として大多数が認証情報を共有していることが判明
更新日：7月20日
VentureBeatによると、企業の54%がAIエージェントのセキュリティインシデントまたはニアミスを経験しているにもかかわらず、大半の導入環境では依然として共有認証情報に依存しています。この結果は、従業員数100人超の107組織を対象に2026年6月に実施された調査に基づいています。
この主要数値は、本来区別すべき2つのカテゴリーをまとめたものです。回答者の18%が確認済みのインシデントを報告した一方、36%は被害が発生する前に阻止されたニアミスを報告しました。この違いを考慮しても、エージェント関連のセキュリティ障害が仮説上の脅威モデリングの段階を超えたことを結果は示しています。
より根深い対立は、エージェントの自律性と企業による統制の間にあります。企業はエージェントを本番データ、ソフトウェアツール、業務ワークフローに接続しています。しかし、すべてのエージェントに個別かつスコープを限定したアイデンティティを付与している企業はわずか32%で、最もリスクの高いエージェントをサンドボックス化している企業も30%にすぎません。
この組み合わせは、企業で一般的に見られる前提に疑問を投げかけます。多くのチームは、AIエージェントを既存のサービスアカウントを使用する別のアプリケーションとして扱っています。実際には、エージェントはツールを選択し、信頼できないコンテンツを解釈し、開発者が事前に列挙していなかったアクションを実行できます。
その結果、AIの問題の内側にアイデンティティの問題が組み込まれた状態が生じます。企業はソフトウェアにより大きな裁量を与える一方で、予測可能なプログラム向けに設計された認証情報の運用慣行を維持しています。セキュリティチームは今や、どのエージェントが行動したのか、誰の権限を使用したのか、そしてその権限がタスクに適合していたのかを判断しなければなりません。
VentureBeatのAIエージェントセキュリティ調査がアイデンティティのギャップを露呈
この調査で最も重要な発見は、インシデントが発生したことではなく、認証情報の設計がインシデントへの曝露と密接に連動していたことです。
エージェントセキュリティ調査によると、参加企業の18%がAIエージェントのセキュリティインシデントを確認しています。さらに36%がニアミスを経験し、合計で54%となりました。
42%はいずれのカテゴリーも報告しませんでした。残る少数のグループは、本番環境でエージェントを運用していないか、関連する事象を追跡していませんでした。したがって、この調査が示すのは限定された企業サンプルにおける自己申告の経験であり、すべての企業を対象に測定されたインシデント発生率ではありません。
調査では、69%の組織がエージェント群のどこかで認証情報を共有していることが判明しました。すべてのエージェントに専用の、スコープを限定して管理されたアイデンティティを付与していると回答した企業はわずか32%でした。スコープを限定したアイデンティティとは、承認されたタスクのみに権限が制限された個別のアカウントをエージェントが持つことを意味します。
認証情報の共有には複数の形態がありました。共通のAPIキーを使用するエージェントもあれば、人間またはサービスアカウントの認証情報を借用するエージェントもありました。48%は、一部のエージェントには個別のアイデンティティがある一方、多くのエージェントが引き続き認証情報を共有していると回答しました。
回答者は複数のアイデンティティパターンを選択できたため、これらの割合は重複しています。これらは相互排他的なグループではなく、混在した環境を表しています。ある企業では、本番エージェントにはスコープを限定したアイデンティティを使用しながら、実験用エージェントには開発アカウントの共有を許可している可能性があります。
こうした環境間の比較は、さらに示唆に富んでいます。何らかの認証情報共有を行っている組織では、74人の回答者のうち47人に当たる63.5%が、インシデントまたはニアミスを報告しました。すべてのエージェントにスコープを限定したアイデンティティがある場合、この割合は22人中9人に当たる40.9%でした。
この22.6パーセントポイントの差が示すのは関連性であり、共有認証情報がすべての事象を引き起こしたことの証明ではありません。すべてのアイデンティティでスコープを限定していたグループは、わずか22組織でした。企業規模、エージェント数、導入の複雑さ、報告体制の成熟度も結果に影響している可能性があります。
それでも、この関連性の背後にあるメカニズムには妥当性があります。共有認証情報は各エージェントが利用できる権限を広げ、問題発生後の追跡可能性を低下させます。セキュリティチームは、APIキーがアクションを実行したことを確認できても、どのエージェントが開始したのかを特定できない場合があります。
このリスクに高度な攻撃者は必要ありません。エージェントが文書を読み違えたり、注入された指示に従ったり、誤ったツールを選択したり、ユーザーの要求を誤解したりする可能性があります。複数のエージェントが同じ特権アカウントを使用していれば、1つの誤った判断によって、そのアカウントに付与されたすべての権限が行使されてしまいます。
共有キーは封じ込めも複雑にします。キーを失効させると、複数の正当なワークフローが一度に停止する可能性があります。どの本番プロセスがその認証情報に依存しているのかを予測できないため、チームがローテーションを先延ばしにすることもあります。
エージェントごとにアイデンティティを分離すれば、より明確な対応経路を構築できます。セキュリティチームは、侵害された1つのアイデンティティを無効化してその活動を調査し、影響を受けていないサービスを維持できます。また、エージェントが要求したアクションを、割り当てられた役割と照合することもできます。
この調査は、AIエージェントのセキュリティインシデントをアーキテクチャ上の問題として捉え直しています。企業は単に安全なモデルと安全でないモデルのどちらかを選んでいるのではありません。自律システムを、別の主体に発行された認証情報の背後に隠したままにすべきかどうかを決めているのです。
共有されたAIエージェントの認証情報がエラーをセキュリティ事象に変える
モデルのエラーは、エージェントが誤った判断を認可済みのアクションに変換できるとき、セキュリティ事象になります。
従来のチャットボットは通常、人間が確認するためのテキストを返します。AIエージェントはAPIの呼び出し、社内システムの検索、レコードの変更、コードの実行、後続ワークフローの起動が可能です。したがって、そのリスクはモデルの挙動と利用可能な権限の両方に左右されます。
アカウントの問題を解決するよう求められたサポートエージェントを考えてみましょう。チケットを読み、顧客データを取得し、返金を行い、企業の顧客管理プラットフォームを更新する可能性があります。各ステップには、テキストのみを扱うアシスタントには不要だったアクセス権が必要です。
ここで、そのチケットに間接的なプロンプトインジェクションが含まれているとします。これは、文書、Webページ、メッセージなど、エージェントが読み取るコンテンツ内に隠された悪意ある指示です。その指示は、承認された目標からエージェントを逸脱させようとします。
サポートエージェントが広範な特権を持つサービスアカウントを使用している場合、注入された指示は継承された権限を悪用できます。企業が共有認証情報を通じてすでにエージェントを認証しているため、モデルが認証を回避する必要はありません。
OWASPは、アイデンティティと権限の悪用をエージェント型アプリケーションのリスクの一つに位置付けています。そのフレームワークでは、目標の乗っ取り、ツールの悪用、メモリ汚染、予期しないコード実行も取り上げています。
これらのカテゴリーは相互に作用します。目標の乗っ取りは、エージェントが達成しようとする内容を変えます。ツールの悪用は、変更された目標に実行経路を与えます。過剰な権限や共有権限は、そのアクションが生み出し得る被害の大きさを決定します。
この相互作用は、モデルのガードレールだけでは防御全体を担えない理由を説明します。ガードレールは不審な入力を特定したり、許可されていない出力をブロックしたりできます。しかし、権限がエージェントの運用上の役割を超えているアカウントを、確実に補うことはできません。
アイデンティティ制御は別の問いに答えます。この特定のエージェントには何が許可されているのか、という問いです。効果的な制御では、エージェントを個別のアイデンティティに関連付け、そのアイデンティティの権限を制限し、各アクションの背後にある権限を記録します。
エージェントが作業を委任する場合、この違いは重要です。調整役のエージェントが、別のエージェントにソースコードの調査やチケットの更新を依頼することがあります。認証情報がプロンプト、メモリ、ツールの応答を通じて移動すると、受信側のエージェントが割り当てられた機能を超える権限を継承する可能性があります。
NISTは、この問題を未解決のセキュリティ優先事項として特定しています。そのエージェントアイデンティティに関する文書では、ソフトウェアエージェントの識別、認証、認可、監査、委任、人間による承認について検討しています。
これらの要件は確立されたゼロトラストの慣行に似ていますが、エージェントの挙動はさらなる複雑さをもたらします。エージェントは、タスクごとに異なる権限を必要とする場合があります。また、複数のシステムから情報を組み合わせることで、生成される出力の機密性が変化することもあります。
静的なサービスアカウントでは、このようなコンテキストへの対応が困難です。エージェントが1つのステップでしか権限を必要としない場合でも、固定された権限セットを付与するからです。短期間かつタスク固有の認可は、より厳格な代替手段となります。
このモデルでは、エージェントは定義されたアクションと期間に限定されたアクセス権を受け取ります。影響の大きい操作には、新たなポリシーチェックや人間による承認を必須にできます。認証情報はエージェントの環境に残り続けるのではなく、期限切れになります。
明確なアイデンティティは否認防止にも役立ちます。これは、組織がアクションを検証可能な実行主体および認可チェーンと関連付けられることを意味します。それがなければ、共有アカウントがファイルを変更したことは分かっても、どのエージェントが変更を要求したのかを調査担当者が特定できない可能性があります。
これは特に、知識集約型のワークフローで重要です。社内資料を調査するエージェントは、公開文書、機密ノート、顧客記録、ソースコードの境界をまたぐ可能性があります。モデルが技術的に正確な応答を生成した場合でも、権限設定の誤りによって情報が漏えいする可能性があります。
検索可能なリポジトリを構築する組織は、すべてを単一の無制限なインデックスに統合するのではなく、ソース単位のアクセス境界を維持すべきです。適切に管理されたAIナレッジベースは検索性能を向上させられますが、検索権限も引き続きユーザーとタスクに従う必要があります。
中心的な教訓は明快です。モデルの推論能力が向上しても、アイデンティティ制御の必要性は減りません。より高性能なエージェントはより多くのツールを使用できるため、すべてのアクションを制限し、追跡可能にする重要性が高まります。
企業の曝露が拡大する中、高リスクのエージェントをサンドボックス化している企業はわずか30%
アイデンティティはエージェントがアクセスすべき対象を制限し、サンドボックス化はそのルールが破られた場合の影響を制限します。
VentureBeatの調査では、最もリスクの高いエージェントをサンドボックス内に隔離している企業はわずか30%であることが分かりました。サンドボックスとは、コード、ファイル、ネットワークアクセス、システム変更を封じ込めるために設計された、制限付きの実行環境です。
サンドボックス化によってエージェントが信頼できるようになるわけではありません。モデルがミスをした場合、ツールが予期せぬ挙動をした場合、または攻撃者がワークフローを別の方向へ誘導した場合の影響範囲を縮小します。この制御は、予防的なフィルターがいつか何かを見逃すという前提に立っています。
調査では、企業規模に関する懸念すべき傾向も明らかになりました。報告されたインシデントまたはニアミスの割合は、従業員101～1,000人の組織では49%でしたが、1,000人を超える組織では63%に上昇しました。
同時に、高リスクエージェントのサンドボックス化率は、小規模なグループの35%から大企業の20%へと低下しました。より多くのシステムと高い統合複雑性を抱える組織ほど、多くの事象を報告しながら、封じ込めの利用率は低くなっていました。
この傾向は複数の要因によって生じる可能性があります。大企業では、古いアプリケーション、重複するアイデンティティシステム、多数のサービスアカウントを運用していることがよくあります。また、エージェントプロジェクトが、中央のセキュリティチームによる把握よりも速いペースで部門間に広がる場合もあります。
本番環境との統合は、隔離をさらに困難にします。コーディングエージェントには、リポジトリ、テストインフラストラクチャ、パッケージレジストリ、デプロイシステムへのアクセスが必要になる場合があります。すべての外部アクションをブロックするサンドボックスではワークフローが成立せず、無制限のアクセスでは封じ込めの目的が失われます。
現実的な答えは、単一の汎用サンドボックスではありません。組織には、エージェントの役割に合わせた境界が必要です。リサーチエージェント、コーディングエージェント、財務エージェント、カスタマーサポートエージェントが、同じ実行ポリシーを共有すべきではありません。
コーディングエージェントは、一時的なリポジトリブランチを備えたエフェメラルな環境で作業できます。テストは実行できても、コードのマージや本番環境の設定変更を行う権限は持たせないことができます。別途承認ステップを設けることで、デプロイを許可できます。
財務エージェントは、取引を送信せずに準備だけを行えます。そのサンドボックスでは、未知のネットワーク宛先へのアクセスを遮断し、ファイルのエクスポートを制限できます。人間の承認者は、実行前に受取人、金額、根拠となる記録を確認できます。
リサーチエージェントは、ローカルの機密情報や無関係な社内リポジトリへのアクセスを持たずに、承認済みの情報源を閲覧できます。ダウンロードしたコンテンツは、スキャンされ、管理されたツールで処理されるまでは信頼できないものとして扱われます。
これらの境界は、それぞれ異なる障害モードに対処します。ネットワーク制限は、データの持ち出しを防止できます。ファイルシステムの分離は、悪意のあるコードを封じ込めることができます。ツールの許可リストは、エージェントが割り当てられたタスクと無関係な機能を呼び出すのを防げます。
レート制限と取引上限は、さらなる保護層となります。これらは、エージェントが誤った操作を繰り返す速度を制限します。1件のレコードに影響するミスなら復旧可能ですが、同じミスが数千件のレコードに及べば、運用上のインシデントになります。
人間による承認も、慎重に配置する必要があります。低リスクのすべてのステップで承認を求めると、エージェントの価値の大部分が失われます。エージェントが不可逆的な操作を行った後にのみ承認を求めても、その制御に意味はありません。
有効なチェックポイントは、重大な結果を伴う境界の手前にあります。たとえば、外部メッセージの送信、コードの公開、データの削除、アクセス権の変更、資金の拠出などです。インターフェースには、実行予定の操作と、要求されている権限を表示する必要があります。
ログには、モデルの最終出力だけでなく、より多くの情報を記録する必要があります。調査担当者には、操作を開始したユーザー、エージェントの識別情報、モデルとポリシーのバージョン、ツールへのリクエスト、承認判断、その結果として生じたシステム変更が必要です。機密性の高いプロンプトにはマスキングが必要な場合もありますが、操作履歴は利用可能な状態に保たなければなりません。
セキュリティチームは、エージェントの有効な認証情報とツールアクセスを無効化するキルスイッチも維持すべきです。ダッシュボード上の切り替えだけでは、キャッシュされたトークンや委任されたセッションが失効したことを保証できないため、スイッチのテストが必要です。
したがって、封じ込めはモデルの設定ではなく、システム全体の特性です。これは、ランタイムインフラストラクチャ、認証情報の設計、ポリシーの適用、復旧手順に依存します。プロバイダーのフィルターはその設計を支援できますが、代替することはできません。
プロバイダーのガードレールが主流だが、エージェント専用セキュリティは依然として稀
AIエージェントは複数のモデル、クラウド、業務システムにまたがるリスクを生み出すにもかかわらず、企業は使い慣れたプラットフォーム制御に依存しています。
VentureBeatの調査では、現在の導入環境ではモデルプロバイダーおよびクラウドネイティブのセキュリティツールが主流であることが明らかになりました。回答者の51%がOpenAIのガードレールを利用しており、Google、Microsoft、Anthropicに関連する制御も上位に入りました。
AIエージェント専用のセキュリティ製品の導入は、非常に限定的でした。これは、企業が当初、エージェント向けの独立したセキュリティ層を構築または購入する代わりに、既存のプラットフォーム制御を拡張したことを示唆しています。
その選択は理解できます。プロバイダーの制御はモデルへのリクエストに近い位置にあり、プロンプト、出力、ツール定義、利用パターンを検査できます。また、初期導入に必要な統合作業も削減できます。
ワークフローが複数のプラットフォームを横断すると、その限界が現れます。企業のエージェントは、あるプロバイダーのモデル、別のクラウドのデータベース、サードパーティの検索サービス、複数の社内APIを使用する可能性があります。個々のモデルプロバイダーが、承認チェーン全体を把握することはできません。
プロバイダーの制御は、自社が運用するスタック部分にも重点を置きます。安全でないコンテンツや疑わしいツール呼び出しを特定できる場合はありますが、IDライフサイクル、データ分類、承認ポリシー、インシデント対応については、依然として企業が責任を負います。
各評価質問に回答した82人の回答者による平均満足度は、5点満点中4.2点でした。しかし、明確な過半数が、その後1年以内にツールを変更または追加する予定でした。
高い満足度とツールの変更予定は、必ずしも矛盾しません。現在のツールは試験導入では十分に機能していても、エージェント数と権限が増えるにつれて不十分になる可能性があります。また、回答者は個々の製品には満足していても、製品間の空白を懸念している可能性があります。
ツール市場だけを唯一の答えと見なすべきではありません。専用のセキュリティソフトウェアは、エージェントの検出、ポリシーの適用、ランタイム監視を改善できます。しかし、不明確な業務上の責任分担や、誰も従わない承認プロセスを解決することはできません。
独立した業界調査も、可視性の問題を裏付けています。2026年4月の企業エージェント調査では、組織の82%が自社環境内で未知のエージェントまたはワークフローを発見したと報告されています。
この調査はセキュリティベンダーの委託によるものであり、VentureBeatの調査とは回答者も定義も異なります。したがって、その65%というインシデント率を、同一集団を測定したかのようにVentureBeatの54%と統合すべきではありません。
それでも、両調査が示す方向性は一致しています。企業はエージェントの導入状況を完全には把握できておらず、セキュリティイベントの報告も多く見られます。サンプルが異なれば割合も異なりますが、いずれも成熟した制御環境を示してはいません。
Cloud Security Allianceの調査では、多くのエージェントがIDのグレーゾーンに位置しているとも指摘されています。エージェントは、人間のユーザーとしても、正式なマシンIDとしても完全には管理されていません。
この曖昧さは、複数の既存ベンダーに圧力をかけています。IDプロバイダーは、動的なエージェントIDと委任された権限をサポートしなければなりません。クラウドプラットフォームは、きめ細かなランタイム制御を提供する必要があります。モデルプロバイダーは、企業システム全体にわたるツールの動作を観測可能にしなければなりません。
セキュリティ情報およびイベント管理ベンダーは、別の課題に直面しています。従来のログは認証やAPI呼び出しを記録しますが、エージェントのタスク、委任された権限、推論のコンテキストまでは記録しない場合があります。有効なAPI呼び出しであっても、業務上は無効な操作である可能性があります。
エージェントセキュリティの専門ベンダーは、こうした空白を対象にできますが、購入者は相互運用性を求めるべきです。1つのモデルやオーケストレーションフレームワークでしか機能しない制御層は、新たな可視性のサイロを生み出す可能性があります。企業には、プロバイダーを変更しても維持されるポリシーが必要です。
また、専用ツールが成果を改善することを示す証拠も必要です。VentureBeatの調査は横断研究であるため、特定の製品がインシデントを減少させたかどうかは示せません。専用製品の導入数は、有意な比較を行うには少なすぎました。
このため、企業は短期的に厳しい現実に直面します。エージェントセキュリティというカテゴリーが確立するのを待つことはできませんが、ソフトウェアを追加購入するだけで、説明責任を持つIDや安全な実行境界が自動的に作られるわけでもありません。
当面の作業は、依然としてアーキテクチャに関するものです。エージェントを棚卸しし、責任者を定め、個別のIDを発行し、権限を絞り、実行環境を分離し、承認ポイントを定義します。ツールの選定は、これらの制御要件に基づいて行うべきです。
AIエージェントのセキュリティインシデント率54%という数字が証明していないこと
この調査は重大な警告シグナルですが、そのサンプルとカテゴリー定義から、企業の侵害率に関する普遍的な主張を導くことはできません。
この調査では、2026年6月の単一調査期間に107組織を対象としました。回答者は従業員数100人超の企業に勤務しており、サンプルは中堅企業に偏っていました。
参加者の42%は、従業員数251～1,000人の企業を代表していました。さらに25%は、従業員数101～250人の組織に勤務していました。業種別では、テクノロジーおよびソフトウェアが23%で最大のグループを占めました。
役割の構成も重要です。45%がAI購入の最終意思決定者、30%が提案者または影響力を持つ立場であると回答しました。管理職は回答者の43%を占めました。
これは確率標本ではなく、自己選択によるサンプルでした。結果は、参加企業から得られた方向性を示す証拠として解釈すべきです。米国のすべての企業について統計的に代表性のある推計を提供するものではありません。
合計54%という数字には、ニアミスも含まれます。ニアミスは、組織が問題を検出して阻止したことで、制御が機能したことを示す場合があります。これは、確認済みの侵害、データ損失、金銭的損害と同等ではありません。
同時に、ニアミスを除外すれば、重大な運用リスクが見えなくなります。阻止された試みや間一髪で回避されたエラーは、条件が異なれば成功していた可能性のある経路を明らかにします。ニアミスが繰り返されると、損害を伴うインシデントが発生する前に、脆弱な制御が露呈する可能性があります。
この調査では、各回答者が何をAIエージェントのインシデントとして数えたかは明確にされていません。ある組織は不正なデータアクセスを報告し、別の組織は失敗した本番環境での操作を数えている可能性があります。業界で一貫した定義は、依然として策定途上です。
報告体制の成熟度によって、企業間の見かけ上の比較が逆転する可能性もあります。詳細な監視を行う組織は、可視性の低い企業よりも多くのニアミスを発見する可能性があります。したがって、報告率の高さは、セキュリティの低さだけでなく、検出能力の高さを反映している場合があります。
認証情報に関する比較にも、同様の限界があります。共有認証情報を使用する組織では、より多くのインシデントが報告されましたが、この調査では、認証情報の共有と規模や複雑性を切り分けていません。エージェント数の多い企業は、より多くのキーを共有し、同時により多くのイベントを経験している可能性があります。
そのため、63.5%対40.9%という数字を因果的な保証として解釈すべきではありません。各エージェントにIDを与えても、プロンプトインジェクション、安全でないツール設計、侵害された依存関係、悪意ある内部関係者を防げるわけではありません。
個別のIDは、権限を絞り込み、帰属を明確にできるため、依然として有用です。これは基礎的な制御であり、完全なセキュリティプログラムではありません。サンドボックス化、監視、評価、承認、インシデント対応も引き続き必要です。
この調査は、プロバイダーネイティブのツールが効果を持たないことも証明していません。回答者は、それらに高い満足度を示しました。より妥当な結論は、プロバイダーの制御と、広範なIDおよび封じ込めの空白が併存しているということです。
企業は、高性能なモデルガードレールを使用しながら、脆弱なサービスアカウント運用を続けることがあります。また、高度な監視ソフトウェアを保有していても、高リスクの実行環境を分離していない場合があります。セキュリティの成果は、これらの制御がどのように連携するかに左右されます。
このニュアンスは重要です。恐怖心に駆られると、組織は誤った対応を取る可能性があるからです。一律禁止は、エージェントを未承認の利用へ追いやり、可視性をさらに低下させる可能性があります。一方、無制限の導入は、実験段階の前提を本番システムへ持ち込むことになります。
リスクベースのモデルは、より妥当な道筋を提供します。公開データを扱う読み取り専用エージェントと、顧客レコードや本番インフラストラクチャを変更できるエージェントには、異なる制御が必要です。権限は、障害発生時に起こり得る結果を反映すべきです。
組織は、エージェントの操作を可逆性と影響度に基づいて分類すべきです。公開文書の閲覧は、影響の小さい操作です。規制対象データの送信、アクセス権の変更、コードの実行、資金の移動には、より強力な承認が必要です。
また、モデル評価とセキュリティテストを分離する必要があります。評価では、エージェントがタスクを正しく完了できるかを測定します。セキュリティテストでは、悪意あるコンテンツや予期しない条件によって、そのタスクが別の方向へ誘導される可能性を検証します。
エージェントは社内ベンチマークで高得点を獲得しても、間接的なプロンプトインジェクションには失敗する可能性があります。逆に、ガードレールが過度に制限的なため、正当なリクエストを頻繁に拒否する場合もあります。どちらの結果も測定が必要です。
したがって、VentureBeatの数値はマーケティング資料ではなく、リスク登録簿に記載すべきものです。この数値は、実際の企業がエージェントの障害に直面している一方で、基本的な統制の整備状況にはばらつきがあることを示しています。ただし、この問題を解消する特定の製品やポリシーを示すものではありません。
企業がギャップを埋めつつあるかを示す3つのシグナル
AIエージェントセキュリティの次の段階は、ID管理のカバー率、封じ込め率、そして独立機関から報告された結果によって評価されます。
最初のシグナルは、一意の管理されたIDを持つ本番環境エージェントの割合です。企業は、新たに承認されたプロジェクトだけでなく、全エージェント群におけるカバー率としてこれを報告すべきです。現在の32%という水準から上昇すれば、ID管理プログラムがデプロイ担当チームまで浸透していることを示します。
より有力な指標は、ID管理のカバー率と権限の品質を組み合わせたものです。広範かつ恒久的なアクセス権を持つ一意のIDは、単に名前を変えただけのサービスアカウントにすぎません。改善には、適切に限定された権限、短期間のみ有効な認証情報、そして文書化された所有者情報が必要です。
IDベンダーやクラウドプラットフォームが、タスク単位の権限委譲をサポートするかどうかに注目してください。重要なのは、管理コンソールに新しい「エージェント」というラベルが追加されることではありません。1回のアクションに限定した権限を付与し、その権限をユーザーまたはポリシーまで追跡できることです。
NISTのエージェント標準化イニシアチブも、もう1つの指標となります。識別、認可、監査、安全な権限委譲に関する具体的なプロファイルが策定されれば、相互運用可能な企業向け統制の実現可能性が高まります。
2つ目のシグナルは、高リスクなエージェントにおけるサンドボックス化です。VentureBeatが示した30%という基準値によれば、重大な影響をもたらし得るデプロイの大半では、隔離が実施されているとの報告がありません。この割合が上昇すれば、組織が予防だけに全面的に依存するのではなく、障害の発生を前提に設計していることを示します。
購入者は、サンドボックスを利用できるというベンダーの主張だけで判断すべきではありません。重要なのは、実際に強制された境界内で稼働している本番環境エージェントがどれだけあるかです。セキュリティチームは、その境界が不正なネットワーク呼び出し、ファイル変更、認証情報へのアクセスを阻止できるかをテストすべきです。
テストには、間接的なプロンプトインジェクションや、侵害されたツールからの応答も含めるべきです。モデルが指示に従っている場合にしか機能しないサンドボックスでは、独立した封じ込め機能を提供できません。エージェントの目標がすり替えられた後でも、その境界が維持されなければなりません。
3つ目のシグナルは、今後の調査で、確認済みのインシデント、阻止された攻撃、モデルのエラー、ニアミスが区別されるかどうかです。分類が改善されれば、どの統制がビジネス上の被害を軽減し、どの統制が単に検知件数を増やしているだけなのかが明らかになります。
組織は可能な限り、匿名化したインシデントのパターンを公開すべきです。侵害されたツール、過剰な権限、認証情報の漏えい、承認の不備に関する教訓を共有することで、購入者は実際の挙動に照らして統制を評価しやすくなります。
現在の調査の多くはセキュリティベンダーの委託によるもの、またはテクノロジー系メディアが公表したものであるため、独立した報告が重要になります。これらの情報源から重要なパターンを読み取ることはできますが、透明性の高い調査方法と反復的な測定があれば、傾向に関する主張の信頼性はさらに高まります。
インシデント率の低下が、必ずしも改善を証明するわけではありません。可視性が悪化したために、組織の検知件数が減少した可能性もあります。より説得力のあるパターンは、エージェントインベントリの拡充、ID管理のカバー率向上、封じ込めの強化、重大な結果の減少が同時に見られることです。
一方で、監視の改善に伴い、報告されるニアミスが増える可能性もあります。確認済みの被害が減少し、対応が迅速化しているのであれば、その増加は短期的な進歩を表している可能性があります。セキュリティ指標には、1つの衝撃的な割合ではなく、文脈が必要です。
企業のリーダーは、まず具体的な問いを投げかけるべきです。組織は、すべての本番環境エージェント、その所有者、認証情報、ツール、実行可能なアクションの最大範囲を特定できるでしょうか。答えが欠けている項目はすべて、管理されていない統制境界を意味します。
AIエージェントのセキュリティインシデントおよびニアミスが54%に達するという数値は、このインベントリ整備が急務であることを示しています。市場の一部では、デプロイの速度がすでにID管理や封じ込めの実践を追い越していることが分かります。
調査やナレッジワークフローでエージェントを使用するチームにも、同じ規律が当てはまります。機密性の高い情報源は定められたアクセス境界内に保持し、出典を維持し、情報を本来のコンテキスト外へ移動させるあらゆるアクションを確認してください。検索可能なナレッジベースは、権限を形骸化させることなく、アクセス性を向上させるべきです。
今後3か月で、企業が測定可能な統制カバー率の向上で対応するのか、それとも新たなセキュリティブランディングを重ねるだけなのかが明らかになるでしょう。デプロイ担当チームに、すべての本番環境エージェントのIDとサンドボックスの状況を確認してください。そうした記録が存在しない場合は、さらなる自律性を付与する前にインベントリを構築してください。記録が存在する場合は、侵害された1つのエージェントが別のワークフローの権限を借用できるかをテストしてください。その答えは、ガードレールのダッシュボードやポリシー文書よりも、準備状況を雄弁に物語ります。
