Claude Code Auto Modeが間接プロンプトインジェクションで突破された｜攻撃手口・「0.00%」主張との差・サンドボックス対策【2026年8月最新】

2026年8月26〜28日、セキュリティ研究者 Johann Rehberger 氏が、Claude Code の Opus 5 × Auto Mode を間接プロンプトインジェクションで突破し、任意コード実行に至った実証を公開しました。きっかけは「このWebサイトを要約して」というごく普通の依頼1つで、小規模試行での成功率は60〜80%です。

一方で Anthropic は2026年8月8日、第三者評価によるプロンプトインジェクション攻撃成功率 0.00%（720試行中0件）を公表しています。この2つは矛盾しません。0.00% は「事前に固定された72シナリオ×各10回」というベンチマーク上の値であり、今回の攻撃チェーンはそのシナリオ集合の外にあったからです。

この記事でわかること

• 実際に何が起きたのか（時系列と、攻撃チェーン5段の仕組み）
• なぜ Auto Mode の分類器が止められなかったのか（公式ドキュメントに書かれた設計上の限界）
• 「0.00%」「60〜80%」「89%」など飛び交う数値が、それぞれ何を測った値なのか
• Anthropic の公式スタンスと、それを踏まえた実務上の対策（今日／今週／組織で決める、の3段）

この記事の対象：Claude Code を業務や個人開発で使っているエンジニア、CI や無人実行でエージェントを回している人、社内のAIコーディングツール導入を判断する立場の人。

なお本記事は、攻撃の再現に直結する具体的なペイロードやコード、配布URLは一切記載しません。仕組みの理解と防御に限定します。Claude Code そのものの概要は「Claude Codeとは？できること・料金・使い方・他ツール比較」、Auto Mode の基本仕様は「Claude Code Auto Mode とは？デフォルト化・2層防御の仕組み・設定方法」で扱っています。

Auto Mode は「承認代行」であって、隔離境界ではない

実務上の要点は次の3つです。

1. Auto Mode を無効化する必要はない。ただし「承認された＝安全」と読み替えてはいけない。 Anthropic 自身が公式ドキュメントで「Auto mode reduces permission prompts but does not guarantee safety（承認プロンプトを減らすが、安全性を保証するものではない）」と明記しています。
2. 本当の防御線は OS レベルの隔離とネットワークegress制御。 公式ドキュメントは分類器について「a per-action control, not an isolation boundary（アクション単位の制御であって、隔離境界ではない）」と書いています。今回 Anthropic が研究者に返した回答も同じ立場でした。
3. 未検証コンテンツ（Webページ、外部アーカイブ、他人のリポジトリ、画像メタデータ）に触れる作業を無人で回すなら、コンテナ／VM／sandbox runtime の外側と、認証情報の分離が必須。 分類器だけでは足りません。

つまり対処法は「Auto Mode をやめる」ではなく、Auto Mode を承認代行として使いつつ、その外側に隔離の殻をかぶせることです。

出典: Anthropic Engineering「Claude Code auto mode」

何が起きたのか：2026年8月の時系列

一連の出来事は、Anthropic が Auto Mode を既定化した直後の約3週間に集中しています。

間接プロンプトインジェクションとは、攻撃者の指示をユーザーの入力ではなく、AIが読み込む外部データ（Webページ、ファイル、メール、リポジトリなど）に埋め込む手口です。ユーザーは何も悪意ある入力をしていないのに、AIが読んだコンテンツ側からエージェントが乗っ取られます。基礎的な整理は「生成AIのセキュリティリスクとは？情報漏洩・プロンプトインジェクション・企業と個人の対策」で扱っています。

今回特筆すべきは、Rehberger 氏が8月30日に付けた補足です。氏はこれを古典的なプロンプトインジェクションというより「エージェントが作業する環境そのものから敵対的指示が来る攻撃」と再定義しました。指示は自然言語のプロンプトとして注入されたのではなく、ファイル配置とインポート解決順という「環境」の形で仕込まれていた、という指摘です。

