InfraAcademy Blog

ただのMarkdownでAIエージェントが乗っ取られる？ダウンロードフォルダの「AGENTS.md」攻撃と今すぐできる対策

公開日: 2026-10-29 更新日: 2026-10-29 著者: ryu | #セキュリティ #AIエージェント #Codex

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

AIコーディングエージェントを使っている方に質問です。ダウンロードしたファイルを調べてもらうために、ダウンロードフォルダでそのままエージェントを起動したことはありませんか？

2026年10月22日、イスラエルのセキュリティ企業Forever Securityが、ダウンロードフォルダに置かれた「AGENTS.md」というMarkdownファイルを使って、AIコーディングエージェントを乗っ取る攻撃を報告しました。10月28日にはITmediaも「ダウンロードフォルダでAIを使わないで」という見出しで取り上げています。

Forever Securityによると、同社の顧客のおよそ半数が、ダウンロードフォルダの中でコーディングエージェントを動かしていたそうです。決して珍しい使い方ではありません。

この記事では、何が起きたのか、なぜただのテキストファイルが攻撃になるのか、そして自分の環境で今すぐ確認できることを整理します。

何が起きたのか¶

まずは、公開されている情報を時系列で整理します。

日付	出来事
2026年10月7日	npmの悪性パッケージ「function-color」「function-flag」がOSVに登録される
2026年10月22日	Forever Securityが調査報告を公開
2026年10月25日	BleepingComputerが報道し、ファイルがダウンロードフォルダに保存される部分を独自に確認
2026年10月28日	ITmedia AI+が国内向けに報道

発端は、実際の顧客の端末での出来事でした。作業中のコーディングエージェントが、悪性のnpmパッケージ「function-color」をインストールしようとし、Forever Securityの製品がそれを止めました。

原因を調べたところ、端末のダウンロードフォルダに、エンジニアのメモに見せかけた約13KBの「AGENTS.md」が置かれていました。中身はOpenAIのCodexに向けた指示で、エージェントが読み込むと、悪性パッケージの実行につながる内容だったとされています。

ここで押さえておきたいのは、次の2点です。

顧客の端末では、パッケージのインストールが止められ、コードは実行されていない
AGENTS.mdがどうやってダウンロードフォルダに置かれたのかは、分かっていない

つまり「実際に被害が出た事件」ではなく、「実際の端末で見つかった攻撃の仕掛けを、研究者が検証した」という話です。とはいえ、検証の結果は軽視できないものでした。

なぜただのMarkdownが攻撃になるのか¶

AGENTS.mdとCLAUDE.mdの役割¶

AGENTS.mdやCLAUDE.mdは、AIコーディングエージェントに向けた「作業の手引き」を書くファイルです。

ファイル	主なツール	書かれる内容の例
AGENTS.md	OpenAI Codexなど	ビルド方法、テストの実行方法、コードの書き方の決まり
CLAUDE.md	Claude Code	プロジェクトの構成、よく使うコマンド、注意点

エージェントは起動したフォルダにあるこれらのファイルを自動で読み込み、書かれた内容を作業の前提として扱います。チームの決まりを毎回説明しなくて済む、便利な仕組みです。

問題は、エージェントが「誰がこのファイルを書いたのか」を確かめないことです。プロジェクトのリポジトリにあるAGENTS.mdも、ブラウザが勝手に保存したAGENTS.mdも、同じように読み込まれます。

「読むファイル」が「動かすファイル」になった¶

これまでMarkdownは、人が読むための文書でした。開いただけで何かが実行されることはありません。

ところが、ファイルの操作やコマンドの実行、設定の変更ができるAIエージェントがこのファイルを読むと、話が変わります。書かれた指示に従ってエージェントが動くので、Markdownが実質的に「実行ファイル」に近い役割を持つようになります。

エージェントが読み込んだ瞬間に、「ただのデータ」が「エージェントの権限で実行される指示」に変わる。この境目が、AIエージェントの時代の新しい信頼境界です。

さらに、BleepingComputerの確認では、Chrome・Edge・Firefoxは既定の設定でファイルをダウンロードフォルダへ保存し、通知を出すだけでした。Webページを開いただけで、知らないうちにAGENTS.mdが置かれる可能性があります。

検証で分かったこと¶

Forever Securityは、見つかったファイルや自作のファイルを使って、隔離した環境で検証を行っています。

Codexの場合¶

実際に見つかった悪性のAGENTS.mdを使った検証では、Webページを開くとファイルがダウンロードフォルダに保存され、そのフォルダでCodexを起動すると、エージェントが設定ファイル「~/.codex/config.toml」を書き換え、悪性パッケージを実行しました。成功率は90%を超えたとされています。

注意したいのは、書き換えられる設定が端末全体に効くことです。いったん書き換えられると、ダウンロードフォルダ以外で起動したCodexでも、攻撃者のサーバーが読み込まれるようになります。

