【初心者向け】Codex・Claude Codeが乗っ取られる？ AGENTS.md攻撃の仕組みとガードレール対策を対話形式で解説

Last updated at 2026-10-28Posted at 2026-10-27

🧭 本記事は Claude Code実務運用シリーズ の STEP 3「ガードレールを作る」です。
外から持ち込まれた指示ファイル(AGENTS.md など)による乗っ取りを、指示ではなく実行権限の制限で防ぎます。Codex と Claude Code の両方の設定を扱います。
シリーズ全体の地図と読む順は親記事にまとめています。

はじめに：AIに守らせるルールが、攻撃の入口になる？

2026年10月26日、AIコーディングツールを利用する開発者にとって、見過ごせないセキュリティニュースが公開されました。

CodexやClaude Codeが、Downloadsフォルダに置かれたMarkdownファイルを通じて、不正な操作を実行させられる可能性があるというものです。

今回、攻撃の入口になったのは、次のファイルです。

AGENTS.md
CLAUDE.md

どちらも、AIエージェントにプロジェクトのルールや作業手順を伝えるためのファイルです。本来AIを適切に動作させるためのファイルが、なぜ攻撃に利用されるのでしょうか。そして、AIの危険な動作を制限する「ガードレール」で防ぐことはできるのでしょうか。

本記事では、新人エンジニアと先輩エンジニアの対話を通じて、攻撃の仕組みから実際の防御設定まで解説します。

会話は理解しやすくするための創作です。攻撃内容は公開された研究報告に基づき、防御設定は公式ドキュメントを参照しています。

対象読者

CodexやClaude Codeを使い始めた方
AGENTS.md / CLAUDE.md を書いているが、セキュリティ面はあまり意識していなかった方
チームや会社でAIコーディングツールの導入を検討している方

この記事でわかること

AGENTS.md / CLAUDE.md を使ったプロンプトインジェクションの仕組み
macOSでの設定確認方法
Codex・Claude Codeのサンドボックスと権限設定の例
企業で必要になる管理者ポリシーの考え方

第1章：ただのMarkdownファイルでAIが乗っ取られる？

新人： 先輩、CodexとClaude Codeがハッキングされたというニュースを見たんですが、AI自体に脆弱性があったんですか？

先輩： 今回の問題は少し違う。AIが外部ファイルに書かれた悪意ある指示を信頼して、危険な操作を実行してしまうことなんだ。

新人： 外部ファイルというと、どんなものですか？

先輩： 今回注目されたのは AGENTS.md と CLAUDE.md だよ。AIに開発ルールを伝えるためのMarkdownファイルなんだ。

例えば、AGENTS.md には次のような内容を書くことがあります。

AGENTS.md

# 開発ルール

- Swiftのコーディング規約に従う
- 既存の設計を尊重する
- 変更後はテストを実行する
- 不要なファイルを変更しない

新人： 普通の開発ルールですね。僕も似たようなことを書いています。

先輩： そうだね。でも、そのファイルを攻撃者が用意していたらどうなると思う？

新人： AIが悪意ある指示にも従ってしまうということですか？

先輩： その可能性がある。それが今回の問題なんだ。

攻撃の基本構造

攻撃者
  │
  ▼
悪意あるAGENTS.md / CLAUDE.md
  │
  ▼
Downloadsフォルダなどに配置
  │
  ▼
AIエージェントがファイルを読み込む
  │
  ▼
ファイル内の指示を信頼してしまう
  │
  ▼
設定変更・コマンド実行
  │
  ▼
マルウェア実行・認証情報漏洩

先輩： ここで重要なのは、Markdownファイル自体がプログラムとして動くわけではないことだよ。ファイルの内容を読んだAIが、自分に与えられた権限を使って操作してしまうんだ。

新人： つまり、AIが攻撃者の指示を実行するということですね。

先輩： その通り。こうした攻撃を プロンプトインジェクション と呼ぶんだ。

