Claude Code Auto Modeの脆弱性：安全メカニズムが自身のクリーンアップをブロック

Auto Modeが問題の一部に

セキュリティ研究者のJohann Rehbergerは、AnthropicのClaude CodeのデフォルトであるAuto Modeに対する攻撃の成功を実証した。彼はプロンプトインジェクションを使用し、エージェントをだまして偽装されたローカルファイルを含むアーカイブをダウンロードして解凍させた。このファイルは標準ライブラリがインポートされたときに悪意のあるコードを実行する。Rehbergerによれば、この攻撃の成功率は80％に達するという。

重大な発見は、コードの実行そのものにあるのではない。Claude Codeが侵害を検出し、マルウェアプロセスを終了しようとしたとき、Auto Modeはクリーンアップコマンドをブロックした。分類器は悪意のあるプロセスの作成を許可したが、その後その削除を拒否したのだ。

開発者の信頼の方程式が変わる

このベクターは、自律型コーディングエージェントに別の承認およびセキュリティ層を追加しても、プロンプトインジェクションの根本的な原因は解決されず、ツールの動作が変わるだけであることを示している。Anthropicは堅牢な防御としてAuto Modeを頼りにしていたが、この欠陥は、エージェントがコードを実行できる場合、エージェント自身の防御メカニズムが、侵入成功後の被害の軽減を逆説的に妨げる可能性があることを示している。

エージェントツールを展開するチームにとって、これは1つのことを意味する。モデルが自身のセキュリティ障害を認識して修正することに依存することは、特にモデル自身の内部ルールがそれを妨げている場合、まだ実行可能ではないということだ。

サンドボックス化が唯一の現実的な解決策

この事例は、LLMシステム内のソフトウェアのガードレールの限界を浮き彫りにしている。モデルがアクセスし、外部の汚染された可能性のあるデータ（ダウンロードされたWebファイルなど）が供給されるのと同じ環境でコードが実行されると、環境は根本的に脆弱になる。

エージェントがホームディレクトリ、SSHキー、またはクラウドの資格情報にアクセスした場合、侵害は完全なものとなる。Auto Modeがどれほど優れていても、物理的およびネットワークの分離に代わることはできない。

エージェントツールのアーキテクチャへの圧力

このインシデントにより、エージェントの作成者は「防弾プロンプト」から体系的なサンドボックス化へと焦点を移さざるを得なくなるだろう。将来のコーディングアシスタントの主要な成熟度指標は、アシスタントがどれだけうまく自己監視できるかではなく、ネットワークの出口が制限され、開発者の機密変数にアクセスできないコンテナでデフォルトで実行されるかどうかになる。

Lilithの判定

エージェントが自分自身の警察になってはならない。LLMコードがホームディレクトリへのアクセス権限で実行されている限り、最高のAuto Modeでさえ、火災時に消火器をブロックする可能性のある単なるセキュリティ劇場にすぎない。