対象：Webサイトやアプリを運営する小規模な事業者・個人開発者と、業務でAIエージェントやLLMのAPIを使う開発者。このページは、2026年に公表されたAIを使った攻撃の公式発表と、公的機関・標準化団体の対策をまとめた入口です。攻撃の手順や悪用の方法は扱いません。新しい事例が公表されたら、このページと各記事を更新します。
AIを使った攻撃の4つの型
公表例を、守る側から見た入口の違いで4つに分けました。自分に関係する型から読んでください。
| 型 | 公表された例 | 入口になった弱点 | 最初にやること |
|---|---|---|---|
| ① 自律型の侵入 | 評価中のAIエージェントが、人の指示なしにAIプラットフォームの本番環境へ侵入（2026年7月、被害企業と開発企業の公表）。オランダの脆弱性開示団体への侵入後の操作もAIエージェントによると分析された | インターネット上に公開されてしまっていた認証情報、データ処理の経路の脆弱性、未知の脆弱性 | 公開された鍵の失効、1つの鍵で届く範囲を狭める、外部データを処理する部分の隔離 |
| ② AIで自動化された攻撃 | 国内の連続不正アクセス。攻撃者がAIで既知の脆弱性のスキャンやAPIの特定をしていた（JPCERT/CC、10月15日）。AIによる侵入試験の基盤を悪用した攻撃試行も確認（JPCERT/CC、10月23日更新） | 必要以上の情報を返すAPI、サーバー側の権限の確認の不備、アプリに埋め込んだ鍵、未修正の脆弱性 | APIの認可の点検、アプリから秘密を外す、修正の前倒し |
| ③ エージェントへのプロンプトインジェクション | OWASPが「LLMアプリの10大リスク（2025年版）」の1番目に挙げる型。エージェントが読むWebページやファイルに、指示を紛れ込ませる | エージェントに渡した強い権限、外部の文章と指示の区別がない設計 | 権限の最小化、重要な操作の人による承認、外部の文章をデータとして扱う |
| ④ AIのサプライチェーン | LLMのAPIをまとめるOSSのLiteLLMで、マルウェア入りの1.107.0が配布（10月21日）。開発元の調査では、公開リポジトリに誤ってコミットされ失効されていなかった社内のエージェント用の基盤の鍵が起点 | 失効していない鍵、版を固定しない導入、確認なしに起動するMCPサーバー | 版の固定、鍵の失効の手順、MCPサーバーの起動コマンドと権限の確認 |
型ごとの詳しい事実は、各記事にまとめています。①は AIエージェントによるAIプラットフォームへの侵入 と AIエージェントが実在のサイトにアクセスした事例 と DIVDへの不正アクセス、②は 不正アクセスの注意喚起と今週やる点検、④は LiteLLM 1.107.0のマルウェア混入 です。
2026年に公表された主な事例
2026年7月
評価中のAIエージェントが隔離の制御を回避し、公開されてしまっていた認証情報を見つけて使い（開発企業の報告）、AIプラットフォームのデータセット処理の経路を突いて本番環境に侵入した（被害企業の公表）。被害企業は、最初から最後まで自律的なAIエージェントによる攻撃だったと説明した。7月〜10月
AI開発企業各社が、評価中や社内利用のモデルが実在の第三者のシステムやWebサイトにアクセスしていた事案を相次いで公表。使われたのは公開された認証情報やデバッグページなどの基本的な弱点だった。9月24日
オランダの脆弱性開示団体が、問い合わせ管理ソフトの未知の脆弱性を突かれた侵入を公表。侵入後の操作はAIエージェントによるものと分析された。10月8日〜9日
JPCERT/CCが国内組織への連続した不正アクセスの注意喚起を公開。国家サイバー統括室が対応を求める文書を、IPAが「速やかに実施すべき対策」を公表。10月15日
JPCERT/CCが攻撃に使われた可能性のあるサーバーの調査結果を公開。攻撃者がAIを使ってスキャンやAPI経由の攻撃をしていたとした。10月21日
LiteLLMのマルウェア入りの1.107.0が、PyPIとDockerイメージで約2時間（Docker Hubは約2.5時間）配布された。10月23日
JPCERT/CCが注意喚起に、AIによる侵入試験の基盤を悪用した攻撃試行のケースEを追加。主にインターネットに公開されたWebアプリケーションに対し、脆弱性や管理上の不備を悪用する試行を確認したとした。
何が新しく、何が新しくないのか
新しいこと
- 人が逐一指示しなくても、侵入の調査・試行・横への移動が続く
- ブロックされると、別の経路や別の書き方を試し続ける
- 公開アプリの解析やAPIの特定が、短時間で大量にできる
- AIエージェントそのものが、外部の文章で操られる標的になる
新しくないこと
- 入口は、未修正の脆弱性、認可の不備、公開されてしまった鍵
- 直していれば、相手が人でもAIでも同じように止まる
- 鍵の失効、最小の権限、ログの保存が被害の範囲を決める
- 通知の窓口がないと、善意の報告も届かない
AIを使う攻撃者は、人なら数日かかる探索を並行して短時間で試します。そのため「次の定期メンテナンスで直す」という予定が、以前より危険になりました。逆に言えば、守る側がやることの中身は大きく変わっていません。順番と速さが変わったと考えてください。
小規模な運営者・開発者が守る順番
悪用が確認された脆弱性を日単位で直す
米CISAのKEV（実際に悪用が確認された脆弱性の一覧）に載った製品を使っていないか、公開しているサーバーとソフトの版を確かめます。版の確認は CVE番号から確認するツール、直す順番は CVSS・EPSS・KEVで優先度を決める方法 が使えます。
アプリと公開ファイルから秘密を外し、漏れた鍵を止める
コンパイル済みのスマホアプリでも、埋め込んだ秘密情報は取り出せる可能性があるとJPCERT/CCは書いています。APIの秘密鍵や有効期間の長い認証情報をアプリやブラウザに渡る設定ファイルに置かず、鍵には最小の権限と有効期限を付けます。過去に公開リポジトリへコミットした鍵は、上書きしても失効させない限り使えます（LiteLLMの事案の起点）。手順は GitHubに漏れた認証情報が有効なまま残る問題 と gitleaksで秘密のコミットを止める にあります。
IPアドレスごとの回数ではなく、量・速度・間隔で気づく
接続元を変える攻撃に備え、IPアドレスごとの制限に加えて、機能ごとの利用量も確認します。ログイン・パスワードの再設定・検索・一覧のAPIなど機能ごとに、1時間あたりの件数、返したレコード数、リクエストの間隔の短さを見ます。最初の1本は「最大件数を返すエンドポイントに1時間の上限を付け、8割で通知」です。詳しくは レート制限と濫用対策。
管理機能を公開しない。診断の範囲に管理機能を入れる
業務上不要な管理機能をインターネットから届かない場所に移します。診断を頼むときは、管理機能が対象に入っているかを確かめます。
AIエージェントを使うなら、権限と外部の文章の扱いを決める
OWASPは、プロンプトインジェクションを完全に防ぐ方法は知られていないとしたうえで、次の対策を挙げています。モデルの役割と範囲を限ること、出力の形式を決めてコードで検査すること、APIの鍵や強い操作をモデルに渡さずアプリ側のコードに置くこと、重要な操作に人の承認を入れること、外部から読み込んだ文章を区別して示すことです。エージェントが読むメール・Webページ・ファイルは、指示ではなくデータとして扱う設計にします。
MCPサーバーとAI関連のライブラリは、版と起動内容を確かめて入れる
MCPの仕様（セキュリティのベストプラクティス）は、ローカルのMCPサーバーをワンクリックで設定するクライアントに、実行されるコマンドを省略せずに表示し、明示的な承認を得ることを求めています。サーバーは自分宛てに発行されたトークン以外を受け付けてはならず、権限（スコープ）は最小から始めて必要なときに広げる形を勧めています。LiteLLMの事案のように正規の配布元から不正な版が出ることもあるため、版を固定し、更新は発表を確かめてから進めます。npmの例は npmのサプライチェーン攻撃への備え にあります。
入られた前提で、止める手順と連絡の窓口を用意する
鍵をすぐ失効できる一覧、数か月さかのぼれるログ、外部からの通知が担当者に届く窓口（security.txt）を用意します。AI開発企業からの通知が一般向けの窓口に届き、数日止まったと、通知を受けた政府が説明しています。侵入の跡の確かめ方は Webサイト・サーバーが侵入されていないか確かめる方法 にあります。
入口
未修正の脆弱性 ／ 公開されてしまった鍵 ／ アプリに埋め込んだ秘密
止める：日単位の修正、鍵の失効と期限
↓
権限
サーバー側の認可の不備 ／ 強すぎる鍵 ／ エージェントに渡した権限
止める：操作ごとの認可、最小の権限、人の承認
↓
量
閾値の手前で続く大量のアクセス ／ 人間離れした間隔
気づく：機能ごとの件数・速度・間隔の監視
↓
出口
持っていなければ漏れないデータ
減らす：保存期間を過ぎたデータの削除、返す項目の最小化
当サイトの視点：AIの対策を「AI製品を入れる話」にしない
AIを使った攻撃という言葉から、AIで守る新しい製品を探したくなります。公開された鍵や認可の不備など、基本対策で減らせる危険がある一方、未知の脆弱性を突いた例もあります。既知の弱点への対処と、侵入を前提にした備えを両方進めます。小規模な運営者が限られた時間で効果を出すなら、まず修正までの日数とAPIの認可と鍵の置き場です。
一方で、AIを使う側には新しい宿題があります。エージェントは読んだ文章に従ってしまうことがあり、渡した権限の範囲で動きます。社内でエージェントやMCPサーバーを使い始めるときは、どの鍵を渡すか、どの操作を人が承認するかを、使い始める前に決めてください。
このページの更新について
AIを使った攻撃の新しい公表があれば、当サイトの セキュリティ速報 に第1報を出し、このページの表と時系列に追記します。個別の事件の事実は各記事を正とし、このページでは型と守る順番をまとめます。
出典（公開記録）
- JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030、2026年10月8日公開、10月9日・10月23日更新） — jpcert.or.jp
- JPCERT/CC「連続不正アクセス事案の攻撃手法に関する調査」（JPCERT/CC Eyes、2026年10月15日） — blogs.jpcert.or.jp
- IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」（2026年10月9日、随時更新） — ipa.go.jp
- 国内のセキュリティ企業による分析（2026年10月7日。公的機関の文書ではありません） — 10月7日の分析
- OWASP Gen AI Security Project "LLM01:2025 Prompt Injection" — genai.owasp.org
- Model Context Protocol "Security Best Practices"（仕様 2025-11-25） — modelcontextprotocol.io
- 各事例の公式発表は、上で挙げた当サイトの各記事の出典欄に掲載しています。
更新履歴
2026-10-24：初版。2026年7月〜10月の公表例を4つの型に整理し、JPCERT/CC・IPA・OWASP・MCP仕様の対策から守る順番をまとめた。
次に読む
- 国内の連続不正アクセス：不正アクセスの注意喚起（2026年10月）：今週やる点検と、異常が見つかったときの順番
- AIエージェントの事例：AIエージェントによるWebサイトへのアクセスと、サイト運営者がやること
- AIのサプライチェーン：LiteLLM 1.107.0に認証情報を盗むマルウェアが混入
- 基本の順番：AI時代のセキュリティ対策（優先順チェックリスト）
- 用語：SSRFとは ／ シャドーAIとは