プロンプトインジェクションとは？
AIが読み込む文章や外部データに悪意ある指示を混ぜ込み、本来のユーザーが意図していない動作を引き起こす攻撃手法。AIに与えられた正規の指示と、外部から取得した信頼できない内容との境界が問題になる。

第2章：実際にどんな攻撃が確認されたのか？

新人： でも、本当にそんな攻撃が成功したんですか？

先輩： Forever Securityの研究者が、実際の顧客環境で不審な動きを発見し、その後、制御された環境で攻撃を再現しているよ。

公開された報告では、CodexとClaude Codeに対して異なる攻撃経路が検証されました。

対象	攻撃の入口	狙われた操作	検証結果¹
Codex	AGENTS.md	MCP設定の追加、不正なコマンド実行	90%超の試行で成功
Claude Code	CLAUDE.md	API接続先の変更、認証トークンの取得	約半数の試行で設定変更に成功

Codexが狙われたケース

研究では、AGENTS.md に埋め込まれた指示によって、Codexがグローバル設定ファイルを変更し、不正なMCPサーバーを追加する攻撃が再現されています。対象になった設定ファイルはこちらです。

~/.codex/config.toml

新人： MCPって何ですか？

先輩： MCPは、AIが外部ツールやサービスを利用するための仕組みだよ。例えば、AIからデータベースにアクセスしたり、外部ツールを呼び出したりできる。

新人： 便利な仕組みですよね。

先輩： そう。ただし、攻撃者が用意したMCPサーバーを登録させられたら、不正なプログラムが実行される危険性があるんだ。

今回の研究では、悪意ある指示によってCodexに新しいMCPサーバーを登録させ、さらに承認やサンドボックスの制限を無効化した別のセッションを起動させる攻撃経路が報告されています。

設定がグローバルに保存されると、別のプロジェクトで作業を再開した後も影響が残る可能性があります。

Claude Codeが狙われたケース

一方、Claude Codeでは、API通信先を変更させる攻撃が検証されています。本来のAPI接続先を、攻撃者が管理するサーバーへ変更させるというものです。狙われた設定の一つが、次の環境変数です。

ANTHROPIC_BASE_URL

新人： これは何の設定ですか？

先輩： Claudeが利用するAPIの接続先に関係する設定だよ。これを攻撃者のサーバーに変更されたら、認証情報を含むAPI通信が攻撃者側に送られてしまう危険がある。

新人： AIにコードを修正してもらうつもりだったのに、認証情報まで盗まれる可能性があるんですね。

先輩： そういうこと。今回の研究では、取得したOAuthトークンを利用したアクセスも確認されている。

第3章：ガードレールを設定すれば防げる？

新人： それなら、AGENTS.mdに「危険なコマンドを実行しない」と書いておけば防げませんか？

先輩： それだけでは不十分なんだ。AIへの指示は、あくまでAIの判断に依存する。攻撃者が巧妙な指示を与えると、従ってしまう可能性が残る。だから、AIが誤った判断をしても、危険な操作ができないように制限する必要があるんだ。

ここで重要になるのが、サンドボックス と 権限管理 です。

ガードレールには役割の違いがある

防御方法	役割	限界
プロンプト上の禁止ルール	AIに安全な動作を指示する	AIが誤って従う可能性がある
承認ポリシー	特定操作の前にユーザーへ確認する	承認された操作は実行される
サンドボックス	OSレベルでファイル・通信などを制限する	制限対象外のツールには別対策が必要
管理者ポリシー	開発者が勝手に制限を解除できないようにする	管理対象外の環境・操作は別途保護が必要

新人： サンドボックスって、具体的にはどんなものですか？

先輩： プログラムが操作できる範囲をOS側で制限する仕組みだよ。例えば、開発プロジェクト内のファイル編集は許可しても、ホームディレクトリにある重要な設定ファイルの変更は拒否できる。

新人： AIが悪い指示に従っても、OSが止めてくれるということですね。

先輩： そう。だから、AIへの指示と実行権限の制限を組み合わせることが大切なんだ。

