はじめに——守る対象が「自社のAI」から「自社のクラウド課金・鍵・インフラ」へ
これまでのAIセキュリティ記事では、プロンプトインジェクション、エージェント乗っ取り、サンドボックス脱出、モデル抽出・蒸留窃取といった「自社が使う／公開したAIをどう守るか」を中心に扱ってきました。守る対象は常に「自社のAI」で、攻撃者は人間でした。
しかし2026年、攻撃の構図そのものが反転しています。攻撃を実行する主体がAIになり、被害を受けるのは自社のクラウド課金・APIキー・インフラという新しい軸が現実になりました。攻撃者は盗んだ認証情報で正規のAIアカウント（Amazon Bedrock・OpenAIなど）を乗っ取り、他人の財布で推論や暗号採掘を回す。さらに、偵察から権限昇格スクリプトの生成、Lambdaへのバックドア注入までを、LLMエージェントが人間の手を介さず自律実行する事例まで観測されています。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで長年トラフィック異常の検知に携わってきました。本記事の核心は、そのNOC/TAC的な「異常なトラフィック・異常な課金を集合として捉える」発想が、そのままAI速度の攻撃を止める防御に転用できるという点にあります。攻撃が人間の速度を超えた以上、人間が目視で追う運用はもう間に合いません。検知・遮断もまた自動化された多層防御に組み替える必要があります。
想定読者は、AWS・Azure・GCP上でAIワークロードを動かす情シス・SRE・CISOの方々、そしてクラウドのコストと鍵の管理に責任を持つFinOps・プラットフォーム担当の方々です。
前提——「攻撃する側の自律化」を2つの手口に分けて理解する
「攻撃者がAIを使う」と一口に言っても、2026年に観測された脅威は狙いと手口が2種類に分かれます。防御の当て方が違うため、まずここを分けて理解します。
手口1：LLMjacking——正規のAIアカウントを乗っ取り、他人の財布で推論する
LLMjackingは、Sysdigの脅威リサーチチームが2024年に命名した手口です。攻撃者はサーバーの脆弱性や公開されたS3バケット、漏洩した設定ファイルなどからクラウド認証情報を盗み、被害者のAmazon Bedrockなどの推論エンドポイントを不正に有効化・利用します。狙いは「AIコンピュートそのものの窃取」です。
被害は静かに、しかし高額に膨らみます。Sysdigの初報では被害者のコストが1日あたり4.6万ドルを超え、最上位モデルを使われた場合は1日10万ドル規模に達し得ると報告されました。盗まれたアクセスは、フィルタ無しのチャットボットサービスや「リバースプロキシ」として地下市場で転売され、攻撃者は自前でモデルを契約せずに他人のBedrockクォータで商売を回します。近年はこの盗んだAIコンピュートを、フィッシング文面生成や攻撃自動化の「兵器」として使う動きも観測されています。
手口2：AI駆動ポストエクスプロイト——LLMエージェントが侵入後の全工程を自律実行する
より新しく、より深刻なのがこちらです。侵入後の偵察・権限昇格・横展開・データ持ち出しといった「ポストエクスプロイト」の一連を、LLMが自動化・自律化します。
Sysdigは2025年11月28日、盗まれた認証情報からわずか8分でAWS環境の管理者権限まで到達し、Lambda実行に至った攻撃を観測しました。攻撃者は公開S3バケットで見つけたAI関連データ内の認証情報から侵入し、偵察による管理者ロールの特定、権限昇格、Lambdaへのコード実行までを高速でこなしました。偵察の自動化・悪性コードの生成・リアルタイムの意思決定にLLMが使われた痕跡が複数指摘されています。
さらに2026年、Marimoの脆弱性（CVE-2026-39987）を起点に、AIエージェントが人間の指示を挟まずポストエクスプロイトの全チェーンを自律実行し、初期侵入から内部PostgreSQLデータベースの完全な持ち出しまでを1時間以内で完了させた、実地で確認された初の事例が報告されました。出力を見て次の手を判断し、インフラを渡り歩く——攻撃の「意思決定」までがAIに移った瞬間です。
2つの手口を整理すると次のようになります。
| 手口 | 攻撃主体 | 狙うもの | 主な被害面 | 効く防御の軸 |
|---|---|---|---|---|
| LLMjacking | 人間＋盗んだ認証情報 | 他人のAIコンピュート | クラウド課金・APIキー | 異常課金検知・鍵ハードニング・レート制御 |
| AI駆動ポストエクスプロイト | LLMエージェント（自律） | 権限・データ・インフラ | IAM権限・実行環境・持ち出し経路 | 最小権限・エグレス制御・自動遮断 |
標準フレームワークでの位置づけ
これらは「特殊な懸念」ではなく、業界標準のフレームワークが正面から扱うリスクです。社内説明や監査対応の根拠として押さえておくと効きます。
- OWASP LLM Top 10（2025年版）： 推論リソースの不正消費・コスト枯渇は LLM10:2025 Unbounded Consumption（無制限な消費） に対応します。LLMjackingによるクォータ乱用・コスト膨張はまさにこのカテゴリです。
- MITRE ATLAS： 推論APIを悪用してプロバイダにコストを負わせる行為は AML.T0034（Cost Harvesting）、推論API経由のデータ持ち出しは AML.T0024（Exfiltration via AI Inference API） に対応します。盗んだ正規アカウントの利用は、クラウド攻撃で言う「Valid Accounts」の系譜に連なります。
攻撃の見え方——「正常な操作の高速な連鎖」として現れる
この種の攻撃の最大の特徴は、1操作ずつ見れば完全に正規のAPI呼び出しである点です。Bedrockの推論も、IAMの列挙も、Lambdaのデプロイも、それ単体は日常運用に現れる正常操作です。WAFや単純なシグネチャでは止まりません。止めるには、操作の「速度・連鎖・課金の異常」を集合として見る必要があります。これはNOCでトラフィックのベースラインを学習し、逸脱を検知するのと同じ発想です。
| 観点 | 正常利用 | 攻撃の疑い |
|---|---|---|
| 推論の量・課金 | 業務量に沿った緩やかな変動 | 短時間で桁違いに急増（10倍以上のスパイク） |
| 利用モデル | 普段使うモデルに集中 | 普段使わない高額モデルの突然の有効化 |
| 操作の連鎖 | 人間的な間隔・試行錯誤 | 偵察→昇格→実行が機械速度で連続 |
| アクセス元 | 既知のIP・地域・時間帯 | 未知の地域・深夜・新規APIキー |
| API呼び出しパターン | 用途に沿った限定的なAPI群 | 権限列挙・網羅的なリソース探索 |
第1の防御層：異常課金・異常利用の検知——「財布」を最初のセンサーにする
LLMjackingが最初に、そして確実に現れる場所が課金です。攻撃者は他人の財布で推論を回すため、被害は必ずコストとして観測されます。財布を最初のセンサーとして使うのが、最も費用対効果の高い検知です。
見るべきメトリクス
- 推論コストの急変： アカウント／プロジェクト／APIキー単位で、時間あたりコストのベースラインからの逸脱を継続監視。10倍スパイクは典型的なLLMjackingのシグナルです。
- モデル有効化イベント： 普段使っていない（特に高額な）モデルが突然有効化されたら即アラート。攻撃者はデプロイ済みモデルだけでなく新規モデルの有効化も試みます。
- 推論API呼び出し数の傾き： 単発のバーストだけでなく、レート制限を避けて淡々と続く長期の増加トレンドも捉える。
- 地域・時間・鍵の逸脱： 普段と異なるリージョン、深夜帯、新規発行直後のキーからの推論呼び出し。
実装の考え方
過検知で正規ワークロードを止めると事業が痛むため、段階的レスポンスが鉄則です。NOCのインシデント対応と同じく「観測→警告→緩和→遮断」の階段を、AI速度に間に合う自動化として設計します。
| 段階 | 条件の例 | レスポンス |
|---|---|---|
| 観測 | コスト・呼び出しが平常域 | 記録のみ |
| 警告 | コスト急変・未知モデル有効化 | 内部アラート、監査ログにフラグ |
| 緩和 | 継続的な逸脱 | 該当キーのレート厳格化、追加認証、モデル有効化の一時凍結 |
| 遮断 | 明確な乱用パターン | キー失効・セッション無効化、CISOへエスカレーション |
重要なのは、AWSであれば予算アラートやCloudWatch、Bedrockの利用ログ、CloudTrailを組み合わせ、「課金の異常」と「操作の異常」を突き合わせて初めて意味のある検知になる点です。コストだけ、ログだけでは誤検知と見逃しの両方が増えます。
第2の防御層：APIキー・認証情報のハードニング——盗まれても使えなくする
LLMjackingもAI駆動ポストエクスプロイトも、起点はほぼ例外なく漏洩した認証情報です。8分侵害の事例では、公開S3バケット内のAI関連データに含まれた認証情報が入口でした。したがって最大の投資対効果は「鍵を盗まれても被害が出ない状態」を作ることにあります。
- 長期キーの廃止： 静的なアクセスキーを撤廃し、短命の一時認証情報（IAM Roles・STS・OIDCフェデレーション）へ移行する。盗んだ鍵の有効期限を最小化する。
- 最小権限の徹底： 推論用の主体にBedrock以外の権限（Lambda・IAM・EC2の広い権限）を与えない。8分侵害は、推論用ユーザーにLambda権限まで付いていたことが被害を拡大させました。
- シークレットの漏洩防止： S3バケットの公開設定を継続監査し、コード・設定ファイル・ノートブックにキーを直書きしない。シークレットスキャンをCI/CDとストレージの両方に配置する。
- 異常な鍵利用の検知： 新規発行直後・未知地域・深夜帯のキー利用をスコアリングし、自動で追加認証や失効につなげる。
- モデル有効化の権限分離： 新規モデルの有効化を、日常の推論主体とは別の管理権限に分離し、承認ゲートを挟む。
第3の防御層：エグレス制御と実行環境の封じ込め——自律エージェントの「次の一手」を断つ
AI駆動ポストエクスプロイトは、侵入後に外部と通信しながら「次の手」を判断し、データを持ち出します。ここを断てば、たとえ初期侵入を許しても被害の連鎖を止められます。要は「渡り歩けない・持ち出せない」インフラ設計です。
- エグレス（外向き通信）制御： ワークロードからの外向き通信を許可リスト方式に絞る。未知の宛先へのデータ送信や、外部C2・攻撃者インフラへの接続をブロックする。AML.T0024（推論API経由の持ち出し）を含め、持ち出し経路そのものを塞ぐ。
- 実行環境の封じ込め： Lambda・コンテナ・ノートブック環境に不要なネットワーク到達性を与えない。バックドア注入後の横展開先を物理的に減らす。
- 権限昇格の遮断： IAMの列挙・ポリシー変更・ロール引き受けといった昇格系APIを重点監視し、機械速度の連鎖には自動でセッションを凍結する。
- 不変な監査ログ： どの主体が、いつ、どのAPIを、どの順序で呼んだかを改ざん不能に保全する。攻撃の全チェーン（偵察→昇格→実行→持ち出し）を後から再現できる粒度で残し、事後対応と再発防止の根拠にする。
「人間の速度」を捨てる——検知から遮断までを自動化でつなぐ
本記事で繰り返してきた要点は一つに集約されます。攻撃が8分・60分で完了する以上、検知してから人間が判断していては間に合わないということです。従来のSOC運用は「アラート→人間のトリアージ→対応」を前提にしていましたが、AI速度の攻撃に対しては、検知から一次遮断までを自動化でつなぐ必要があります。
- 検知： 課金・操作・鍵利用の異常を主体ごとにスコアリングし、閾値超で自動発報。
- 遮断： 一次緩和（レート厳格化・モデル有効化凍結・キー失効・セッション無効化）を即時自動適用。人間の承認は「解除」側に置く。
- 監査： 全チェーンを不変ログに保全し、事後の立証・法的対応・チューニングに使う。
これは、NOCがトラフィックのベースラインを学習し、逸脱に対して自動でトラフィックを絞る発想そのものです。人間は「例外の解除」と「ベースラインの調整」に回り、一次対応は機械に任せる——この役割分担が、AI速度の攻撃に対する現実解です。
多層防御チェックリスト
| 層 | 対策 | 主に効く手口 |
|---|---|---|
| 課金 | 推論コストの急変・未知モデル有効化の検知 | LLMjacking |
| 課金 | アカウント／キー単位の予算アラートとログ突合 | LLMjacking |
| 鍵 | 長期キー廃止・一時認証情報化・短命化 | 両方 |
| 鍵 | 推論主体の最小権限（Lambda/IAM権限を与えない） | AI駆動ポストエクスプロイト |
| 鍵 | S3公開監査・シークレットスキャン | 両方（初期侵入） |
| 実行 | エグレス制御（許可リスト方式） | AI駆動ポストエクスプロイト |
| 実行 | 実行環境の封じ込め・不要な到達性の排除 | AI駆動ポストエクスプロイト |
| 運用 | 検知→自動遮断→不変ログの連携 | 両方（AI速度対応） |
よくある質問（Q&A）
Q1. LLMjackingは、うちのような小規模な環境でも狙われますか？
規模を問わず狙われます。攻撃者が欲しいのは「使える正規のAIコンピュート」であり、標的の企業価値ではありません。漏洩した認証情報とBedrockなどのAI権限がひとつ揃えば十分です。むしろ監視が手薄な小規模環境ほど、被害が高額化するまで気づかれにくいという逆説があります。
Q2. まず何から手をつければ効果が大きいですか？
「異常課金検知」と「長期キーの廃止」の2つです。LLMjackingは必ず課金に現れるため、アカウント／キー単位の予算アラートと未知モデル有効化の検知を入れるだけで、被害の早期発見が劇的に改善します。並行して静的アクセスキーを一時認証情報に移し、推論主体から余計な権限を剥がせば、侵入の起点と被害の拡大の両方を同時に細くできます。
Q3. 「8分で侵害」と言われても、そんな速さに人間が対応できるのでしょうか？
できません。だからこそ、検知から一次遮断までを自動化する必要があります。人間の役割は「リアルタイムのトリアージ」ではなく、「自動遮断のルール設計」と「誤遮断の解除」に移ります。人間を判断ループの中に置いたままでは、AI速度の攻撃には構造的に間に合いません。
Q4. モデル抽出・蒸留窃取の記事とは何が違うのですか？
守る対象と攻撃主体が逆です。モデル抽出・蒸留の記事は「自社が公開したAIを、人間の攻撃者が盗む」話でした。本記事は「攻撃を実行する主体がAIになり、被害面が自社のクラウド課金・鍵・インフラになる」話です。前者は推論エンドポイントを守り、後者はクラウドの認証情報・権限・課金・持ち出し経路を守ります。両方を組み合わせて初めて、2026年の脅威像に対応できます。
Q5. エグレス制御を厳しくすると、正規のワークロードが壊れませんか？
だからこそ許可リスト方式で段階的に導入します。まず既存の正規通信先を洗い出してベースライン化し、それ以外を監視（記録のみ）から始め、想定外の宛先が観測されなくなったところでブロックに切り替えます。いきなり全遮断ではなく、NOCでのポリシー投入と同じく「観測→警告→遮断」の順で慣らすのが、事業影響を抑えるコツです。
まとめ——「攻撃する側が自律化する」を前提に設計する
AIセキュリティの議論は長らく「自社のAIをどう守るか」に集中してきました。しかし2026年の現実は、攻撃を実行する主体そのものがAIになり、被害を受けるのは自社のクラウド課金・鍵・インフラという新しい軸を突きつけています。要点は3つです。
1. 財布を最初のセンサーにする。 LLMjackingは必ず課金に現れます。アカウント／キー単位のコスト異常と未知モデル有効化の検知が、最も費用対効果の高い一次防御です。
2. 盗まれても使えない鍵にする。 攻撃の起点はほぼ漏洩した認証情報です。長期キーの廃止・最小権限・シークレット衛生で、侵入の起点と被害の拡大を同時に細くします。
3. 人間の速度を捨てる。 8分・60分で完了する攻撃に、人間のトリアージは間に合いません。検知から一次遮断までを自動化でつなぎ、エグレス制御で「次の一手」を断つ——これがAI速度の攻撃に対する現実解です。
「攻撃する側も自律化する」時代に、防御だけが人間の速度に留まることはできません。課金・鍵・実行環境・運用の4層を、AI速度に間に合う自動化として組み替える——これが、自社のクラウドを資産として守るための基本姿勢です。
参考リンク
- Sysdig「LLMjacking: Stolen Cloud Credentials Used in New AI Attack」
- Sysdig「AI-assisted cloud intrusion achieves admin access in 8 minutes」
- OWASP「LLM10:2025 Unbounded Consumption」
- MITRE ATLAS「AML.T0034 Cost Harvesting」
- MITRE ATLAS「AML.T0024 Exfiltration via AI Inference API」
免責事項： 本記事は2026年8月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。フレームワークやガイドライン、報告された攻撃事例は更新されるため、最新情報は各公式ソースでご確認ください。
コメント