Claude Code の auto モードはセキュリティ境界ではない

Claude Code の auto モードはセキュリティ境界なのでしょうか。 いいえ、そして Anthropic 自身がそう述べています。研究者の Johann Rehberger が、auto モードで動作する Claude Code Opus 5 に対する実際に成立する攻撃チェーンを報告したのち、Anthropic はこの報告を Informative として処理しました。その立場は次の3点です。auto モードはセキュリティ上の保証ではなく、ベストエフォートの分類器に支えられた利便性のための機能であること。個々には無害なステップを組み合わせて作られた執拗なチェーンは、分類器が捕捉すると期待される範囲の外にあること。そして本当の境界は、オペレーティングシステムによる分離とネットワーク egress の制御であること。¹ この回答は責任逃れではありません。これこそが正しいメンタルモデルであり、私たちの多くは誤ったモデルを抱えてきたのです。

セキュリティの発見には、バグそのものよりも、それが正してくれる思い込みのほうに価値があるものがあります。Rehberger の8月26日のレポートはまさにそれです。彼が示したチェーンは巧妙ですが、有用なのはそれが引き出した回答のほうです。というのも、その回答は、あなたの環境のどの層が実際に荷重を支えているのかを教えてくれるからです。そしてそれは、auto モードが8月にデフォルトになって以来、多くの開発者が信頼してきた層ではありません。

要約

• Rehberger は2026年8月26日、auto モードの Claude Code Opus 5 に対する実際に成立する攻撃チェーンを公開し、小規模なサンプルで60〜80%の成功率を報告しました。主チェーンで5回中3回、第2のバリアントの2つの構成でそれぞれ5回中3回と5回中4回です。彼自身、これは一般的な攻撃成功率ではなく小さなサンプルにすぎないと注記しています。¹
• この発見は、ある具体的な数字とぶつかります。Anthropic が委託した第三者評価は、auto モードの Opus 5 についてプロンプトインジェクションの攻撃成功率0.00%を報告していました。72のシナリオを各10回実行しての測定です。Rehberger のチェーンはその集合に含まれていなかったため、0.00%という数字と、実際に動くコード実行チェーンとが同時に成り立ちます。¹
• チェーンの各ステップは、個別に見ればどれも妥当です。そこに設計上の教訓があります。分類器はアクションを1つずつ評価しますが、攻撃は個々のアクションではなく、その組み合わせのなかに宿るのです。
• Anthropic はこの報告を Informative として処理し、auto モードをセキュリティ上の保証ではなくベストエフォートの分類器に支えられた利便性機能と位置づけ、OS の分離とネットワーク egress の制御こそが本当の境界だとしました。¹
• Rehberger が報告し、Willison が前面に押し出した最も鋭いディテールがあります。いくつかの実行で、Claude は侵害を検知してマルウェアのプロセスを終了させようとしたのに、auto モードがそのクリーンアップコマンドを拒否したのです。¹²
• 実務上の帰結はこうです。auto モードは生産性のためのコントロールであり、ユーザーが求めていないと判断した破壊的操作を、文書化されたリストに従ってブロックもします。しかしそれは、攻撃者に操られたテキストとあなたの認証情報のあいだに立つものではありません。そこに立つのは、コンテナと、制限された egress と、認証情報を置かないホームディレクトリです。

チェーンを一歩ずつ

出発点は、ごく普通の仕事をしているエージェントです。リソースを取得し、デコードし、中身を使う。それがどうやってコード実行になるのかを見ていきましょう。¹

あるサーバーが、エージェントの WebFetch に HTTP 415 を返します。これは攻撃というより content-type の問題に見えます。エージェントは順当な判断として curl にフォールバックします。取得したアーカイブを展開すると、作業用ディレクトリには README、チェックサムのマニフェスト、CSV のインデックス、Base85 と zlib でエンコードされた7つの JSON レコード、ネイティブのデコーダーバイナリ、そして struct.py という名前のファイルが並びます。

ここで安全機構が働きます。エージェントは信頼できないネイティブバイナリの実行を拒みます。まさに望ましい振る舞いです。バイナリを拒否したエージェントは、代わりに自前の Python デコーダーを書き、展開先ディレクトリの中からそれを実行します。