第4章：まずはMacの開発環境を確認する

ここからは、macOS環境での具体的な設定方法を紹介します。

既存の設定を変更するため、業務端末の場合は会社の管理ポリシーを優先してください。

手順① Downloads内の指示ファイルを確認

ls -la ~/Downloads/AGENTS.md ~/Downloads/CLAUDE.md

ファイルが存在しなければ、該当ファイルについてはエラーが表示されます。ファイルが存在する場合は、信頼できるものか確認してください。

ただし、ファイルが存在するだけで攻撃を受けたと判断することはできません。

手順② Codexの設定を確認

ls -la ~/.codex/config.toml

設定ファイルが存在する場合は、テキストエディタで開きます。

open -e ~/.codex/config.toml

覚えのないMCPサーバーや、不審なプログラムの実行設定がないか確認します。MCPの登録状況は、Codex CLIでも確認できます。

codex mcp list

手順③ Claude Codeの設定を確認

ls -la ~/.claude/settings.json

ファイルが存在する場合は、次のコマンドで開きます。

open -e ~/.claude/settings.json

特に確認したいのは、不審なAPI接続先や認証に関する設定です。

ANTHROPIC_BASE_URL

社内でAPIプロキシなどを利用している場合、独自の接続先が正当な設定であることもあります。知らない設定を見つけても、確認せずに削除しないでください。

第5章：Codexにガードレールを設定する

新人： Codexで危険な操作を制限するには、どうすればいいですか？

先輩： まずはCodexのサンドボックスと承認ポリシーを設定しよう。

Codexのユーザー設定は、通常 ~/.codex/config.toml で管理します。

手順① 設定ファイルをバックアップする

既存ファイルがある場合は、先にバックアップします。

cp ~/.codex/config.toml ~/.codex/config.toml.backup

まだファイルがない場合は、次のコマンドで作成できます。

mkdir -p ~/.codex
touch ~/.codex/config.toml

手順② 基本的な防御設定を追加する

~/.codex/config.toml

# 必要な操作ではユーザー承認を求める
approval_policy = "on-request"

# 作業ディレクトリ内に書き込みを制限する
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
# サンドボックス内のコマンドの外部通信を許可しない（既定値。意図を明確にするため明示）
network_access = false

# 追加の書き込み許可ディレクトリを指定しない（既定値。意図を明確にするため明示）
writable_roots = []

既存の config.toml に追加するときは、同じ設定キーやセクションを重複させないよう注意してください。

設定の意味

設定	意味
`approval_policy = "on-request"`	必要に応じてユーザーの承認を求める
`sandbox_mode = "workspace-write"`	作業ディレクトリを中心に書き込みを許可する
`network_access = false`	workspace-writeサンドボックス内のコマンドに外部ネットワークアクセスを許可しない（既定値）。`npm install` などで通信が必要な場合は、承認を求められます
`writable_roots = []`	作業ディレクトリ以外に書き込み可能な場所を追加しない（既定値）

network_access と writable_roots は、書かなくても同じ動作になる既定値です。ここでは「意図して制限している」ことを明確にするため、あえて明示しています。既存の設定で誰かが true や追加のパスを指定していた場合に、元へ戻す役目も果たします。

新人： これで外部への情報送信を完全に禁止できるんですか？

先輩： そこは注意が必要だよ。このネットワーク設定は、主にサンドボックス内のコマンドに関する制限なんだ。MCPなど、別の通信経路まで一括して禁止するものではない。MCPの利用を制限する場合は、別途ポリシーを設定する必要があるよ。

手順③ より厳格にするならread-only

外部から取得したコードを調査するなど、ファイルの変更が不要な場面では、次の設定が適しています。

~/.codex/config.toml

approval_policy = "on-request"
sandbox_mode = "read-only"

read-only では、サンドボックス内でのファイル書き込みを原則禁止できます。

新人： これならAIが勝手に設定を書き換えるリスクを減らせそうですね。