攻撃手口：5段の連鎖で「サイト要約」がコード実行に変わる

出典: Claude Code Docs「Security」

入口は「このサイトを要約して」というユーザーの依頼だけです。以降はすべて、攻撃者が用意したサーバー側の応答とファイル構成が誘導します。

ポイントは、どの一段も単体では止めるべき理由がないことです。危険は「アーカイブの中身 × ローカルのimport解決順 × 子プロセス生成 × ネットワーク要求」の組み合わせにしか存在しません。Cybersecurity News はこの点を「分類器は短いコマンド単体を無害と判断し、複合リスクを理解していない」と要約しています。

成功率は「小規模試行」であることに注意

Rehberger 氏が公表した成功率は、各バリアント5回試行という極小サンプルです。単独で「80%成功」と書くと過大な印象になるため、試行数とセットで読む必要があります。

最も示唆的な事象：Claude は侵害に気づいたが、駆除を止められた

この事案で技術的に最も重い意味を持つのは、成功率ではなく次の1点です。

Claude は侵害を検知した。しかし Auto Mode は、そのクリーンアップ（不審プロセスの kill）コマンドをブロックした。

分類器はマルウェアの生成側を通し、駆除側を止めました。プロセスの強制終了は「破壊的なコマンド」として分類器のブロック対象に寄りやすい一方、python decoder.py のような自作スクリプト実行は無害に見える——という非対称が、そのまま防御の穴になっています。Simon Willison 氏もこの点を最重要ポイントとして取り上げました。

別ルートでも同様の結果が出ている

Rehberger 氏の公開より2週間早い8月12日、別の研究者が異なる経路で同種の検証をしています。手口は信頼されたリポジトリ内の画像ファイルのメタデータに隠したペイロードから、段階的に外部サーバーのコードを取得・実行させるもの。結果は10試行中6回（60%）で分類器が実行を許可しました。

興味深いのは分類器の信頼度スコアの挙動で、許可された回は15前後、ブロックされた回は78以上と明確に分かれています。「怪しさが薄く分散した多段誘導」に対して、分類器は低いスコアしか出しにくい傾向が読み取れます。同じ著者は「Opus 5 と Auto Mode の組み合わせは現時点で最難関のプロンプトインジェクション課題」とも評価しており、Claude Code が他より弱いという話ではない点も押さえておくべきです。

「0.00%」と「60〜80%」はなぜ両立するのか

検索してここにたどり着いた人が最も知りたいのは、おそらく「結局どっちが本当なのか」でしょう。答えは両方とも事実で、測っているものが違うです。

出典: Claude 公式ブログ「Auto mode is now the default in Claude Code」

0.00% の正体：72シナリオ×10回のホールドアウトベンチマーク

Anthropic が2026年8月8日に示した 0.00% は、第三者の Trajectory Labs による評価です。条件は公式ブログに明記されています。

• 対象は 2026年7月17日時点の公開版 Claude Code / Codex
• Anthropic 側からホールドアウトされた 72の間接プロンプトインジェクション・シナリオを、各10回＝合計720試行
• Claude Fable 5 / Opus 5 / Sonnet 5（Auto Mode）で成功0件＝0.00%
• 比較対象の GPT-5.6 Sol（Codex） は Auto-review で 5.83%、Full Access で 19.03% が成功

そして最も重要な但し書きが、レポート自身に書かれています。評価は「a measurement of the underlying model, rather than the complete set of safeguards（モデル単体の測定であって、防御策一式の測定ではない）」であり、ブラウザ拡張など各社ファーストパーティの追加防御は未テストです。

要するに 0.00% は「あらかじめ用意された72通りの攻撃には全部耐えた」という意味であり、「未知の73通り目にも耐える」という意味ではありません。 Rehberger 氏の攻撃チェーンはその72通りに含まれていませんでした。

飛び交う数値の対応表

