企業のAI攻撃対象領域の3分の2は可視化できていない、Snykが警告
Snykは、企業のAIリスクについて厳しい数値を提示した。関連する攻撃対象領域のほぼ3分の2が、セキュリティチームの直接的な視界の外に存在し得るという。Google Newsを通じて広まったこの警告は、日常業務の中で接続されるエージェント、プラグイン、データセット、データパイプラインに焦点を当てている。企業がAIの実験を本番環境へ移すにつれ、こうした構成要素は増加する。
この数値は、企業市場全体を対象とした独立監査によるものではなく、Snykによるものだ。同社の裏付け分析は、Snyk Evoに関連する500を超える企業環境から得た匿名化情報を用いている。この違いは重要である。このデータは参加環境の一端を示す一方、より広範な主張については、他のプラットフォームや業界でもなお検証が必要だ。
こうした留保があっても、Snykが指摘する問題は、単一ベンダーのテレメトリーを超える広がりを持つ。Cloud Security Allianceの調査では、回答組織の68%がAIエージェントの行動を人間の活動と明確に区別できなかった。OWASPも、プロンプトインジェクション、過剰な権限、制御されない自律性を、重大なアプリケーションリスクとして別途文書化している。
したがって中心的な対立は、AI導入か抵抗かではない。急速かつ分散的な導入と、既知のアプリケーション、人間のアイデンティティ、安定した資産台帳を前提に構築されたセキュリティシステムとの対立である。企業は推論し行動するソフトウェアをより多く認可する一方で、何が自社データに接続されているのかについて確信を失いつつある。
この隔たりはセキュリティチームに圧力をかけるだけでなく、開発者、プラットフォームエンジニア、調達責任者、事業部門のオーナーにも及ぶ。どのグループもAIへの依存関係を持ち込む可能性がある。しかし、モデルからプラグイン、アイデンティティ、データセット、API、本番アクションに至る連鎖をマッピングできる単一のシステムを備えた組織は少ない。
Snykの警告がGoogle Newsで取り上げられた理由
Snykの最も重要な主張は、AIが新たな脆弱性を生むということではない。企業が、それらを生み出すシステムを確実に可視化できていないという点にある。
Snykは2026年2月、ソフトウェア開発とエージェント型システムにまたがるレイヤーとしてAI Security Fabricを発表した。同社は、そのアプローチによって、ソフトウェア開発ライフサイクル全体で可視性、防御、ガバナンスを統合すると述べた。
この製品発表には、Snykの2026 State of Agentic AI Adoption調査の結果も含まれていた。同社によると、この分析は500を超える企業Evo環境からの匿名化インサイトを対象とした。Snykは、導入されたAIモデルのすべてに、データセットやサードパーティーツールを含む、ほぼ3倍の数の隠れた構成要素が関連付けられていたと述べている。
見出しとなった主張は、この観察をさらに踏み込んだものだ。Snykは、企業AIリスクのおよそ3分の2が、最も目に見えやすいモデル層の下に存在するとしている。隠れた部分には、エージェントツール、プラグイン、接続されたリポジトリ、外部サービス、そして従業員が開発時や日常業務で接続するデータパイプラインが含まれる。
これらの構成要素が自動的に悪意あるものになるわけではない。プラグインは単に文書を取得したり、社内APIを呼び出したり、承認済みのメッセージを送信したりするだけかもしれない。セキュリティ上の問題は、その構成要素、付与された権限、入力ソース、下流のアクションを引き起こす能力の関係性から生じる。
モデルのインベントリだけでは、こうした関係を捉えられない。同じモデルを使う2つのチームでも、リスクプロファイルがまったく異なるエージェントを介して利用している可能性がある。あるエージェントは公開文書を要約するだけかもしれない。別のエージェントは、ソースコードを読み、顧客記録を照会し、本番システムに変更を書き込む可能性がある。
だからこそ、この話題は、従業員が未承認のチャットボットを使うことへのおなじみの警告以上の意味を持つ。シャドーAIには現在、承認済みソフトウェアに組み込まれた機能、ローカルに導入されたモデル、エージェントフレームワーク、ブラウザー拡張機能、自動化サービス、マシンアイデンティティも含まれる。一部は正式な調達を通じて導入される。別の一部は、従業員がタスクを完了するためにもう1つツールを接続した時点で現れる。
Google Newsはこの主張に幅広い配信チャネルを与えるが、集約掲載はその基礎となる数値を検証するものではない。読者は、この3分の2という推定値を、Snykの顧客関連環境データから得られたベンダーの調査結果として扱うべきだ。より強い結論を支えるのは、企業がエージェントの行動、権限、構成要素間の依存関係を棚卸しすることに苦慮しているという裏付け証拠である。
この区別により、分析が製品マーケティングへと転じるのを防げる。Snykによる市場全体の正確な推定値は、引き続き検証の余地がある。一方、可視性の問題そのものは、すでに複数の独立した標準志向の情報源によって裏付けられている。
AIの攻撃対象領域は、もはやアプリケーションの一覧ではない
実務上の攻撃対象領域は現在、モデル、アイデンティティ、ツール、データストアが接続関係を通じてリスクを生む、変化し続けるグラフのように振る舞う。
従来のアプリケーションセキュリティは、比較的安定した対象から始まる。チームはアプリケーションを所有し、そのリポジトリを維持し、依存関係を追跡し、既知のインフラを通じてデプロイする。セキュリティツールはコード、パッケージ、コンテナイメージ、クラウド構成、公開エンドポイントをスキャンできる。
AIネイティブなシステムでは、さらに多くの可変要素が加わる。SnykによるAI-native applicationsの分析は、事前学習済みモデル、埋め込み、サードパーティーエージェント、データセット、外部サービスを含み得るサプライチェーンを説明している。各構成要素は、アプリケーションのソースコードとは独立して変化し得る。
埋め込みとは、コンテンツの意味を比較するために使われる数値表現である。ベクトルデータベースは、検索のためにこうした表現を数百万件保存することがある。権限やソースラベルに誤りがあれば、エージェントは利用者が本来アクセスするべきではない情報を取得し得る。
しばしばRAGと略される検索拡張生成は、モデルが回答を生成する前に、選択された文書や記録を与える仕組みだ。RAGは精度を高められる一方、別の信頼境界も生む。検索レイヤーは、エージェントが検索できるソースと返すべきコンテンツを決定しなければならない。
ツールは、より重大な境界を生み出す。メール、ソース管理、クラウドインフラ、顧客データベースに接続されたエージェントは、テキスト生成の域を超えられる。開発者が付与した権限に応じて、情報の読み取り、書き込み、実行、承認、送信を行える。
これにより、購入済みアプリケーションを中心に整理されたセキュリティインベントリとの不整合が生じる。企業はモデルプロバイダーとエージェントフレームワークを承認しているかもしれない。それでも、デプロイ後に接続されたすべてのツールエンドポイント、サービスアカウント、データセット、プロンプトテンプレート、プラグインの完全な記録を欠いている可能性がある。
この連鎖は、従来型のリリースなしに変化することもある。モデルプロバイダーが挙動を更新するかもしれない。サードパーティーツールが機能を追加するかもしれない。データセットに新しい文書が追加されるかもしれない。ユーザーがOAuthスコープを拡張するかもしれない。OAuthスコープは、委任認可を通じてアプリケーションがアクセスできる範囲を決定する。
こうした変化が重要なのは、リスクが組み合わせに依存するためだ。読み取り専用アクセスを持つ要約エージェントの影響範囲は限定される。同じエージェントにメール送信、ファイル編集、制限のないWebエンドポイント呼び出しの権限を与えれば、操作された入力はまったく異なる結果を生み得る。
したがって攻撃対象領域には、コードの脆弱性だけではない。過剰な権限、汚染されたコンテキスト、露出した認証情報、安全でない出力処理、不十分な承認ルール、不完全なアクションログも含まれる。これらの問題の一部は、ソースファイルや既知のソフトウェアパッケージだけを検査するスキャナーには見えないままである。
エンジニアリングチームにとって、ドキュメントはコントロールシステムの一部となる。アーキテクチャ判断、承認済みツール、権限スコープ、インシデントの知見を検索可能な形で記録することは、個々のダッシュボードが見逃す関係性の特定に役立つ。構造化されたengineering knowledge baseはこの作業を支援できるが、セキュリティ監視の代替にはならない。
より大きな教訓は単純だ。AIシステムを単一のモデルエンドポイントとして統治することはできない。データ、ツール、アイデンティティ、アクションが運用中を通じて可視化された、接続型アプリケーションとして扱う必要がある。
エージェント型AIがアイデンティティ制御に圧力をかける
最も急速に拡大する盲点は、自律ソフトウェアが人間のユーザー向けに設計された権限を継承する場所にある。
Cloud Security Allianceは2026年3月にagent identity researchを発表した。その調査では、73%の組織が翌年中にAIエージェントが不可欠になると予想していた。しかし68%は、エージェントが実行したアクションを人間が実行したアクションと明確に区別できなかった。
この68%という数値と、Snykによるおよそ3分の2という警告の類似は印象的だが、両者が測定しているものは異なる。SnykはAI環境全体にわたる隠れた構成要素とリスクを論じている。Cloud Security Allianceの調査は、アイデンティティの帰属とアクセス管理を検討している。
両者を合わせると、同じ構造的な弱点が見えてくる。組織は、認証、認可、監視の慣行を更新するより速いペースで、ソフトウェアアイデンティティに業務システムへのアクセスを与えている。
マシンアイデンティティとは、人ではなくソフトウェアが使用する認証情報である。APIキー、サービスアカウント、証明書、ワークロードアイデンティティ、OAuthトークンの形を取ることがある。エージェントは、データにアクセスしアクションを実行するためにこれらの認証情報に依存する。
人間向けのアイデンティティシステムは通常、個人がサインインし、定義されたロールを受け、そのアカウントに紐付いた活動を生成することを前提としている。エージェントはこのモデルを複雑にする。1つのエージェントが複数のユーザーのために動作し、複数のツールを呼び出し、数秒のうちにマシン生成の操作連鎖を生み出す可能性がある。
特に、エージェントが共有サービスアカウントを使う場合、帰属の特定は難しくなる。ログには、そのアカウントが記録を変更した、あるいはファイルをダウンロードしたと表示されるかもしれない。しかし、そのアクションを引き起こした従業員の要求、モデルの判断、取得した文書、プラグイン呼び出しまでは特定できない可能性がある。
これは単なる監査上の不便ではない。帰属が弱いと、インシデント封じ込めはより困難になる。どのエージェント、ユーザー、ワークフローが不審な活動を開始したのか分からなければ、セキュリティチームは適切な認証情報を確信を持って無効化できない。
過剰な権限は被害を拡大する。メッセージを要約するだけのために作られたツールに、送信や削除の権限が与えられることがある。コードアシスタントが、1つのプロジェクトをレビューするだけでよいにもかかわらず、複数のリポジトリに対する書き込みアクセスを取得することもある。
OWASPはこの状態をexcessive agencyと説明している。そのガイダンスでは、過剰な機能、権限、自律性を根本原因として挙げている。OWASPは、利用可能なツールを制限し、権限を絞り、ユーザーのコンテキストでアクションを実行し、影響の大きい操作には承認を求めることを推奨している。
こうした制御は、成熟したゼロトラストの実践に似ている。各リクエストは、特定のアイデンティティ、定義された認可、現在のコンテキストに基づいて評価されるべきだ。モデルが、操作が許可されるかどうかを単独で決定すべきではない。
エージェントには、人間の操作者とは区別される固有のアイデンティティも必要です。ログには、ユーザーの要求、エージェントのインスタンス、選択されたツール、使用された認証情報、そして実行されたアクションの関係を保持しなければなりません。この連鎖がなければ、企業は膨大な量のテレメトリーを収集していても、実質的には何も見えていない状態に陥ります。
ここで、AI導入はセキュリティアーキテクチャに圧力をかけます。事業部門は、反復的な承認作業をなくし、複数ステップのタスクを完了するアシスタントを求めています。一方、セキュリティチームには、検証ポイント、限定的な権限、そして後から再構築できる意思決定が必要です。すべての検証ポイントを取り除けば速度は上がりますが、誤った、あるいは操作されたアクションによる潜在的な被害範囲も拡大します。
この対立は、完全な自律性を選ぶか、エージェントを禁止するかで解決するものではありません。企業には、結果の重大性に応じて異なる自律性レベルが必要です。要約の下書きは自動のままで構いません。資金の送金、レコードの削除、本番インフラの変更、保護されたデータの開示には、より強力な統制が求められます。
真のトレードオフは速度と検証可能な統制の間にある
エージェントがシステム境界を越えることで企業は価値を得る一方、接続が増えるほど、その振る舞いの検証は難しくなります。
エージェント型AIが企業にとって魅力的なのは、分離された複数の手順を一つのワークフローに接続できるからです。サポートエージェントは、チケットを読み取り、アカウント履歴を取得し、緊急度を分類し、回答案を作成し、顧客レコードを更新できます。この一連の流れにより、手作業による調整を減らせます。
同じ一連の流れには、複数のセキュリティ境界も含まれています。チケットには信頼できないテキストが含まれる場合があります。アカウント履歴には保護対象データが含まれる可能性があります。モデルが安全でないツール指示を生成することもあります。顧客システムは、長期的な影響を伴う更新を受け入れる可能性があります。
プロンプトインジェクションは、このトレードオフを具体的に示します。プロンプトインジェクションは、細工されたコンテンツによって、モデルが指示に従う方法が変化する現象です。そのコンテンツはユーザーから直接提供される場合もあれば、Webページ、文書、メール、リポジトリ、取得したレコードから間接的に入り込む場合もあります。
従来のアプリケーションは、厳格な構文とアクセス制御により、コマンドとデータを分離します。言語モデルは、両方をコンテキスト内のトークンとして処理します。この設計により、モデルが外部テキストを指示ではなく常に信頼できないデータとして扱うことを保証するのは困難です。
OWASPの現行ガイダンスでは、完全に防げるプロンプトインジェクション対策は知られていないとされています。推奨されているのは、振る舞いの制約、期待する出力形式の検証、入力と出力のフィルタリング、モデルが利用できる権限の制限です。
こうした緩和策は影響を減らしますが、確実性を生むものではありません。限定された文書コレクションだけを読み取れるエージェントは、シェルコマンドを実行できるエージェントより危険性が低くなります。人による承認ステップは不審なアクションを捉えられますが、それはレビュー担当者が情報に基づいた判断を下せるだけの十分なコンテキストを受け取る場合に限られます。
速度への圧力は、各セーフガードに及びます。チームは、統合作業の繰り返しを避けるために広範なアクセス権を付与するかもしれません。ユーザー単位の認可は実装に時間がかかるため、共有認証情報を使うかもしれません。ユーザーが摩擦を訴えると、承認プロンプトを抑制する可能性もあります。
このため、中心的な争点は導入速度と検証可能な統制のトレードオフになります。Snykは、AIシステムの変化が速すぎて時折のレビューでは追いつかないため、セキュリティは継続的でなければならないと主張しています。同社はこの要件に対応する製品を販売しているため、商業的な利害関係があることは明白です。
したがって、購入者は診断と提案されるプラットフォームを分けて考えるべきです。統合セキュリティレイヤーは可視性を改善する可能性がありますが、大企業全体にわたるすべてのモデル、ローカルデプロイメント、ブラウザツール、データセット、アイデンティティ、外部統合を一つの製品で観測できると証明したベンダーはありません。
カバレッジの主張は、統合とテレメトリーに依存します。承認済みのクラウドモデルは検出しやすいかもしれません。一方、開発者のワークステーションでローカルホストされるモデルは、そうではない可能性があります。一般的なソフトウェアパッケージに組み込まれたAI機能は、通常のアプリケーショントラフィックに見えるアクティビティを生成する場合があります。
暗号化された接続とプライバシー規則は、さらに制約を加えます。プロンプトや取得した文書を監視すると、機密性の高い従業員・顧客データを露出させる可能性があります。セキュリティチームには、不正利用を検出するのに十分なコンテキストが必要ですが、機密情報の第二のリポジトリを構築してはなりません。
地域ごとのデータ規則も別の制約になります。多国籍企業は、すべてのAIインタラクションログを一元化できない可能性があります。ローカル処理、選択的なメタデータ、保持管理、そして法域ごとに異なる監視ポリシーが必要になるかもしれません。
こうした複雑さは、Snykの警告を無効にするものではありません。むしろ、その中心的な主張を強めると同時に、単純な解決策には疑問を投げかけます。可視性は必要ですが、可視性そのものが設計、プライバシー、運用面のコストを生みます。
「3分の2」という主張が証明していないこと
Snykのデータは深刻なガバナンス上の隔たりを示していますが、すべての企業環境の3分の2が侵害されている、または悪用可能であることを示すものではありません。
最も重要な制約はサンプリングです。Snykは、500を超える企業のEvo環境から得た匿名化インサイトについて説明しています。その環境を利用する組織は、規模、ソフトウェアの実践、AI成熟度、セキュリティの優先順位において、より広い市場とは異なる可能性があります。
同社は、自社サンプルがあらゆる業界や地域を代表することを公には立証していません。また、より広範なセキュリティカバレッジを有利にする形で問題を定義する商業的な理由もあります。どちらもデータが誤りであることを意味しませんが、慎重な帰属が必要です。
「リスク」は「脆弱性」よりも広い概念です。隠れたコンポーネントは、悪用可能な欠陥を含んでいなくても、管理されていない、あるいは資産台帳が不十分である可能性があります。弱い権限、機密データ、安全でない入力、または重大なアクションを実行する能力と組み合わさったときに危険になります。
同様に、「3分の2」はセキュリティチームが各環境の正確に3分の1しか見えていないことを意味しません。この推計は、観測された環境のパターンを要約したものです。個々の組織では、カバレッジがはるかに良い場合も悪い場合もあります。
「アタックサーフェス」という表現も、異なる問題を曖昧にし得ます。インターネットに公開された資産、内部API、ソフトウェア依存関係、エージェントツール、データフロー、アイデンティティ、モデルの振る舞いが含まれる場合があります。ベンダーごとに、こうした要素の数え方は異なります。
独立した測定には、共通の定義が必要です。研究者は、既知の資産と未知の資産、到達可能なコンポーネントと休眠中のコンポーネント、理論上の露出と実証済みの攻撃経路を区別する必要があります。こうした区別がなければ、大きな割合は注目を集めても、運用上の指針としては限られます。
NISTは、そのAI Risk Frameworkを通じて、より中立的な基盤を提供しています。このフレームワークは、AIリスクの統治、マッピング、測定、管理を中心に作業を整理しています。また、リスク管理がシステムライフサイクル全体を通じて継続すべきことも強調しています。
マッピングは、Snykの主張に特に関連します。組織はリスクを測定する前に、モデル、想定タスク、ユーザー、データ、依存関係、デプロイメントコンテキスト、影響を受ける当事者を特定しなければなりません。スキャナーだけで、不足しているすべてのポリシーや所有権に関する決定を取り戻すことはできません。
測定にはテストも必要です。企業は、エージェントが想定する権限を文書化していても、本番環境で有効な権限を検証していない可能性があります。承認済みツールを記録していても、更新された統合を通じて追加された機能を見落とすことがあります。
したがって懐疑的な立場は、盲点が架空だというものではありません。一社のベンダーのテレメトリーでは、市場全体におけるその正確な規模をまだ定義できない、ということです。見出しは、資産棚卸しとテストを促すものであるべきであり、そのどちらかの代替物になってはなりません。
セキュリティリーダーは、ベンダーにカバレッジの算出方法を尋ねるべきです。分母、検出方法、除外された環境、更新頻度、重複または古い資産を解決するプロセスを求めるべきです。そのコンテキストを欠く正確な割合は、誤った安心感を生む可能性があります。
成果も測定すべきです。より多くのコンポーネントを見つけることが有用なのは、組織が危険な関係を優先順位付けし、所有者を割り当て、権限を縮小し、検証済みの経路を修正できる場合に限られます。管理不能なアラートキューを生むだけの大規模な資産台帳は、別の形の盲点になり得ます。
盲点が縮小しているかを示す3つのシグナル
次の段階は、アイデンティティの帰属、コンポーネント台帳、危険なエージェント権限の検証済み削減を通じて測定されます。
最初のシグナルは、企業がログ内でエージェントのアクティビティと人間のアクティビティを分離できるかどうかです。Cloud Security Allianceによる68%という調査結果は、直接テレメトリーではなく調査に基づくものではあるものの、明確なベースラインを提供しています。
改善とは、重大な影響を持つ各アクションに、エージェントのアイデンティティ、ユーザー委任、ツール名、認可コンテキスト、追跡可能な結果が付与されることを意味します。後続の調査で、帰属に苦しむ組織が減少していれば、管理可能なエージェントガバナンスを実現できるという根拠はより強くなります。
この数字が3分の2付近にとどまるなら、逆の結論が導かれます。企業は、基本的な説明責任を解決しないまま、より多くの自律型ワークフローを導入していることになります。その結果は、導入とともに可視性の隔たりが拡大しているというSnykの警告を強めるでしょう。
2つ目のシグナルは、一貫性のあるAI部品表の登場です。AI部品表は、システムで使用されるモデル、データセット、プロンプト、フレームワーク、ツール、サービス、依存関係を記録します。これは、ソフトウェア部品表の概念をAI固有のコンポーネントへ拡張したものです。
有用な版は、デプロイメントと同期し続ける必要があります。調達時に作成された静的な文書では、後から接続されるツールやデータセットを見落とします。単にリストを作ることよりも、自動検出、所有者の割り当て、バージョン履歴、有効な権限の証跡が重要です。
相互運用可能な台帳形式が広く採用されれば、企業が可視性を回復できるという主張は強まります。ベンダー固有のダッシュボードへの依存が続けば、セキュリティ製品、クラウドプラットフォーム、ローカル環境の間に盲点が残ります。
3つ目のシグナルは、組織が本番環境における過剰なエージェンシーを削減しているかどうかです。セキュリティチームは、別途承認を得ずにデータの書き込み、コードの実行、通信の送信、インフラの変更、機密リポジトリへのアクセスを行えるエージェントの数を追跡すべきです。
その数が減少すれば、企業がAIガバナンスを技術的統制へ変換していることを示します。増加すれば、生産性目標が依然として封じ込めを上回っていることを示します。過剰な権限を持つエージェントに関わるインシデント報告は、この指標を特に緊急性の高いものにするでしょう。
これらのシグナルは、企業が公表するAIポリシーの量より重要です。ポリシーは意図を示します。アイデンティティ、台帳、権限、ログは、運用の現実を明らかにします。
SnykのGoogle News見出しが成功しているのは、その現実を記憶に残る一つの警告に圧縮しているからです。正確な3分の2という数字は依然としてベンダー由来の推計ですが、その根底にある不一致を退けるのは困難です。AIコンポーネントは、多くの組織がそれらを発見、分類、統治できる速度を上回って増えています。
開発者にとって、直ちに問うべきなのは、すべてのエージェント接続に名前の付いた所有者と必要な権限があるかどうかです。セキュリティチームにとっては、ユーザーの要求からモデルの判断、下流の結果に至るまで、一つのアクションをログで再構築できるかどうかです。企業の購入者は、両方について証拠を求めるべきです。
次の四半期は、実践的なテストの機会を提供します。本番エージェントを一つ選び、すべてのモデル、ツール、アイデンティティ、データセット、外部呼び出しをマッピングし、その地図を既存のセキュリティ記録と比較してください。二つの見方に大きな違いがあれば、その盲点はすでに組織内にあります。一致するなら、権限と承認統制が文書どおりに機能するかをテストしてください。Google Newsが警告を発した今、答えを示すのは企業のテレメトリーです。
