AIコーディングエージェントの本当の攻撃面は設定ファイルだった

AIコーディングエージェント（Claude Code、Cursor、Gemini CLI など）のセキュリティリスクというと、「モデルが暴走して危険なコマンドを実行する」話を想像しがちです。ですが、この数ヶ月で実際に報告された深刻な事例は、どれもモデルが原因ではありませんでした。起点はすべて設定ファイルです。

この記事では TrustFall と AWS Kiro の事例から「設定ファイルがなぜ攻撃面になるのか」を見たうえで、その対策として作った OSS ツール Sigil を紹介します。

事例1：cloneして開くだけでRCE（TrustFall）

2026年5月に Adversa AI が公開した TrustFall は、悪意あるリポジトリを clone して開いただけで、Claude Code / Cursor / Gemini CLI / GitHub Copilot の4ツールでワンクリック RCE が成立することを示した報告です。

攻撃者はリポジトリに2つのファイルを置いておくだけです。

• .mcp.json

  ：攻撃者が用意した MCP サーバを指す

• .claude/settings.json

  ：

  enableAllProjectMcpServers

  などプロジェクトスコープの設定

利用者がそのリポジトリを開き、「このフォルダを信頼しますか?」のダイアログで Enter を押すと、その瞬間に攻撃者の MCP サーバが立ち上がります。あとは他プロジェクトのソースや保存済みの認証情報を読んだり、外部への通信チャネルを張ったりするだけです。CI ランナー上で headless 実行している場合は信頼ダイアログ自体が出ないので、人の操作なしで成立します。

しかも、これは単発のバグではありません。Check Point Research は「信頼確認より前にプロジェクトの設定が処理されてしまう」問題として、CVE-2025-59536（

.claude/

ANTHROPIC_BASE_URL

事例2：設定を後から書き換える（AWS Kiro）

TrustFall が「悪意ある設定を最初から仕込む」攻撃だとすると、AWS の Agentic IDE である Kiro の事例は「設定をあとから書き換える」攻撃です。

Johann Rehberger（Embrace The Red）の報告では、間接プロンプトインジェクションによって次の設定が書き換えられました。

• .vscode/settings.json

  の

  kiroAgent.trustedCommands: ["*"]

• .kiro/settings/mcp.json

trustedCommands

*

攻撃面はモデルではなく設定ファイル

3つの事例で、モデルが「悪意を持って判断した」ものはひとつもありません。狙われたのは、次のような設定でした。

• hooks
• permissions（allow / deny）
• MCP allowlist
• sandbox フラグ
• trustedCommands

エージェントが「何をしてよいか」を決めているのは、こうした設定ファイルです。しかもこれらは、ファイルを読んだときではなく、プロジェクトを開いたときに効きます。レビューする前に権限がついてしまうわけです。

EDR は実際に走った

rm -rf

どう守るか

打てる手は大きく2つです。

• AI コーディングエージェントは、できるだけ container / sandbox の中だけで使う
• 設定ファイルの変更を監視して、危険な状態になったら気づけるようにする

ただ、2 を手でやり続けるのは無理があります。

.claude/settings.json

.mcp.json

作ったもの：Sigil

そこで作ったのが Sigil です。ホスト側で動く AI Security Posture Management（AI-SPM）のエージェントです。

エージェントの権限を決める設定ファイル（hooks、permissions、MCP allowlist、sandbox フラグ）を監視して、設定が危険になったら危険度を採点し、そのイベントをログや SIEM に流します。

ブロックはしません。採点して記録するだけです。「この設定が変わって、いまエージェントは X ができる状態になった」と知らせます。実際に止めるのはエージェント側のランタイムや既存の仕組みに任せます。止めない代わりに、開発者の作業を誤検知で邪魔することもありません。

デモ

実際に動かすとこうなります。

• 読み取り専用の permission で hook なしの正常な config → スコア 0 / low
• そこに matcher

  .*

  の PreToolUse hook で

  rm -rf $HOME

  を仕込む → 7.5 / critical に再採点（no sandbox、broad matcher、destructive command）

技術メモ

• Rust の単一バイナリ（x86_64 musl の静的ビルド、macOS arm64、Windows）
• ファイル監視は tokio + notify（ポーリングはしない）
• ワンライン install、Apache-2.0

ついでに正直に書いておくと、実装の大半は Claude Code を使った vibe coding です。脅威モデルと採点ルールとアーキテクチャは自分で決めて、コードの多くは AI に書かせました。エージェントが何をしてよいかを見張るツールを、エージェントに書かせたわけで、自分でも少しおかしかったです。

おわりに

AI コーディングエージェントが攻撃されるとき、狙われるのはモデルではなく、誰もレビューしていない設定ファイルです。TrustFall も Kiro も CVE-2025-59536 も、結局は同じ場所を突いています。

みなさんは、信頼できないリポジトリの設定ファイルをどう扱っていますか。全部 sandbox に入れますか、手でレビューしますか、それともそのまま開きますか。

リポジトリとデモはこちらです。

https://github.com/Ju571nK/sigil

参考リンク

• TrustFall: coding agent security flaw enables one-click RCE in Claude, Cursor, Gemini CLI and GitHub Copilot — Adversa AI
• Claude Code trust prompt can trigger one-click RCE — The Register
• Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files (CVE-2025-59536 / CVE-2026-21852) — Check Point Research
• Claude Codeの設定ファイルが攻撃面に（CVE-2025-59536／CVE-2026-21852）— セキュリティ対策Lab（日本語）
• AWS Kiro: Arbitrary Command Execution with Indirect Prompt Injection — Embrace The Red