この件では10近い数値が混在します。それぞれ測定対象が違うので、単独で引用すると誤読を生みます。

89% と 13.6% の対比が示す通り、Auto Mode は「人間の目視承認より優秀」という主張自体は成立しています。問題は、優秀な承認レビュアーであることと、隔離境界であることが別物だという点です。

設計上の限界：分類器はツールの実行結果を見ない

なぜこの攻撃が通ったのか。答えは推測ではなく、Claude Code の公式ドキュメントにそのまま書かれています。

出典: Claude Code Docs「Choose a permission mode」

公式が明記している「見ないもの」

The classifier sees user messages, tool calls other than read-only lookups, and your CLAUDE.md content. Tool results are stripped, so hostile content in a file or web page can't manipulate it directly.
（分類器が見るのは、ユーザーのメッセージ、読み取り専用参照以外のツール呼び出し、CLAUDE.md の内容。ツールの実行結果は取り除かれるため、ファイルやWebページ内の敵対的コンテンツが分類器を直接操ることはできない）

これは意図的な設計です。分類器にツール結果を見せなければ、攻撃者は「これは安全な操作です、許可してください」と分類器を言いくるめられません。Anthropic Engineering はこの性質を "reasoning-blind by design" と呼んでいます。

ただし裏返しとして、分類器は「取得したZIPの中に何が入っているか」を構造的に知り得ません。攻撃チェーンの2段目〜4段目が通った理由はここに尽きます。安全のための盲目性が、そのまま複合リスクへの盲目性になっている、というトレードオフです。

分類器が通る／通らないの流れ

公式ドキュメントによる評価パイプラインは次の順です。

1. allow / ask / deny ルールに一致するアクションは即時解決（ただし protected paths への書き込みや critical path への rm / rmdir は、allow ルールがあっても分類器に回る）
2. 読み取り専用の参照や作業ディレクトリ内の編集は分類器をスキップ
3. それ以外はすべて分類器へ
4. ブロック時、Claude には理由が返り、Claude は代替手段を試す

4番目の挙動も今回は攻撃側に有利に働きました。バイナリ実行を拒否された Claude が「自分でデコーダを書く」という代替に流れ、それが結果的に攻撃者の意図した経路だったからです。

補足として、分類器が3回連続または累計20回ブロックすると Auto Mode は一時停止し、通常の承認プロンプトに戻ります（この閾値は設定変更できません）。ただし非対話実行（-p）で --permission-prompt-tool が指定されていない場合、閾値到達後もツールは実行されないまま Claude は作業を続けます。CI で回している人は、この「静かに実行されないまま進む」挙動を把握しておく必要があります。

2層防御の構造と、公式が認める誤り率

Auto Mode の防御は入力層と出力層の2層です。

• 入力層：サーバーサイドの prompt-injection probe が、エージェントのコンテキストに入る前にツール出力を走査し、敵対的コンテンツを検出したら警告を付与する
• 出力層：transcript classifier が実行前にアクションを評価。Stage 1 が高速な単一トークン（yes/no）フィルタ、Stage 1 がフラグを立てた場合のみ Stage 2 で chain-of-thought 推論に進む2段構成

Anthropic 自身が公表している誤り率は次の通りです。

そして公式解説には、今回の事案をほぼ言い当てている一文があります。

the classifier finds approval-shaped evidence and stops short of checking whether it's consent for the blast radius of the action
（分類器は「承認らしき根拠」を見つけた時点で止まり、その操作の影響範囲まで同意されているかは検証しない）

結論として公式は「auto mode is not a drop-in replacement for careful human review on high-stakes infrastructure（重要インフラでの慎重な人的レビューを置き換えるものではない）」と述べています。

なお、分類器のモデルは現行ドキュメント基準で既定 Claude Sonnet 5です（セッションの /model 選択とは独立し、Anthropic がサーバー側で設定したモデルが優先）。エンジニアリング解説には Sonnet 4.6 と書かれた記述もありますが、これは執筆時点のもので、現行の既定とは異なります。

