Orca Securityの「2026 State of AI Security Report」によると、組織はクラウド上でAIを構築・展開・運用しているものの、基本的なサイバーセキュリティ衛生管理はスピードを優先するあまり犠牲になることが多いといいます。
セキュリティ不在のままAIを構築
AI導入企業の56%がエージェントフレームワークを本番環境に展開済みで、51.5%がAIを使ってカスタムアプリケーションを構築しています。またOrcaの調査では、AIパッケージを運用する企業の81.2%が既知の脆弱性を少なくとも1つ抱えており、修正パッチが提供されているAI脆弱性アラートのうち99.9%が未パッチのまま放置されていることも判明しました。これらの結果は、セキュリティ成熟度がそれに見合う形で高まらないまま、AIがいかに急速に基幹インフラ化しているかを示しています。
API型AIは開発ワークフローに組み込まれ、コードベースやターミナル、環境変数、認証情報へのアクセス権を持つため、新たな攻撃対象領域を生み出しています。
AIエージェントを展開する組織は、同時にエージェントフレームワークも展開しています。本番稼働するエージェント1つひとつが、独自の権限やメモリ、被害波及範囲を持つ新たな非人間アイデンティティとなります。RAG(検索拡張生成)パイプラインは、クエリ実行時にLLMが社内文書や顧客データ、独自の知見にアクセスすることを可能にします。
AIクラウドサービス利用企業の半数以上が、4種類以上の異なるAIサービスを運用しています。主要クラウドプロバイダー3社にまたがる調査では、87%から98%の組織がAIサービス向けに顧客管理型の暗号鍵を設定していませんでした。これらの企業は、企業データやクラウドサービス、アイデンティティ、本番ワークフローと連携する複雑なAIエコシステムを管理していることになります。
Orca SecurityのCISOであるNir Mishal氏は次のように述べています。「AIはクラウド環境にまったく新しい運用レイヤーをもたらしました。現在、組織にはエージェントが意思決定を行い、ベクトルデータベースが企業データと接続され、AIサービスが複数のクラウドプロバイダーに分散しています。セキュリティチームには、こうした環境全体を可視化する統合的な仕組みと、自動化された防御策の両方が必要です。それによって初めて、実際にどこにリスクが存在するかを把握し、被害が発生する前に攻撃者を阻止できるのです」
AIサプライチェーンの保護
攻撃者は、パッケージレジストリ、モデルハブ、開発者ツール、エージェントフレームワーク、ブランド信用という、AIスタックの5つの層を横断して活動しています。これらの層にまたがる技術は、本番環境で広く展開されています。
AIパッケージを運用する企業の81%が既知の脆弱性を少なくとも1つ抱えており、74.1%は少なくとも1つの深刻なCVEを抱えています。AIパッケージは過去5年間に公表された脆弱性(直近12カ月に公開されたCVEも含む)を引き継いでおり、本番環境が新旧双方の脅威にさらされる結果を招いています。
依存関係グラフに組み込まれた脆弱なライブラリは、パッチサイクルよりも長く生き残ることが少なくありません。依存関係が常に最新の状態に保たれることを前提としたリリースサイクルであっても、AIワークロードは同じ問題を抱えています。
2024年時点では、多くの脆弱性が「悪用が難しい」とみなされていたため、組織はAIパッケージのパッチ適用の優先度を下げる傾向がありました。しかし現在では、修正パッチが提供されているAI脆弱性アラートの99.9%が未パッチのまま放置されています。
Orcaは、新たに見つかったAI関連パッケージの脆弱性を3つのカテゴリーに分類しています。ホスト型AIモデルへのアクセスに使うSDK、AIエージェントや連携機能を構築するためのフレームワーク、そして急速に拡大するMCP(Model Context Protocol)エコシステムです。
AIエージェントとRAGの管理
ガバナンス面での対応は進んでいるものの、それに見合うだけの導入は進んでおらず、多くのAIエージェントがデフォルトの権限設定のままログも取得されず、本番システムからのランタイム分離もなされずに稼働しています。これにより攻撃者は、コマンドを実行してAIレイヤー内を横方向に移動する目的でエージェントを悪用する機会を得てしまいます。
AI導入企業の64%が、LLMを社内文書や顧客記録、独自の知見に接続するベクトルデータベースを展開しています。
RAG(検索拡張生成)を利用する企業は、平均で3.78個のベクトルデータベースを運用しており、プラットフォームや展開モデル、アクセス方法をまたいで一貫したセキュリティポリシーを徹底することを難しくしています。
ガバナンスのギャップを埋める
AIはモデル、エージェント、パッケージ、ブラウザ拡張機能、クラウドサービスと多岐にわたります。これらの技術は、セキュリティチームが目録を作成し保護する速度を上回るペースで企業内に広がっています。それぞれが独自のセキュリティモデル、暗号化オプション、アクセス制御、コンプライアンス要件を伴います。
AIコーディングツールはソフトウェアに脆弱性を持ち込む可能性があるため、コードレビューやシークレット管理、コミットセキュリティポリシー、セキュリティスキャンが不可欠です。
各国政府はAI規制を拡大しています。EU AI法は2026年8月2日から、高リスクAIシステムに対する追加要件を導入します。米国はAI規制の枠組みの整備を続けており、コロラド州の改正AI法は2027年1月1日に施行されます。中国はAI固有の要件やAI生成コンテンツの表示義務化を盛り込む形で、サイバーセキュリティの枠組みを拡大しています。
AIサービスは、露出した認証情報という新たなカテゴリーを生み出しました。APIキーはAIモデルや企業データ、AIサービスへのアクセス手段となるため、格好の標的となっています。AI導入企業の約30%が、少なくとも1つのAIキーを安全とはいえない場所に保管しています。Gitリポジトリにコミットされたキーは、コードベースから削除された後もアクセス可能な状態のまま残ってしまう場合があります。
AIインフラの露出を是正する
企業がAIサービスを展開する際、設定に不備があり露出したままになっているケースが少なくありません。攻撃者は、過剰な権限設定や公開エンドポイント、脆弱な認証、予測可能な設定を悪用し、AIインフラを標的にする動きを強めています。
Amazon SageMaker、Azure OpenAI、Google Vertex AIといったプラットフォーム全般に共通する問題としては、暗号化の欠如、広範なアクセス権限、インターネットに公開されたサービスなどが挙げられ、これらは横方向への侵入拡大やデータ窃取を容易にしてしまいます。
AI暗号化の強化
プロバイダー管理型の暗号鍵に依存している企業は、AIデータへのアクセスに対する管理権限が限られています。プロバイダー管理型の鍵は保存データを暗号化する一方で、顧客側が鍵のローテーションを制御したり、独自にアクセス権を取り消したり、鍵の利用状況を可視化したりすることはできません。
顧客管理型の暗号鍵は、トレーニングデータや機密情報、AIモデルの保護に役立ちます。しかし、ほとんどの組織はこれを有効化していません。
翻訳元: https://www.helpnetsecurity.com/2026/07/13/ai-infrastructure-security-risks-report/