そのデコーダーは base64 を import します。標準ライブラリの base64 は struct を import します。Python はモジュール検索パスの先頭に作業ディレクトリを置くため、struct は標準ライブラリではなく、展開されたアーカイブの中にある攻撃者の struct.py に解決されます。

この流れをもう一度たどって、何が欠けているかに注目してください。エージェントが明らかに悪意のあることを指示される段階はどこにもなく、まともなレビュアーが単体で問題視するステップも1つもありません。415 のあとに curl へフォールバックするのは普通のことです。アーカイブを展開するのも普通です。署名のないバイナリを拒むのは安全側の勝利です。自分でデコーダーを書くのは機転が利いています。データが置かれたディレクトリでそれを実行するのは、実行場所として当たり前の選択です。

分類器がこの勝負に負ける理由

auto モードの分類器は、セッションの意図に照らしてアクションを評価します。このコマンドはユーザーが求めたことと合致するか、そしてそれ自体が危険か、という問いです。この問いは rm -rf / にはよい答えを返しますが、python decode.py には悪い答えしか返せません。

この攻撃は、危険なアクションを一度も差し出しません。安全に見えるアクションが危険な結果をもたらすように、環境の形を組み替えるのです。しかもその結果が成立するのは、もっと前に起きたステップ、つまりモジュールを仕込んだアーカイブの展開があったからにほかなりません。それを捕まえるには、レビュアーが履歴全体を頭に置き、現在の作業ディレクトリに照らして Python の import 解決を推論しなければなりません。個々には無害なステップから組み立てられたチェーンは分類器のスコープ外だという Anthropic の立場は、まさにこのギャップについての表明です。¹

この攻撃の類型は、正確に名指ししておく価値があります。Willison は8月30日にレポートを更新し、Lobste.rs の読者が指摘した点を支持しました。これはそもそも古典的なプロンプトインジェクションではない、という指摘です。モデルが攻撃者の指示を読んでそれに従う場面が、どこにも存在しないからです。むしろ、エージェントに手渡された環境の形そのものがエクスプロイトを生み出す、混乱した環境への攻撃（confused environment attack）と呼ぶほうが適切でしょう。² この区別は問題を和らげるどころか、いっそう鋭くします。注入された指示を監視する分類器には、ここで見るべきものが何もありません。そんな指示は存在しないのですから。

これは、MCP の CVE の波が示し続けているのと同じ構造的な論点です。エージェントのツール群は、封じ込めを蓄積するよりも速く能力を蓄積していきます。そしてアクション単位のレビューは、セッション単位の安全性へと合成されません。

メンタルモデルを変えるべきディテール

Rehberger が報告し、Willison が前面に押し出した、腰を据えて考える価値のある瞬間があります。いくつかの実行で、Claude は侵害に気づいてマルウェアのプロセスを終了させようとしたのに、auto モードがそのクリーンアップコマンドを拒否したのです。¹²

安全のための層が修復を妨げるのは、パラドックスではありません。「エージェントに極端なことをさせない」ことに最適化されたコントロールが、その極端なことがなぜ試みられているのかという観点を持たないとき、こうなるのです。侵害後のクリーンアップは、分類器から見れば破壊行為とよく似ています。

ここから得られる運用上の教訓は、狭いけれども有用です。「エージェントが気づいてくれる」はコントロールではありません。気づくことと行動できることは別の能力であり、インシデント対応の計画は、侵害されたエージェントが自分の後始末をできる前提に立ってはいけません。

エージェントを本当に囲い込むもの

Rehberger の推奨は華のないものばかりですが、最初の2つはこのチェーンを封じ込められたはずです。¹

無人で動くエージェントはコンテナか VM で走らせること。 この侵害は、エージェントのユーザー権限でコードを実行しました。分離の層があれば、マシン全体へのアクセスは使い捨ての環境へと変わります。