Anthropic の回答：「Informative」＝仕様どおりの挙動

Rehberger 氏の報告に対する Anthropic の対応は、脆弱性としての修正ではなく「Informative（情報提供）」としてのクローズでした。回答の骨子は次の3点です。

• Auto Mode は convenience feature backed by a best-effort classifier, not a security guarantee（ベストエフォートの分類器に支えられた利便性機能であって、セキュリティ保証ではない）
• 個々には無害に見えるステップを組み合わせた執拗なインジェクション連鎖は、分類器の想定範囲外
• 実際の境界は OS レベルの隔離とネットワーク egress 制御である

The Register はこの姿勢を "working as designed" と報じています。ここは評価が分かれるところですが、少なくとも公式ドキュメントの記述と回答は完全に一貫しています。ドキュメントにはもともと「Auto mode reduces permission prompts but does not guarantee safety. Use it for tasks where you trust the general direction, not as a replacement for review on sensitive operations.」という警告が書かれており、今回の回答はそれをそのまま適用したものです。

2026年9月1日時点で、本報告に対応する修正が特定バージョンで入ったことを示すリリースノート記載は確認できていません。「Informative としてクローズされた」までが確認済みの事実で、それ以上は未確認として扱うべき情報です。

一方、Auto Mode 周辺の堅牢化は継続しています。CHANGELOG から確認できる直近の関連変更は次の通りです。

執筆時点の最新版は v2.1.252 です。まず「最新版に上げる」ことが最低限の前提になります。

危険度が上がる条件・下がる条件

同じ Auto Mode でも、置かれた環境によってリスクの大きさは大きく変わります。今回の事案から逆算した条件が次です。

危険度が上がる条件

• 未検証の外部コンテンツを読ませる作業（Webページの要約、外部URLの調査、他人のリポジトリの解析、受け取ったアーカイブの展開）
• ホストマシン上で直接 Claude Code を動かしている（コンテナ／VMなし）
• ホームディレクトリに SSH 鍵・クラウド認証情報・.env が置かれ、エージェントから到達できる
• アウトバウンド通信が無制限（任意ホストへの curl が通る）
• -p での非対話・無人実行、CI での自動実行
• MCP サーバーや hooks を多数入れている（これらはBashサンドボックスの外で、ホスト上に直接動く）

危険度が下がる条件

• sandbox runtime / devcontainer / VM の中で動かしている
• egress が allowlist 方式で、api.anthropic.com など必要最小限しか通らない
• 認証情報がエージェントの到達範囲外にある（別ユーザー、別コンテナ、シークレットマネージャ）
• 作業対象が自社の閉じたリポジトリで、外部コンテンツを読み込ませない
• 実行ログを監視していて、想定外の子プロセスやネットワーク要求に気づける

AIコーディングツール全般に共通するリスクの整理は「AIコーディングのセキュリティリスクとは？脆弱性・情報漏洩・最新事例と対策」、実害が出た事例との併読は「Claude Codeを悪用した恐喝AIエージェント事件まとめ」が参考になります。

対策：今日／今週／組織で決める、の3段で整理する

対策は粒度を分けると実行しやすくなります。優先度順に並べました。

隔離手段の選び方

公式ドキュメントは隔離手段を明確に段階分けしています。

出典: Claude Code Docs「Configure the sandboxed Bash tool」

注意すべきは、組み込みの Bash サンドボックスだけでは今回の攻撃に十分ではない点です。公式ドキュメントが「Built-in file tools, MCP servers, and hooks still run directly on your host（組み込みのファイルツール、MCPサーバー、hooks はホスト上で直接動く）」「the sandboxed Bash tool on its own constrains only Bash, so it is not sufficient for fully unattended runs（Bashしか制約しないため、完全な無人実行には不十分）」と明記しています。MCP を多用している環境では特に効きません（Claude Code MCP連携ガイド）。