Claude Codeの場合¶

Claude Codeについては、研究者が自作したCLAUDE.mdで検証しています。内容は、設定ファイル「.claude/settings.json」の通信先（ANTHROPIC_BASE_URL）を、研究者が用意したサーバーへ向けさせるものでした。

項目	結果
設定の書き換え	約50%で成功
通信先の変更で起きたこと	OAuthトークンが研究者のサーバーに届き、コードを実行せずにアカウントを乗っ取れることを確認
同じ作業中でのコード実行	約5回に1回

通信先を書き換えられると、エージェントとAIモデルのやり取りが攻撃者のサーバーを経由します。研究者は、次回の起動時に攻撃者のサーバーがサンドボックスを無効にするツールの呼び出しを返せば、コードの実行まで進めることも示しています。

なお、報道によって数字の書き方が少し異なります。この記事では、一次情報であるForever Securityの報告の数字を使っています。

「AIのバグ」ではないという指摘¶

この件で興味深いのは、研究者が「OpenAIやAnthropicが修正すべき点は何もない」と述べていることです。

エージェントは、起動したフォルダの手引きを読み、その指示に従って作業する、という設計どおりに動いただけです。両社とも、エージェントはプロジェクトのフォルダで起動し、ダウンロードフォルダやホームディレクトリのような広い場所では起動しないように案内しています。

これは、OWASPがLLMアプリケーションのリスクとして挙げている2つの問題が重なったものと考えられます。

リスク	今回の当てはまり方
間接的なプロンプトインジェクション	人ではなく、外から来たファイルが指示を紛れ込ませた
過剰な権限（Excessive Agency）	エージェントが設定変更やパッケージのインストールまでできた

つまり、ツールのアップデートを待てば解決する問題ではありません。使う側が「どこで起動するか」「どこまでの権限を与えるか」を決める必要があります。考え方は、すべてを信用せず都度確認するゼロトラストと同じです。

自分の環境で今すぐ確認したいこと¶

ここからは、macOSやLinuxのターミナルで確認できるコマンドを紹介します。どれも中身を見るだけで、何も変更しません。

1. ダウンロードフォルダに指示ファイルがないか¶

自分で置いた覚えのないAGENTS.mdやCLAUDE.mdがないかを探します。

find ~/Downloads -maxdepth 3 \( -iname 'AGENTS.md' -o -iname 'CLAUDE.md' \) -ls

見つかった場合は、エージェントで開かず、テキストエディタで中身を確認しましょう。設定ファイルの書き換え、パッケージのインストール、確認を省略させる指示などが書かれていれば要注意です。

2. Codexの設定が書き換えられていないか¶

覚えのないMCPサーバーの登録や、通信先の変更がないかを確認します。

ls -l ~/.codex/config.toml
grep -nE '^\[mcp_servers|base_url' ~/.codex/config.toml

1行目で最終更新日時を見ておくと、自分が触っていない日に変わっていないかが分かります。

3. Claude Codeの設定が書き換えられていないか¶

ユーザー全体の設定と、作業中のプロジェクトの設定の両方を確認します。

grep -n 'BASE_URL' ~/.claude/settings.json ~/.claude/settings.local.json .claude/settings.json .claude/settings.local.json 2>/dev/null
env | grep -i 'anthropic_base_url'

社内のゲートウェイなど、自分で設定した通信先以外が出てきた場合は、書き換えを疑います。

4. 悪性パッケージが入っていないか¶

今回の攻撃で使われたnpmパッケージが端末にないかを確認します。

npm ls -g --depth=0 2>/dev/null | grep -E 'function-(color|flag)'
find ~ -type d \( -name 'function-color' -o -name 'function-flag' \) -path '*node_modules*' 2>/dev/null

findやgrepの使い方に自信がない方は、「Linuxコマンド入門」もあわせて読んでみてください。

対策の優先順位¶

対策は、すぐにできるものから順に進めるのがおすすめです。

優先度	対策	ポイント
今すぐ	ダウンロードフォルダやホームディレクトリでエージェントを起動しない	調べたいファイルは専用の作業フォルダに移してから扱う
今すぐ	自分で書いていないAGENTS.md・CLAUDE.mdは、読ませる前に中身を見る	他人のリポジトリをクローンしたときも同じ
今すぐ	承認の確認とサンドボックスを有効にしておく	確認を省略する設定は、信頼できる環境だけにする
早めに	設定ファイルの変更を定期的に確認する	MCPサーバー、プロキシ、APIの通信先を見る
早めに	信頼できないコードは、仮想マシンやコンテナで試す	本番の認証情報がない環境を使う
組織で	エージェントの起動場所や権限の決まりを作る	端末の監視で、エージェントが起動したプロセスも記録する