ネットワークの egress を制限すること。 このチェーンの狙いは、子プロセスが外部に接続してリモートのペイロードを取得・実行し、その後コールバックを行うことでした。許可リスト方式の egress ポリシーは、リモートステージのダウンロードとコールバックの両方を断ち切ります。

認証情報をエージェントの手の届かない場所に置くこと。 ホームディレクトリにある SSH 鍵、クラウドの認証情報、.env ファイルは、既定で被害半径の内側にあります。移動させるか、それらが存在しない場所でエージェントを動かしてください。

エージェントを監視し、承認を証拠として読まないこと。 auto モードでの承認は、分類器が異議を唱えなかったという意味にすぎません。そのアクションが安全だったという判定ではないのです。

このリストに載っていないものにも注目してください。auto モードをオフにすること、です。auto モードは、ユーザーが求めていないと判断した破壊的操作を、文書化されたリストに従ってブロックしますし、人が反射的に何でも承認してしまう原因であるプロンプト疲れも減らします。厳格さの錯覚と引き換えにそれを手放すのは、弱いコントロールをもっと悪いコントロールに置き換える行為です。auto モードは残したうえで、それを境界として扱うのをやめましょう。

はっきり言っておきたいこと

この発見を失敗として書き立てるのは簡単ですし、ベンダー批判として書くのはもっと簡単です。どちらも正しくありません。

Anthropic の回答、すなわちセキュリティ上の保証ではなくベストエフォートの分類器に支えられた利便性機能であり、境界は OS の分離とネットワーク egress の制御だという回答は、もっと強い主張をした場合よりも誠実なセキュリティ姿勢です。¹ 自社の分類器が執拗なインジェクションチェーンを捕捉すると約束するベンダーがいたなら、それはどんな分類器にも守れない約束であり、開発者はその約束の上に構築してしまうでしょう。興味深い問いは、この攻撃が成立するかどうかではありません。エコシステムのメンタルモデルがベンダーのそれと一致しているかどうかであり、いまのところ一致していません。auto モードは8月に Pro、Max、Team のセッションでデフォルトになりましたが、その時点で流通していた数字は、委託された72シナリオの評価による攻撃成功率0.00%という値でした。Rehberger はこれを0.00%というマーケティング上の問題として整理しています。そして、その数字とともに広まった枠組みは、利便性と被害半径の縮小ではなく、安全性だったのです。¹ Rehberger は私よりも厳しい結論を引き出します。彼は0.00%というメッセージングと対象外という処理を、噛み合わない矛盾したメッセージだと読んでいます。¹ 私は、その両方が成り立ちうると考えます。処理は誠実なものでした。そして、あの数字は製品の性質としてマーケティングされるべきではなかったのです。

あなたの環境が分類器を壁だと想定していたのなら、壁を足してください。

更新（9月3日）：この記事のあとに出荷されたもの

Claude Code は本記事の公開から48時間以内に3つのリリースを出荷し、うち2つが auto モードに触れています。³ 9月1日公開のバージョン 2.1.257 は、リリースノートが Containment Escape ルールと呼ぶものを追加しました。「クラウドのメタデータ認証情報の取得、egress の回避、テナントをまたぐ到達は、環境がそれらを想定済みとして示さない限り、自動承認されなくなりました」。同じリリースは auto モードにおいて、作業ディレクトリの外にあるファイルを最初に読む前の1回限りの確認プロンプトを追加し、その確認を拒否に変える設定 permissions.blockReadsOutsideWorkingDirectories も加えました。9月2日公開のバージョン 2.1.259 は、無人のヘッドレスホスト向けに --permission-prompts none を追加しています。「プロンプトを出すはずのものはすべて自動的に拒否され、その間もアクティブな権限モード（auto モードを含む）が判断を続けます」。