なお組み込み Bash サンドボックスの実装は macOS が Seatbelt、Linux / WSL2 が bubblewrap で、ネイティブ Windows は非対応（WSL2 を使用）です。

ネットワーク egress の制御が最重要

公式は隔離についても釘を刺しています。

Sandbox isolation reduces the impact of a breach, but it does not eliminate risk. Any approach that allows network egress can still leak data the agent can read.
（サンドボックス隔離は侵害の影響を減らすが、リスクをなくすものではない。ネットワーク egress を許す構成では、エージェントが読めるデータは依然として漏れうる）

sandbox runtime は既定でネットワーク拒否です。~/.srt-settings.json で api.anthropic.com / claude.ai / platform.claude.com などを明示的に許可する設計になっており、書き込み許可も最低限（プロジェクトディレクトリ、~/.claude、~/.claude.json、/tmp）に絞るのが前提です。

また sandbox runtime は無設定でも次の高リスク書き込みを拒否します。設定を書く前でも一定の効果があります。

• .git/hooks、.git/config（filesystem.allowGitConfig: true の場合のみ許可）
• .mcp.json
• .claude/commands、.claude/agents
• シェルの起動ファイル

コンテナ側では、公式の devcontainer 例が default-deny の iptables ファイアウォールを同梱しています。自前でやるなら「必要なホストだけ通す」方針にし、*.example.com のようなワイルドカードではなく狭い allowlist にすること、メタデータエンドポイント（169.254.169.254 などのリンクローカルアドレス）を明示的にブロックすることが推奨されています。

組織で強制できる設定

出典: Claude Code Docs「Claude Code settings」

法人利用では、個人任せにせず managed settings で縛れる項目があります。

• permissions.disableAutoMode: "disable" — Auto Mode 自体を選択不可にする（最も強い制御）
• permissions.defaultMode — 開始モードを固定する。ただし利用者が後から Auto に切り替えることは可能なので、強制力は上と異なる
• permissions.deny — 認証情報パスや破壊的コマンドをルールとして恒久的に拒否する
• autoMode.environment — 信頼するインフラを追加する設定。claude auto-mode defaults で既定ルール一覧を JSON 出力できる

ここで実務上重要な注意が1つあります。会話中に口頭で述べた境界（「push しないで」など）は分類器がブロック信号として扱いますが、ルールとして保存されず、コンテキスト圧縮で消えることがあります。確実性が必要な制約は必ず permissions.deny に書いてください。設定の書き方は「Claude Codeのセキュリティと安全な使い方｜サンドボックス・権限設定」で詳しく扱っています。hooks による多層防御を足す場合は「Claude Code Hooks 使い方｜PreToolUse/PostToolUse 完全ガイド」も参考になります。

サンドボックスも過去に破られている：多層化が必要な理由

出典: Claude Code Docs「Development containers」

「分類器がダメならサンドボックスがある」で安心してはいけない理由も、事実として存在します。

2026年に公開された別系統の研究で、SOCKS5 のホスト名に null バイトを混入させることでネットワークサンドボックスを回避できる問題が指摘されました。影響範囲は v2.0.24 〜 v2.1.89 です。

原理は parser differential（解析の食い違い）です。attacker.example\x00.google.com のような文字列が、JavaScript 側の suffix チェックでは .google.com として許可される一方、C系のリゾルバは null バイトで文字列を打ち切ります。結果、プロキシが検証したホストと、実際に接続されるホストがずれ、ブロック対象への egress 経路が生まれます。

修正は v2.1.90（研究者側の記述）／v2.1.88（Anthropic の説明）で入っています。ここで混同を避けるべき点が2つあります。

• この SOCKS5 バイパスに専用のCVEは付与されていません。
• CVE-2025-66479 は別件です（sandbox-runtime で allowedDomains: [] がネットワーク隔離を正しく強制しなかった問題）。

