Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年7月21日に Crystal Morinが投稿したブログ (https://www.sysdig.com/blog/four-ways-ai-has-fundamentally-changed-the-threat-landscape-in-2026) を元に日本語に翻訳・再構成した内容となっております。
長年にわたり、脅威の状況は見慣れた形を保ってきました。すなわち、熟練した人間がマルウェアを書き、既知の脆弱性をスキャンし、盗み取ったデータや企業環境へのアクセスをダークウェブのフォーラムで販売する、という形です。その形はいまも存在します。ただ、防御側が対処しなければならない唯一の形ではなくなった、というだけのことです。
私はこの 4 年間、Sysdig 脅威リサーチチーム（TRT）とともに活動してきました。その間、攻撃はますます高速化してきました——脆弱性はアドバイザリ公開から数時間で悪用され、攻撃は数分のうちに展開します——が、最近になって、私たちは構造的に異なる何かを記録するようになりました。いまや私たちが目にしているのは、単に攻撃者が AI を利用しているというだけでなく、AI がその作業そのものを担い、リアルタイムで計画し、実行し、適応していく攻撃なのです。
この 6 か月の間に、エージェント型 AI が脅威の状況をどのように根本から変えつつあるかを表す、4 つの明確なテーマが浮かび上がってきました。これらのテーマはいずれも、Sysdig TRT が実際に「野生（in the wild）」で確認したものです。予測ではなく、リサーチと現場の証拠の積み重ねなのです。
1. エージェント型脅威アクターの登場
Sysdig TRT が最近観測した最も重要な変化は、AI がますます攻撃を端から端まで（エンドツーエンドで）遂行するようになっているという点です。
私たちはエージェント型脅威アクター（ATA）を、その攻撃能力が、手作業で構築された、あるいは AI が開発したツールキットをキーボードの前の人間が用いるのではなく、AI エージェントによって提供されるオペレーターと定義しています。要するに、AI エージェントが環境からの出力を読み取り、次に何をすべきかをリアルタイムで推論し、各ステップで人間が判断を下すことなく攻撃手順を連続的に実行するのです。
ATA と、AI が開発したツールキットを使う人間、あるいは環境内を移動しながら LLM にプロンプトを与える人間との違いは、自律性にあります。ヒューマン・イン・ザ・ループ型のモデルでは、人間による推論が存在する箇所で攻撃のタイムラインに目立った切れ目が残り、またプロンプトの変遷はエージェントの攻撃スクリプトの変化として現れます。ATA は一時停止しません。
4 回のピボットでアクセスから持ち出しまで
2026 年 5 月、Sysdig TRT は、ある ATA が marimo の脆弱性（CVE-2026-39987）を突いた初期アクセスから、わずか 4 回のピボット・1 時間足らずで内部データベースの持ち出しにまで至る様子を目撃しました。人間が先導することなく、エージェントは認証情報を抽出し、それを再生（リプレイ）して SSH 秘密鍵を取得し、それを用いて下流のサーバーに対する SSH セッションを操りました。
コマンドストリームに漏れ出したコメントや、機械による消費を前提として組み立てられたコマンドから、この攻撃が LLM によって、LLM のために構築されたことは明白です。Sysdig TRT がこの攻撃を精査して結論づけたのは、ステップ間にためらいがなく、レイテンシもなく、人間の攻撃者であればスクリプトに決して書き込まないような痕跡（アーティファクト）がペイロード内に存在したということでした。
コンテナエスケープと Kubernetes のシークレット
別のオペレーションでは、Sysdig TRT は、ある ATA がコンテナエスケープを実行し、Kubernetes のシークレットをダンプする様子を捉えました。自律的な攻撃がアプリケーション層を越えてオーケストレーションプレーン——ワークロードのスケジューリング、シークレット、クラスター構成を自律的に制御する層——にまで及んだのは、これが初めてでした。
コンテナエスケープから Kubernetes のシークレットへと至る種類のキルチェーンは、実行に相当な専門知識を要するため、人間の攻撃者ではあまり見られないものです。この事例は、オペレーターがいまや、事前知識をまったく必要とせずに、エージェントを送り込んで攻撃を連鎖させられるようになったことを示しました。
エージェント型ランサムウェア
続いて登場したのが JADEPUFFER です。これは初めて文書化されたエージェント型ランサムウェアの事例であり、AI エージェントによって端から端まで駆動された、完全な恐喝オペレーションでした。エージェントはインターネットに公開された Langflow インスタンスに存在する 1 年前の脆弱性を発見し、環境を列挙しました。そして、LLM やクラウドのプロバイダー、暗号資産ウォレット、データベースおよび構成ファイルに関連する、価値の高い鍵や認証情報を狙って的確にスキャンし、収集しました。人間が AI を標的に向けると、あとは AI が自律的にやってのけたのです。
エージェントが目的の標的——MySQL データベースと Alibaba Nacos 構成サービスを実行する本番サーバー——に到達すると、1,300 件を超える構成エントリを暗号化し、LLM が生成した身代金要求、Bitcoin の支払いアドレス、Proton Mail の連絡先を記載した恐喝用テーブルを作成しました。この攻撃が示す意味は厳しいものです。かつてランサムウェアはニッチなスキルセットを必要としましたが、いまやランサムウェアのオペレーションを実行できるかどうかは、AI エージェントを動かすのにかかるコスト次第でしかないのです。
このランサムウェア攻撃の最中、JADEPUFFER は最初のログイン試行で失敗に直面しました。エージェントはその原因を診断し、31 秒以内に、わずか 15 行のコードで修正済みのペイロードを送り込みました。
これらのペイロードには、自然言語による推論と、ステップごとの注釈も含まれていました。こうした注釈が重要なのは、ペイロードにアクセスできる場合に、LLM が生成したコードと人間が書いた攻撃とを見分ける最も分かりやすい手がかりの一つになるからです。他の ATA 攻撃にも同様の痕跡（ブレッドクラム）が残されていましたが、こうした AI 生成スクリプトのアーティファクトは、ランタイムで検知できる行動シグナルなのです。
2. AI インフラが標的になった
JADEPUFFER は、Sysdig TRT が複数のキャンペーンにわたって追跡してきたパターンの一例にすぎません。もう一つ浮かび上がっているのは、AI インフラが意図的に攻撃者の優先標的となっているという流れであり、その「なぜ」は、そのインフラがしばしば抱えているものに行き着きます。
認証情報の倉庫
AI インフラでは、認証情報が本来あるべきでない場所に保管されていることが多く、機微なデータへの接続がしばしば存在し、デフォルトのパスワードが変更されないまま放置されがちで、アクセスがインターネットに公開されたままになっていることもあります。言い換えれば、AI インフラは、組織が AI アプリケーションを構築するために展開しているツールを明らかにしてしまうため、まさに金鉱なのです。
Langflow、LMDeploy、Marimo、LiteLLM、PraisonAI などのフレームワークは、現代の AI 開発をつなぐ結合組織です。これらはモデル呼び出しをオーケストレーションし、認証情報を仲介し、クラウド API に触れ、本番データのすぐ隣に位置します。しかもこれらは、組織が他のデータベースや API の周囲に何年もかけて築いてきたようなハードニングを施されないまま、インターネットに公開されたインフラ上に、素早く展開されています。一つでも悪用すれば、OpenAI の API キー、Anthropic の認証情報、AWS のアクセスキー、クラウドストレージのトークン、データベースの接続文字列を、すべて同じ環境から手に入れられるかもしれません。もはや単なる足掛かりではなく、攻撃者もそのことを分かっているのです。
JADEPUFFER もこれを実証しました。Langflow インスタンスが侵入口となり、エージェントは価値の高い認証情報や鍵を明示的に探索しました。その後に標的となった本番の MySQL サーバーと Nacos 構成サービスにも、認証情報とデータがぎっしり詰まっていました。
モデルへのアクセスの窃取
Sysdig TRT は 2024 年 5 月に LLMjacking という用語を生み出しました。これは、攻撃者が盗み取ったクラウド認証情報を使ってホスト型のモデル API にアクセスし、AI コンピュートを吸い上げる行為を指します。当時の試算では、LLMjacking によって被害者は 1 日あたり最大 46,000 ドルもの請求を負う可能性があるとされました。2025 年までに、それはリバースプロキシインフラの販売を通じて数十億もの盗み取られたトークンを仲介する、産業化された闇市場へと成熟していました。
組織が自前のモデルをローカルで稼働させ始めるにつれ、攻撃対象領域は再び移り変わってきました。ごく最近では、ある攻撃者が、被害者の公開された未認証の Ollama サーバーを推論エンジンとして利用し、自律型の攻撃用ツールを構築しました。実際、今年の初めには、推定 175,000 台の Ollama インスタンスが 130 か国以上で公開状態にありました。潜在的な攻撃対象領域は驚異的です。
言ってしまえば、皆さんの AI スタックが資産インベントリに載っていなければ、それは死角です。皆さんの環境にどのような AI インフラが、どこに存在するのかを把握できていれば、こうした脅威が組織に及ぶリスクは大幅に低減できます。第一歩は、AI 部品表（AIBOM）でそのインフラを特定することです。そこから先のリスク低減は、基本的なセキュリティ衛生管理——アイデンティティ管理、ランタイム検知、そして公開範囲の縮小——です。
3. 時間の猶予が崩れ去った
ほとんどの脆弱性管理プログラムに組み込まれている前提は、いまだに「時間はある」というものです。公開後の時間、評価して優先順位を付ける時間、パッチ適用を計画する時間、といった具合にです。その前提はもはや通用しません。AI の導入が各方面で定着したいま、アプリケーションは高速に構築され、それ以上に高速に破られています。時間は——かつてないほどに——きわめて重要なのです。
公開が号砲となる
Sysdig TRT はこの数か月間、悪用までのタイムラインを記録することに費やしてきました。パターンは一貫しており、その数字は憂慮すべきものです。
- PraisonAI の認証バイパス：マルチエージェントのオーケストレーションプラットフォームで、4 時間未満で悪用されました。
- Marimo の RCE：リアクティブな Python ノートブックプラットフォームで、10 時間未満で悪用されました。
- LMDeploy の SSRF：LLM 推論エンジンで、12 時間で悪用されました。
- Langflow の RCE：エージェントと RAG パイプラインを構築するためのビジュアルフレームワークで、20 時間で侵害されました。
- LiteLLM の SQL インジェクション：LLM ゲートウェイで、36 時間で悪用されました。
上記の数字は、CVE 付与後の悪用タイムラインですらありません。これらの攻撃のいくつかは、CVE 番号が割り当てられる前の、GitHub Security Advisory（GHSA）の段階から始まっています。今日では、公開こそが号砲です。というのも、公開情報は概念実証（PoC）を説明しており、攻撃者はそれを使って LLM で数秒のうちにエクスプロイトを組み立てられるからです。
侵入されると、時計はさらに速く進む
攻撃者がクラウド環境を突破すると、対処すべき新たな時間軸の課題が生じます。Sysdig TRT は、平均的なクラウド攻撃が端から端まで 10 分以内に展開すると結論づけたのち、2023 年にクラウドの検知と対応のための 555 ベンチマークを初めて策定しました。Sysdig 555 ベンチマークとは、検知に 5 秒、トリアージに 5 分、対応に 5 分——防御側がクラウドの脅威を阻止するために与えられている時間は、これがすべてだということを表しています。
それ以降、AI 駆動および AI 支援型の攻撃を見ても、その数字は依然として当てはまります。たとえば、前述の marimo の脆弱性では、攻撃者が被害者の環境から認証情報を収集するのにわずか 3 分しかかかりませんでした。別の AI 支援型の侵入では、攻撃者が管理者権限を取得するのに 8 分を要し、その後、リソースデータを持ち出して LLMjacking キャンペーンを実行しました。
555 ベンチマークは、セキュリティチームが現代の攻撃に遅れずついていくための、最低限の運用テンポを定めるために設計されました。この時間軸はいまや、組織にとってかつてないほど重要になっており、エージェント型の検知・対応能力を運用しているチームは、先手を保つために必要な速度で動いています。
4. 攻撃者はモデルを操っている
攻撃者はまた、AI モデルに自分たちの「仕事」を代わりにやらせる方法も習得しました。驚くことではないかもしれませんが、セキュリティ業界は全体としてこうした進化を予期し、自社のモデルに安全のためのガードレールを実装してきました。それでもなお、攻撃者は諦めません。
モデルのジェイルブレイク
2026 年 6 月、Sysdig TRT は、複数の脅威アクターが LLM の安全フィルターを回避するために、悪意あるプロンプトを「capture the flag」（CTF）の体裁で包み込んでいるのを観測しました。自分たちの要求を正当なセキュリティ演習であるかのように見せかけることで、攻撃者は正規のモデルに、本来であれば生成を拒否するはずの、実際に機能する CVE エクスプロイトを生成させることに成功しました。
この CTF ジェイルブレイク手法は LLM のセキュリティ上の失敗ではありますが、モデルが出力するエクスプロイトスクリプトに明白なフォレンジックの痕跡を残します。攻撃者がプロンプトで要求したエクスプロイトの CVE 番号が、コマンドのヘッダーやパスワード、IAM のログエントリにそのまま滲み出るのです。こうしたアーティファクトは、防御側が探すことができ、また探すべき、新しくシンプルな検知シグナルです。
さて、脅威アクターがこうしたアーティファクトを偽造し、それを使って防御側を欺く方法を発見するまでに、どれくらいかかるでしょうか。ここでもまた、時計は刻一刻と進んでいます……
アブリテレーテッド モデル
一方で、そもそもガードレールのないモデルを運用できるのなら、わざわざプロンプトを操作する必要があるでしょうか。前述の、Sysdig TRT による直近の LLMjacking の調査結果が重要だったのは、攻撃者が被害者の LLM へのアクセスを盗んで自律型ツールを構築したという点だけではありません。その LLM は「アブリタレイテッド（abliterated）」な Llama-3.3-70B モデルでした。これは、安全のためのガードレールが取り除かれたバージョンのモデルであることを意味します。モデルには何の制約もなく、オペレーターには何のコストもかからなかったのです。
これら 2 つの手法を合わせて見ると、攻撃者が AI モデルを、入手できるものや都合の良いものに応じて、悪用・操作・窃取の対象となるリソースとして認識していることが分かります。自己ホスト型のモデルエンドポイントにはいずれも攻撃対象領域があり、あらゆる AI API キーは標的であり、そしてモデルそのものも、そこに到達できる者にとっては、何らかの形で攻撃チェーンの一部となり得るのです。
これが防御側にとって意味すること
これら 4 つのストーリーラインはそれぞれ異なりますが、複合し得るものです。
こんな状況を思い描いてみてください。あるエージェント型脅威アクターが、AI パイプラインツールに存在する CVE 付与前の欠陥を公開から数時間で悪用し、ハードニングされていなかった認証情報を盗み出し、ガードレールを剥ぎ取られたモデルを動かす盗み取ったコンピュート上で、オペレーション全体を実行する——というものです。このキャンペーン全体は、数分とまではいかずとも、1 時間を大きく下回る時間で完了し得ます。
これは決して仮説上の連鎖ではありません。実のところ、これは JADEPUFFER の説明そのものであり、そこに Sysdig TRT が文書化してきた LLMjacking と操作の戦術を加えたものだとも言えます。JADEPUFFER のような攻撃——あるいは類似の ATA——に使われる LLM が、アブリタレイテッドされていたり、盗み取ったコンピュートで動いていたりすると想定することは、あり得ない話ではないのです。
これらの攻撃はそれぞれ異なりますが、検知は可能です。今のところ、LLM が生成したコードは、人間のオペレーターならわざわざしないようなやり方で、自らを解説し、自らの推論に注釈を付け、構造化された出力を生み出します。
JADEPUFFER のペイロードには、注入されたスクリプトの内部に自然言語によるステップの根拠が含まれていました。VAPT フレームワークのオーケストレータープロンプトには、そのツール自身のアーキテクチャに関する詳細なドキュメントが含まれていました。これらはブロックすべきシグネチャではありません——ATA のペイロードを見ることができる場合に、狩り出すべき行動パターンなのです。したがって、モデルは攻撃対象領域の一部であるかもしれませんが、同時にインテリジェンスの供給源にもなります。既知のシグネチャに合わせて調整された検知は、実行のたびに新しいペイロードを書くエージェントを取り逃がします。
同様に、パッチサイクルに基づいて運用される脆弱性管理は、公開から数時間以内に始まる悪用を取り逃がします。そして、AI インフラのあらゆる隅々や信頼境界をカバーしていないセキュリティツールは、キルチェーンの残りを可能にする認証情報ストアを見落としてしまいます。
ワークロードと AI インフラの全体にわたって、実際に何が実行されているかをリアルタイムで把握するランタイムの可視性こそが、その基盤です。それは、これらの攻撃が要求する速度と粒度で機能する制御なのです。
本稿で参照した各調査結果の背後にある技術的リサーチの全容や、私たちの最新の調査結果を追いたい方は、 sysdig.com/threat-research をご覧ください。