何が起きたか
Anthropicは、コーディングエージェント利用者をプロンプトインジェクション攻撃から守る手段として、Claude Codeの「Auto Mode」に大きく依存しています。同社は最近これをデフォルト設定に切り替え、その有効性について強気の主張を行っていました。
そこに、現在最も信頼できるプロンプトインジェクション研究者の一人と評されるJohann Rehberger氏が、Auto Modeを回避する攻撃を提示しました。氏によれば成功率は約80%です。
手口はシンプルです。Claude Codeを誘導してzipアーカイブをダウンロード・展開させ、その後にbase64をインポートするコードを実行させます。Claude Codeは、base64のインポートがアーカイブから展開されたローカルのstruct.pyを読み込んで実行してしまうことに気づきません。Pythonの標準ライブラリ名だと思って通した処理が、攻撃者が置いたファイルを呼び出す入口になっているわけです。
なぜ重要か：防御機構が失敗の一部になった
最も示唆的なのは、成功率80%という数字そのものではありません。いくつかの実行では、Claudeは侵害に気づき、マルウェアのプロセスを終了させようとしました。ところが、Auto Modeがそのクリーンアップコマンドを拒否したのです。
つまり分類器（クラシファイア）は、マルウェアのプロセス生成は許可し、それを止めるためのコマンドはブロックしました。安全機構そのものが、失敗の一部になったということです。
これは「防御が不十分だった」という話とは質が違います。攻撃実行は通り、復旧は止まる——非対称に悪い方向へ倒れています。承認フィルタ型の防御は、コマンドの見た目から危険度を判定します。zipの展開もモジュールのインポートも、単体では無害に見えます。一方「プロセスをkillする」は、文脈を持たない分類器にとっては十分に危なく見える。この認識のズレが、そのまま攻撃者に有利な非対称性として現れています。
結論は「サンドボックス」
記事の著者は、Rehberger氏の結論——敵対的攻撃のリスクがある環境でエージェントを安全に動かす唯一の方法はサンドボックスである——に同意しています。
Rehberger氏の推奨は具体的です。無人で動かすコーディングエージェントは、コンテナ・VM・OSサンドボックスの中で実行すること。ネットワークの外向き通信（egress）を制限すること。エージェントを監視すること。そして、ホームディレクトリ、SSH鍵、クラウド認証情報などをエージェントの実行環境に晒さないこと。
いずれも「モデル側の賢さ」に依存しない、実行環境の設計で担保する対策である点が共通しています。分類器の精度向上は歓迎すべきですが、それを唯一の防波堤に据える設計は今回の結果が否定しています。
💼 事業会社視点：これは自社にどう効くか
日本企業でいま危ういのは、SIer・受託開発の現場と、社内でコーディングエージェントを本格導入し始めたSaaS/EC事業者です。多くの現場では、エンジニアの手元Macやそのままの開発サーバーでClaude Codeを動かしています。そこには顧客本番環境へのSSH鍵、AWS/GCPの認証情報、決済APIキーが平然と置かれている。今回の攻撃が示したのは、外部リポジトリやドキュメントを読ませるだけで、その全部が射程に入り得るということです。受託開発なら、侵害は自社事故ではなく顧客への損害賠償・契約解除の話になります。
役員が今週やるべきことは、AI利用ポリシーの再検討ではありません。「誰のどのマシンで、何の権限を持ったままエージェントを走らせているか」の実地棚卸しです。そのうえで、無人実行はコンテナ/VMに隔離し、egressを許可リスト化し、認証情報はエージェントの実行環境から物理的に外す。ここは情報システム部門の予算で数週間で片づく範囲で、投資対効果は極めて明快です。
逆に「Auto Modeがデフォルトで守ってくれるから大丈夫」という説明でセキュリティ審査を通した組織は、その前提が外部研究者に80%破られた事実を踏まえ、根拠を差し替える必要があります。ベンダーの安全機能を統制の中心に据える設計は、機能の仕様変更ひとつで崩れます。