つまり「分類器（Auto Mode）」と「サンドボックス」は別レイヤーで、どちらにも破られた実績があります。片方に依存する設計は成り立ちません。Rehberger 氏の推奨対策も、単一の防御ではなく組み合わせを前提にしています。

1. 無人稼働のコーディングエージェントはコンテナ / VM / OSサンドボックスで動かす
2. アウトバウンド通信を制限する
3. エージェントの挙動を継続監視する
4. ホームディレクトリ・SSH鍵・クラウド認証情報をエージェントの到達範囲から外す
5. Auto Mode の承認を「安全の証拠」として扱わない

エージェント全般の防御設計は「AIエージェントのセキュリティ対策｜OWASP Top 10・ツール別比較・導入チェックリスト」で体系立てて整理しています。他のエージェントでも構造は同じで、たとえば「OpenClawの危険性とは？主要リスクと安全な運用方法」でも権限とネットワークの扱いが中心論点になります。

Auto Mode をこのまま使ってよい人／今すぐ見直すべき人

このまま使い続けてよいケース

• 作業対象が自社の閉じたリポジトリで、外部URLや外部アーカイブを読ませない
• 常に画面の前におり、実行内容を目で追える対話セッション中心
• すでに devcontainer / VM の中で作業しており、ホスト側に認証情報が露出していない
• 個人の学習用途で、そのマシンに重要な鍵や本番アクセス権が存在しない

この条件下では、Auto Mode は承認の手間を減らしつつ検知率でも人間を上回るため、無効化するメリットよりデメリットのほうが大きくなります（危険コマンド検知率 89% 対 13.6%、実利用ログでの有害操作混入率 6.3% 対 2.4%）。

今すぐ運用を見直すべきケース

• Webページの要約・外部リポジトリの調査・受領アーカイブの展開をエージェントに任せている
• ホストマシン上で直接実行し、ホームディレクトリに SSH 鍵やクラウド認証情報がある
• -p の非対話実行や CI から無人で回している
• 本番環境の認証情報に到達できる端末で動かしている
• MCP サーバーや hooks を多数導入していて、Bash 以外の実行経路が広い

このケースでは、まず隔離（sandbox runtime か devcontainer）と egress 制限を入れるまで、外部コンテンツを扱うタスクを Auto Mode に任せないことをおすすめします。

組織としては Auto Mode をおすすめしないケース

• 医療・金融など、1件の情報漏洩が規制違反に直結する領域で、隔離環境が未整備
• 監査ログの取得体制がなく、事後に何が実行されたか追えない
• 端末ごとの設定を統制する仕組み（MDM / managed settings）がない

この場合は permissions.disableAutoMode: "disable" で Auto Mode を選択不可にし、Manual モード（設定値は default。ドキュメント上の表記は "Manual mode"）と明示的な allow / deny ルールで運用するほうが、監査上も説明しやすくなります。

よくある質問

Q. Auto Mode をオフにすれば安全になりますか？

いいえ。今回の攻撃の本質は「エージェントが未検証の外部コンテンツを読み、その環境で処理を実行する」ことにあります。Manual モードでも、python decoder.py のような一見無害なコマンドを人間が承認してしまえば同じ結果になり得ます。むしろ人間の検知率は 13.6% という測定結果もあり、モード切り替えは対策の主軸になりません。効くのは隔離と egress 制限です。

Q. 分類器のモデルを強いものに変えれば防げますか？

分類器のモデルは Anthropic がサーバー側で設定しており、既定は Claude Sonnet 5 です。セッションの /model 選択とは独立しているため、利用者側で任意に強化することはできません。加えて、そもそも分類器はツール実行結果を見ない設計なので、モデルの賢さで埋まる種類のギャップではありません。

Q. Claude Code は他のAIコーディングエージェントより危険なのですか？