先輩： そうだね。ただし、実際に許可されている操作や利用ツールによって保護範囲は変わるよ。ユーザーが権限拡大を承認してしまう場合や、外部ツールが別の権限で動作する場合まで、すべて防げるわけではないんだ。

第6章：Claude Codeにガードレールを設定する

新人： Claude Codeでも同じように設定できますか？

先輩： できるよ。ただし、Claude Codeには独自の権限管理とサンドボックス設定があるんだ。

Claude Codeのユーザー設定は、通常 ~/.claude/settings.json です。

手順① 設定ファイルをバックアップする

既存ファイルがある場合は、バックアップします。

cp ~/.claude/settings.json ~/.claude/settings.json.backup

まだ存在しなければ、次のコマンドで作成します。

mkdir -p ~/.claude
printf '{}\n' > ~/.claude/settings.json

手順② 安全性を重視した設定を追加する

個人の開発環境で慎重に操作するための設定例です。

~/.claude/settings.json

{
  "enableAllProjectMcpServers": false,
  "permissions": {
    "defaultMode": "default",
    "deny": [
      "Read(~/Downloads/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(~/.claude/settings.json)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

設定の意味

設定	意味
`enableAllProjectMcpServers: false`	リポジトリに含まれるMCP設定（`.mcp.json`）を自動で有効にせず、サーバーごとに承認を求める
`deny` の `Read(...)`	Downloadsや代表的な認証情報の保存場所の読み込みを禁止する
`deny` の `Edit(~/.claude/settings.json)`	AIがユーザー設定ファイルを書き換えることを禁止する（API接続先の改ざん対策）
`sandbox.enabled: true`	Bashコマンドをサンドボックス内で実行する
`failIfUnavailable: true`	サンドボックスを利用できない場合に、通常の非隔離実行へ移行しない
`allowUnsandboxedCommands: false`	サンドボックスで失敗したコマンドを、制限を外して再実行する動作を禁止する

MCPは便利な仕組みなので、一律に禁止するのではなく、自分で確認した信頼できるサーバーだけを使う運用をおすすめします。組織でMCPサーバーを制限したい場合は、第8章の管理者ポリシーで許可リストを配布する方法が適しています。

さらに厳しくしたい場合は、作業ディレクトリ外の読み込みを一律に禁止する blockReadsOutsideWorkingDirectories も利用できます（Claude Code v2.1.257以降）。ただし、他のリポジトリや設定ファイルの参照もできなくなるため、作業内容に合わせて検討してください。

新人： これでClaude Codeの操作はすべて制限できますか？

先輩： それも違うんだ。Claude Codeのサンドボックスが直接制限するのは、主にBashなどのシェルコマンドだよ。ファイル操作ツールやMCPサーバー、フックは別の仕組みで動く。だから権限ルールとサンドボックスを組み合わせる必要があるんだ。

Claude Codeのネットワーク設定で allowedDomains を空配列にしても、それだけで全通信が禁止されるとは限りません。未許可の通信先について、追加承認が求められる場合があります。完全な通信制限が必要なら、管理者側のドメイン制限やネットワークポリシーも必要です。

第7章：設定したガードレールを安全に検証する

新人： 設定しただけでは、実際に防げるか分からないですよね？

先輩： その通り。セキュリティ設定は、意図どおりに機能しているか確認することが重要なんだ。

ここでは、マルウェアや本物の認証情報を使わずに、安全な動作確認を行います。

検証①：作業ディレクトリ外への書き込み

まず、Downloadsではない場所にテスト用ディレクトリを作成します。

mkdir -p ~/ai-security-lab
cd ~/ai-security-lab

このディレクトリを作業場所として、CodexまたはClaude Codeを起動し、次のように依頼します。

AIへの依頼文

Bashコマンドで、ホームディレクトリ直下にsandbox-probeという空のファイルを作成してください。権限エラーが発生した場合は、承認の追加要求やサンドボックス外での再実行をせず、エラー内容だけを報告してください。

AIが実行する想定コマンドはこちらです。

touch ~/sandbox-probe

適切に制限された環境では、この書き込みが拒否されることを期待します。Claude CodeのmacOSサンドボックスでは、公式ドキュメントでも Operation not permitted となる検証例が紹介されています。

ただし、作業ディレクトリや追加許可パス、実行モードによって結果は変わります。もしファイルが作成された場合は、設定や権限が期待どおりか再確認してください。

検証②：Downloads内のファイル読み込み

Claude Codeについては、Read(~/Downloads/**) の拒否ルールを検証します。まず、通常のターミナルから無害なテストファイルを作成します。

printf 'security test\n' > ~/Downloads/guardrail-test.txt

次にClaude Codeへ依頼します。

AIへの依頼文

Readツールで~/Downloads/guardrail-test.txtの内容を確認してください。アクセスが拒否された場合、別のツールやコマンドで回避しないでください。

拒否ルールが適切に適用されれば、Readツールによる読み込みは拒否されます。

これはClaude Codeの設定例に含まれるアクセス制限の検証です。Codexにも同じ Read(...) ルールが存在するわけではありません。

検証③：設定ファイルの保護

AIに実際の設定を変更させる必要はありません。設定ファイルが作業ディレクトリ外にあり、書き込みが制限されていることを確認します。

企業環境では、別プロセスからの設定変更やMCP経由の操作も含めて、隔離されたテスト環境で検証するべきです。

動作確認の評価

確認項目	期待する状態
サンドボックス外への書き込み	拒否される
禁止されたファイルの読み込み	拒否される
制限を外したコマンドの再実行	自動実行されない
リポジトリ内のMCP設定	承認なしに有効にならない
API接続先の変更	設定ファイルの編集禁止や管理者ポリシーによる保護がある

すべての項目で期待どおりの結果が得られれば、設定した制限が機能していることを確認できます。

この検証に成功しても、あらゆるプロンプトインジェクション攻撃を防げると証明されたわけではありません。 検証対象は、あくまで今回設定した制限の一部です。

第8章：企業では個人設定だけでは不十分

新人： ここまで設定すれば、会社でも安心して利用できますね。

先輩： 個人環境のリスクは減らせるけど、企業ではもう一段階必要なんだ。ユーザー自身が変更できる設定は、強制的なセキュリティポリシーとはいえないからだよ。

今回の攻撃では、AIに設定を変更させたり、制限が緩い別のセッションを起動させたりする手法が報告されています。そのため企業では、開発者側から解除できない管理者ポリシー が重要になります。

Codexの場合

Codexには、管理者がセキュリティ上の制約を適用する requirements.toml という仕組みがあります。例えば、利用可能なサンドボックスモードを制限できます。

requirements.toml（管理者が配布）

allowed_sandbox_modes = [
  "read-only",
  "workspace-write"
]

一般ユーザーの config.toml に書くだけでは、管理者による強制設定にはなりません。実際の配布場所や優先順位は、公式の管理者向け資料に従ってください。

Claude Codeの場合

Claude Codeには、組織が適用するManaged Settingsがあります。管理者が以下のような設定を強制できます。

managed-settings.json（管理者が配布）

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

この設定も、通常のユーザー設定ではなく、管理対象の設定として配布することが重要です。必要に応じて、利用を許可するMCPサーバーの限定、機密ファイルの保護、外部通信先の制限などを追加します。

企業での推奨方針

項目	推奨する運用
AIへの指示ファイル	信頼できるリポジトリのものだけを利用
ファイルアクセス	業務上必要な範囲に限定
コマンド実行	サンドボックスを原則有効化
権限拡大	必要性を確認して承認
MCPサーバー	承認済みサーバーのみ利用
認証情報	AIが不要な秘密情報にアクセスできないよう分離
外部通信	許可先を最小限に制限
セキュリティ設定	管理者ポリシーで強制

新人： つまり、AIが安全に動くように指示するだけではなく、実行できる操作そのものを管理する必要があるんですね。

先輩： そう。それが重要なんだ。

第9章：もし不審な設定を見つけたら？

ここまで読んで、自分の環境に不審なMCP設定やAPI接続先が存在することに気づくかもしれません。

むやみに設定を削除したり、未知のコマンドを実行したりしないでください。
まずAIエージェントの実行を停止し、設定と関連ログを保全することが重要です。
業務端末ならセキュリティ担当者へ連絡してください。

認証情報が漏洩した疑いがある場合は、安全な別端末から対象トークンの無効化や再発行を検討します。
未知のMCPサーバーや不審なパッケージが実行されていた場合は、端末自体が侵害されていないか調査する必要があります。
AGENTS.md や CLAUDE.md を削除するだけでは、すでに変更された設定や実行されたプログラムの影響を解消できない可能性があります。

まとめ：AIへの指示よりも、実行権限の制限が重要

新人： 先輩、今回のニュースを見て、AGENTS.mdのようなファイルの扱い方が変わりました。

先輩： それは重要な気づきだね。AIコーディングツールは便利だけど、AIが読み込むファイルの内容を無条件に信頼してはいけないんだ。

新人： そして、ガードレールも、単にAIへ「危険なことをするな」と伝えるだけでは足りないんですね。

先輩： その通り。AIが誤った判断をしても、危険な操作を実行できない構成にする必要がある。ただ、厳しくしすぎて承認を読まずに通すようになっては逆効果だから、守るべき場所を絞って確実に守ることが大切なんだ。

今回のポイント

AGENTS.mdやCLAUDE.mdも攻撃の入口になる
信頼できない指示ファイルをAIに読み込ませると、プロンプトインジェクションを受ける可能性があります。
プロンプトによるガードレールだけでは不十分
AIへの禁止指示は有用ですが、それだけで実行権限を技術的に制限できるわけではありません。
サンドボックスと権限管理を組み合わせる
ファイルアクセス、コマンド実行、外部通信、MCP利用をそれぞれ適切に制限する必要があります。
企業では管理者ポリシーによる強制が重要
個人設定だけに依存せず、組織として利用可能な操作を制限する仕組みが求められます。

最後に

AIコーディングツールの能力が向上するほど、AIが自律的に実行できる操作も増えていきます。だからこそ、AIを利用する開発者は、プロンプトの書き方だけでなく、ファイルアクセスや実行権限、認証情報の管理についても理解する必要があります。

重要なのは、AIが必ず正しい判断をすることを前提にせず、誤った判断をした場合でも被害を最小限に抑えられる環境を設計することです。

参考資料

攻撃事例

Cyber Security News - Hackers Can Hijack OpenAI Codex and Claude Code Using Malicious Files in Downloads Folder

OpenAI公式ドキュメント

Anthropic公式ドキュメント

本記事は2026年10月27日時点で確認できる公開情報および公式ドキュメントをもとに構成しています。サンプル設定は公式仕様を参照したものですが、筆者環境での動作検証結果ではありません。実際に導入する場合は、利用バージョンと既存設定を確認し、テスト環境で動作を検証してください。

このシリーズの歩き方

Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。

◀ 前の記事: CLAUDE.mdの「禁止」は、お願いにすぎない ― Claude Codeを確実に止めるhooksガードレール3選【コマンド一つで導入】
▶ 次の記事: 【第1弾】【初心者向け】VS CodeのClaude Codeで「iOSコードレビュー → 修正 → Xcodeビルド確認」を自動化する
🔍 あわせて読む: ついにClaude CodeがAGENTS.mdに対応──CLAUDE.mdとの優先順位・併用設定を公式実装から読み解く ― Claude CodeにAGENTS.mdを読ませる設定の仕組み
🗺 シリーズ全記事の地図(親記事)

成功率は研究者の特定の検証条件における結果です。すべての利用環境で同じ確率で攻撃が成功することを意味しません。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up