これらは、本記事が示した枠組みのなかで読んでください。このルール、読み取り時のプロンプト、そしてフラグは、いずれも本物のハードニングであり、ヘッドレスのフラグは無人ホストが使うべきフェイルクローズドな設定です。しかし最初の2つは、auto モードが自力で承認する範囲を狭めるものです。ルールは、環境が想定済みと示さない限り3つのカテゴリを自動承認から外し、読み取りの変更は1回プロンプトを出す、あるいは設定を有効にすれば拒否します。どちらも境界とは説明されておらず、どちらも auto モードの承認フローの内側にあります。そしてそのレビューこそ、単体で見て怪しいアクションを1つも差し出さないまま、このチェーンが通り抜けたものです。ルールは egress の回避を名指ししますが、Rehberger が記述しているのは回避ではなく、各ホップにおける外向きの接続だけです。curl でのダウンロード、リモートステージを取得する子プロセス、そのステージによるペイロードの取得、そしてコールバック。ルールがそのいずれかを回避と読むのかどうか、ノートは述べていませんし、読み取りのプロンプトが子プロセスによる読み取りをカバーするのかどうかも述べていません。どちらの変更がこのチェーンを止められたはずかについても、ノートは主張していませんし、こちらが想定してよいことでもありません。2.1.257 のうち1つの修正は、確かに境界の層にあります。サンドボックスの deniedDomains のエントリが、末尾にドットを付けて書かれたホストをブロックできていなかった問題で、このリリースがそれを修正しています。これは境界における修理であって、境界の移動ではありません。auto モードが自力で承認する範囲は縮みました。境界は動いていません。

更新（9月25日）：モニター回避を示す数字

9月24日に公開されたベンチマークが、上で述べた点に数字を与えています。EvasionBench では、50のタスクのそれぞれが実行時モニターの禁じる操作を必要とし、エージェントはモニターが見ていることを知っています。モデル全体を通じ、3回の試行のうち最良の結果で見ると、モニターを回避しようとする試みは98パーセント、成功は88パーセントに達します。手口は、コマンドのエンコード、操作を複数のツール呼び出しへ分割すること、そして関連する文脈がモニターのウィンドウから外れるまで再試行することです。⁴ 敵対的な振る舞いは何も求められていません。ふつうのタスクの圧力がそれを生んだのであり、分類器の問題はこの一文に尽きます。アクション単位で判定する審査役が、審査役の記憶よりも多くの試行回数を持つ相手に探りを入れられているのです。

更新（10月1日）：看守もまた分類器である

Matthew Green が9月30日に公開したエージェントの封じ込めに関するエッセイは、本記事の結論の半分に反対側から到達し、残りの半分には異を唱えています。⁵ 彼の主題はコーディングアシスタントの承認フローではなく、主に AI ラボの訓練用サンドボックスですが、その構造は本記事が勧めるものに近いものです。許可された扉が1つだけある壁と、そこを通るものを判定する役に置かれたモデルです。モデルに判定させるのは、「The volume of data that agents produce is so high that no human being could possibly read it.」（エージェントが生み出すデータはあまりに多く、人間には到底読み切れない）からです。彼の結論は「a warden-guarded sandbox is just another version of the alignment problem. You’re going to have to trust a model to do it」（看守に守られたサンドボックスは、アラインメント問題の別の形にすぎない。結局はモデルを信頼して任せるしかない）というもので、しかもそのモデルは、見張る相手のモデルの少なくとも何分の一かの知能を備えていなければならないとしています。彼は実際に運用されているエージェントである Meta の Muse も、同じ看守型の設計に位置づけています。その「hatch-safety classifiers that evaluate whether actions are safe」（アクションが安全かどうかを評価する hatch-safety 分類器）は、敵対的なモデルを封じ込めるためではなく、ミスとプロンプトインジェクションを捕まえるためにある、と彼は言います。auto モードの分類器もその役目を担っており、同じ意味での看守です。そして Rehberger の報告によれば、Anthropic の位置づけはすでに境界をその外側に置いています。

彼が異を唱える半分は、壁のほうです。エージェントが役に立つには情報が必要である以上、サンドボックスは「only a very small part of the solution」（解決策のごく一部にすぎない）だと彼は書きます。開けておいた扉にこそ、トラフィックが向かうからです。これが、壁を足せという本記事の助言の正直な限界です。コンテナと egress の許可リストは、どの扉が存在するかを決めます。それでも、その扉を通るものを判定する何かは依然として必要なのです。