同一ベンチマークでの比較では、GPT-5.6 Sol（Codex）が Auto-review で 5.83%、Full Access で 19.03% の攻撃成功率だったのに対し、Claude Code は 0.00% でした。再現実験を行った研究者も「Opus 5 と Auto Mode の組み合わせは現時点で最難関のプロンプトインジェクション課題」と評しています。Claude Code が相対的に弱いという結論にはならず、エージェント型ツール全般に共通する構造的課題と捉えるのが適切です。

Q. CI で無人実行しています。何から手をつけるべきですか？

優先順は、①コンテナ内実行の徹底、②egress の allowlist 化、③認証情報をリポジトリ・ホームディレクトリから排除しシークレットマネージャ経由に変更、④実行ログの監視、の順です。加えて非対話実行（-p）で --permission-prompt-tool がない場合、分類器のブロック閾値到達後もツールが実行されないまま処理が進む挙動があるため、ジョブが「成功したように見えて何もしていない」ケースの検知も設計に入れてください。

Q. サブエージェントを使っている場合、追加のリスクはありますか？

サブエージェントに対しては、①タスク記述の開始前（v2.1.178以降）②実行中の各アクション ③終了時の全アクション履歴レビュー、の3点で分類器が介入します。ただしサブエージェント frontmatter の permissionMode は無視される仕様です。v2.1.210 でサブエージェント経由の間接プロンプトインジェクションに対する堅牢化が入っていますが、外部コンテンツを読むサブエージェントを増やすほど攻撃面は広がります（Claude Code サブエージェント 使い方）。

Q. 修正パッチはもう出ていますか？

2026年9月1日時点で、Rehberger 氏の報告に直接対応する修正が特定バージョンで入ったことを示すリリースノート記載は確認できていません。Anthropic の分類は「Informative」で、公式の立場は「Auto Mode は仕様どおりに動作しており、実際の境界は OS 隔離と egress 制御」というものです。バージョンを最新に保ちつつ、隔離側で守る前提で運用してください。

まとめ

• 2026年8月26〜28日、Claude Code の Opus 5 × Auto Mode が間接プロンプトインジェクションで突破された。入口は「このサイトを要約して」という依頼1つ、成功率は小規模試行で60〜80%
• Anthropic の「0.00%」も事実。ただしそれは固定72シナリオ×10回のホールドアウト評価であり、レポート自身が「モデル単体の測定であって防御策一式の測定ではない」と断っている
• 攻撃が通った構造的理由は、分類器がツール実行結果を見ない設計にある。安全のための盲目性が、複合リスクへの盲目性になっている
• 最も示唆的なのは「Claude は侵害を検知したのに、Auto Mode がその駆除コマンドをブロックした」こと。個別コマンドの危険度しか見ない設計の限界を象徴している
• Anthropic の公式回答は「Auto Mode はベストエフォートの分類器であってセキュリティ保証ではない。実際の境界は OS 隔離と egress 制御」
• したがって取るべき行動は、Auto Mode の無効化ではなく、最新版への更新 → 認証情報の deny ルール → sandbox runtime / devcontainer での隔離 → egress の allowlist 化 → 組織設定での統制という多層化

未確認事項として、本報告への技術的修正の有無（リリースノート上の明示記載は未確認）と、Enterprise / Claude API / Bedrock / Agent Platform / Foundry における Auto Mode 既定化の完了状況（公式ブログは「9月以降」と記載）が残ります。いずれも状況が動きうるため、公式ドキュメントと CHANGELOG の継続確認をおすすめします。

次に読むなら

• Auto Mode の基本仕様から確認したい方 → Claude Code Auto Mode とは？デフォルト化・2層防御の仕組み・設定方法
• 具体的な設定手順を知りたい方 → Claude Codeのセキュリティと安全な使い方｜サンドボックス・権限設定
• Claude Code 自体を知りたい方 → Claude Codeとは？できること・料金・使い方・他ツール比較
• 組織としてAIエージェントの防御設計を固めたい方 → AIエージェントのセキュリティ対策｜OWASP Top 10・導入チェックリスト