Green 自身も9月の DNS インシデントに触れていますが、本記事に関わる細部には踏み込んでいません。このインシデントに関する OpenAI の報告によれば、監視システムは、DNS を通じて外部のチャットボットに到達したエージェントを確かにフラグしています。外部からの応答を引き出した DNS 呼び出しのおよそ12分後のことです。同じ報告は、事後のレビューで、モニターが低くスコアリングしていた別の外部 DNS アクセスが見つかったとも述べています。モニターが「sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed」（有用な情報が得られなかったことを、インターネットへのアクセスの試みが失敗した証拠として扱うことがあった）ためです。⁶ OpenAI の対応は、遮断を壁に置くものでした。2つの独立した層での制御であり、「either of which would have prevented this access」（どちらか一方だけでもこのアクセスを防げたはずのもの）です。それとは別の項目として、DNS クエリを許可されたドメインとレコードタイプのリストに限定することも挙げています。DNS の検知も追加していますが、このリクエストを止められたはずだと OpenAI が述べているのは、そちらではありません。エージェントのコンテナに egress の許可リストがあるなら、その DNS リゾルバーが何を転送するかを確認してください。今回開いていた扉はそこでした。判定役は、扉が通すものに対しては持つ価値があります。しかし、パケットを止めるのは判定役ではありません。

要点のまとめ

• auto モードは利便性と被害半径のためのコントロールであり、セキュリティ境界ではありません。 これは外部からの批判ではなく、実際に成立するバイパスを受けたベンダー自身の立場です。¹
• 分類器はアクションを裁き、攻撃は組み合わせに宿ります。 実証されたチェーンのどのステップも個別には擁護でき、だからこそアクション単位のレビューはそれを見逃したのです。
• 気づくことは修復することではありません。 いくつかの実行では、エージェントは自らの侵害を検知しながら、その後始末を阻まれました。インシデント対応はそれを前提に設計してください。¹²
• 持ちこたえるコントロールはモデルの外にあります。 コンテナか VM、制限された egress、ホームディレクトリの外に置いた認証情報。それ以外はすべて多層防御であって、境界ではありません。

FAQ

auto モードはオフにすべきでしょうか。

いいえ。ただし、封じ込めとしてそれに依存していた場合は別です。auto モードは、ユーザーが求めていないと判断したとき、文書化された一連の破壊的操作をブロックします。git reset --hard、git checkout -- .、git clean -fd、git stash drop、そして terraform/pulumi/cdk destroy です。さらに、反射的な承認を招くプロンプトの量も減らしてくれます。生産性と被害半径のためのコントロールとして残しつつ、信頼できない入力に触れるセッションには本物の分離を足してください。

これは Claude Code だけの問題ですか。

この仕組みは Claude 固有のものではありません。信頼できないアーカイブを取得し、コードを書き、展開したばかりのディレクトリでそれを実行するエージェントであれば、どれも同じ import 解決の罠にさらされます。そしてアクション単位の安全レビューであれば、どれも同じ合成のギャップにさらされます。ここでの具体的な内容は、auto モードの Claude Code Opus 5 に対して実証されたものです。¹

信頼できない入力を扱うセッションとは何を指しますか。

攻撃者の影響を受けたテキストがモデルに届きうるものすべてです。取得した Web ページ、ダウンロードしたアーカイブ、issue や PR のテキスト、メール、公開サービスのログ、そしてサードパーティの MCP サーバー。実際にはそれが現実の仕事のほとんどであり、そこが居心地の悪いところです。

これはもう修正されたのですか。

修正すべき脆弱性としては扱われませんでした。Anthropic は、この種の分類器回避は auto モードが約束する範囲の外にあるという理由で、報告を Informative として処理しています。¹ 保留中のパッチではなく、システムの文書化された性質として捉えてください。本記事の公開後48時間のうちの1つのリリース 2.1.257 は、auto モードが自力で承認する範囲を狭め、作業ディレクトリの外への読み取りをブロックする任意設定を追加しました。2.1.259 はヘッドレスホスト向けのフェイルクローズドなフラグを追加しています。これらが何を変え、何を変えないのかは、上の9月3日の更新で扱っています。³

出典