Claude Codeがパワフルなのは、それがリスキーであるのと同じ理由だ。コードの読み込み、ファイルの編集、シェルの実行、プロジェクトのメモリ、外部ツールへのアクセスを1つのランタイムに集約しているからだ。Anthropic自身のドキュメントでは、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと統合するエージェント型コーディングツールと説明されている。ひとたびツールがリポジトリ内でこれらすべてを実行できるようになれば、セキュリティの問題は、モデルがプロンプトを注入できるかどうかだけではなくなります。より深い問題は、リポジトリコンテンツ、共有設定、メモリ、ツール接続のすべてが同じ実行パスに参加したときに何が起こるかです。(クロード)
クロード・コードの調査が興味深いのはここからだ。公開されているベンダー・アドバイザリー、NVDの記録、チェック・ポイントのサードパーティ・リサーチのすべてが同じ方向を示している。それは、「モデルが何か間違ったことを言った」のではなく、「トラスト・バウンダリー・フェイル」だったのです。クロード・コードでは、信頼が完全に確立される前に実行が許可されたり、プロジェクトが管理するコンフィギュレーションがセキュリティ態勢に影響を与えたり、権限、シェルの検証、ネットワーク制御の間にギャップが露呈したりすることがありました。これらは、コンフィギュレーションと実行の境界におけるシステム設計の失敗である。(NVD)
これは1つの製品リリースサイクルを超えて重要である。クロード・コードは、リポジトリが単なるデータでなくなったときに何が起こるかを示す、最も明確な公開事例の一つである。エージェントのコーディング環境では、レポは命令、メモリ、フック、権限、ツールの統合を運ぶことができます。そのため、最新のセキュリティレビューでは、レポを単なるソースツリーではなく、能力サーフェスとしてモデル化する必要があります。Anthropicのドキュメンテーションは、この変化をわかりやすい言葉で表現しています：プロジェクトで共有される設定には、パーミッション、フック、MCPサーバーを含めることができます。 .mcp.json CLAUDE.mdとオートメモリーはセッション開始時にロードされ、サブエージェントはMCPツールを含むメイン会話からツールを継承できる。(クロード)
クロード・コードのセキュリティは信頼の境界から始まる
AIのコーディング・セキュリティに関する多くの議論は、いまだに古いモデルを前提としている。そのモデルでは、AIはテキストジェネレーターであり、シェルは別であり、ビルドステップが実行されない限り、レポのコンフィギュレーションはほとんど不活性であり、「プロンプト注入」はほとんどモデルを混乱させるためのものである。クロード・コードはそのモデルを壊す。AnthropicはClaude Codeを、複数のパーミッションモード、Bashのネイティブサンドボックス、プロジェクトレベルのメモリ、ライフサイクルイベントでアクションを自動化できるフック、外部サービスのMCP統合、フックやMCPサーバーをパッケージ化するプラグイン、コンテキストをまたいで作業を委譲できるサブエージェントなどを備えた、ツールを使う環境として説明している。これは、コード補完プラグインよりもはるかにリッチなランタイムだ。(クロード)
信頼境界は、ランタイムが信頼されていないリポジトリコンテンツをライブの操作入力として扱うことを防ぐ唯一のものです。Anthropicのセキュリティドキュメントによると、初回のコードベース実行と新しいMCPサーバーは信頼確認が必要で、ネットワーク要求を行うツールはデフォルトでユーザーの承認が必要です。また、Claude Codeはあなたが許可した権限しか持たず、承認前に提案されたコードとコマンドをレビューする責任があるとしている。これらは賢明なコントロールだが、順序が正しい場合にのみ機能する。もしコンフィギュレーションがトラストの前に解決されるなら、あるいはプロジェクトがトラストダイアログ自体を支配するパーミッションモードを黙って変更できるなら、モデルのアライメントはもはや主要な問題ではない。シーケンスは(クロード)
Anthropicの2026年3月の自動モードに関する記事は、もう一つの重要なポイントを明示している。Anthropicは、承認疲労を軽減するために、オートモードを構築した。これは、現実的な脅威モデルを見直すことになるので、有益な告白である。製品のデフォルトの操作パターンが慣れを促すのであれば、人間の承認はセキュリティ上のハードな境界線ではない。そのような世界では、攻撃者は常にゼロクリックのエクスプロイト・チェーンを完全に必要としているわけではない。時には、開発者が「承認」が何を意味するのかに気づかなくなるようなワークフローが必要なだけなのです。(アンソロピック)
Anthropic自身のドキュメントもまた、セキュリティメカニズム間の重要な線引きを行っている。サンドボックスはファイルシステムとネットワーク制御でBashサブプロセスを隔離しますが、ドキュメントには、組み込みのファイルツールはサンドボックスを通して実行するのではなく、パーミッションシステムを直接使用することも同様に明確に書かれています。つまり、「サンドボックスを使用する」ことは、クロードコードのリスクに対する完全な回答ではないということです。もしあなたの脅威モデルがコンフィギュレーション・ファイル、組み込みの編集・書き込みツール、あるいはコンピュータの使用を含むのであれば、1つ以上の境界を越えて考える必要がある。サンドボックスは価値あるものですが、スタックの中の1つのレイヤーに過ぎません。(クロード)
クロード・コード・フック、MCP、メモリー、サブエージェント、プラグインが攻撃対象を拡大する
Claude Codeのセキュリティサーフェスを理解する最も簡単な方法は、1つのアシスタントの観点から考えるのをやめて、階層化された拡張ポイントの観点から考え始めることです。Anthropicのドキュメントでは、フックをユーザー定義のシェルコマンド、HTTPエンドポイント、またはClaude Codeのライフサイクルの特定のポイントで自動的に実行されるLLMプロンプトと説明しています。フックは、クロードがファイルを編集したり、タスクを終了したり、入力を必要とするときに、自動的にシェルコマンドを実行させる。この決定論的な制御という一言が、セキュリティ上の重要な事実である。つまり、フックは単なるコンテキストではないということだ。自動化なのだ。(クロード)
MCPは異なるサーフェスだが、同じようなシフトを生み出す。Anthropicのクロード・コードのドキュメントによると、プロジェクト・スコープのサーバーは .mcp.json ファイルがプロジェクトルートにあること、そのファイルはバージョンコントロールにチェックインされるように設計されていること、チームメンバー全員が同じMCPツールやサービスにアクセスできるように特別に存在すること、などを説明している。また、ドキュメントでは、インストールするMCPサーバーを信頼し、信頼できないコンテンツを取得するMCPサーバーには特に注意するよう警告している。言い換えれば、チーム・コラボレーションの公式モデルは、すでにリポジトリ・コンテンツがツールの接続性を定義できることを前提としている。これはエンジニアにとって便利なことです。それはまた、リポジトリコンテンツがツールプレーンに直接パスを持つことを意味します。(クロード)
記憶は第三の平面を加える。Anthropic』には、クロード・コードにおける2つの補完的な記憶システムが記録されている。クロードはこれらを、強制的な設定ではなく、コンテキストとして扱う。CLAUDE.mdファイルは各セッションの開始時に読み込まれ、CLAUDE.mdは完全にロードされる。MEMORY.mdには起動時の制限があるが、それでも最初の200行または25KBは自動的にロードされる。MEMORY.mdには起動時の制限があるが、最初の200行または25KBは依然として自動的にロードされる。そのため、メモリポイズニングとコンテキストシェーピングは、カジュアルなプロンプト攻撃とは異なる。汚染されたプロンプトは一過性である。ポイズニングされたプロジェクト命令ファイルは、すべてのセッションの一部になる可能性がある。エージェントはそれをコードではなくアドバイスとして扱うかもしれないが、エージェントツールでは、アドバイスはアクションの選択に影響を与える。(クロードAPIドキュメント)
サブエージェントとプラグインも同じパターンです。Anthropicのサブエージェントのドキュメントによると、デフォルトでは、サブエージェントは、allowlistまたはdenylistで明示的に制限しない限り、MCPツールを含むメイン会話からすべてのツールを継承します。プラグインリファレンスによると、プラグインはスキル、エージェント、フック、MCPサーバー、LSPサーバーを1つのインストール可能なユニットにバンドルできるパッケージングレイヤーです。Anthropicはそこにセキュリティの制限も課しています：プラグインで配布されるエージェントにフックを含めることはできません、 mcpServersあるいは パーミッションモード.この制限は明らかだ。それは、人間工学がすでにそれらの表面を特別に敏感なものとして扱っていることを示すものだ。しかし、その制限があったとしても、アーキテクチャー上の教訓は残る。それはポリシーとケイパビリティのための流通経路なのだ。(クロードAPIドキュメント)
以下の表は、公式の機能セットを、レビュー時に最も重要なセキュリティ上の影響に分類したものである。(クロード)
| 表面 | 公式文書に書かれていること | なぜセキュリティが重要なのか |
|---|---|---|
| フック | フックはライフサイクルイベント時に自動的に実行され、決定論的な制御のために設計されている。 | プロジェクトの設定が自動実行になる |
| プロジェクト・スコープのMCP | .mcp.json は、バージョン管理とチーム共有のために設計されたプロジェクトルート設定です。 | 共有ツールの接続性がレポの信頼性の一部となる |
| CLAUDE.mdとオートメモリー | メモリファイルはセッション開始時にロードされ、コンテキストに影響を与える | プロジェクトの文脈は決定を持続的に形作る |
| パーミッション設定 | 権限をバージョン管理でチェックし、チーム間で共有できる | コラボレーション・コンフィグが安全姿勢を変える |
| サブエージェント | サブエージェントは、デフォルトでMCPツールを含むツールを継承します。 | 権限委譲は、意図した以上の能力を広げる可能性がある |
| プラグイン | プラグインは、スキル、エージェント、フック、MCP サーバー、LSP サーバーをパッケージ化します。 | パッケージングが政策とリスクの流通レイヤーとなる |
実務で変わるのは、リポジトリがもはやソース・アーティファクトだけではないということだ。それはまた、実行時の影響面でもある。セキュリティチームは、ソースコードはコンパイルされ、実行され、デプロイされたときに危険であることを開発者に何年もかけて教えてきた。クロード・コードは、古典的な意味では明らかに実行可能ではないが、それでもエージェントが実行するもの、接続するもの、信頼するものを変更する、ソースに隣接するコンフィギュレーションという別のカテゴリーを追加する。これこそ攻撃者が求めるブリッジなのだ。
クロード・コードのパーミッションと信頼は、ほとんどのチームが認識しているのとは異なるトレードオフをもたらす
クロード・コードの公式許可モデルは、単純なイエスかノーの承認プロンプトよりもリッチである。Anthropicは複数の許可モードを文書化している： デフォルト, 編集を受け付ける, プラン, オート, バイパス許可そして ドントアスク. プラン モードでは、クロードはファイルを読み、シェルコマンドを実行して探索し、ソースを編集せずにプランを書くことができる。 ドントアスク 明示的に許可されていないものはすべて自動拒否する。 バイパス許可 のようなクリティカルなローカルステートに対するプロンプトがわずかに残るのみで、パーミッションプロンプトとセーフティチェックが無効になる。 .git, .vscode, アイデアの一部である。 クロード.人間学は明確に次のように警告している。 バイパス許可 は、プロンプト・インジェクションや意図しないアクションからの保護はなく、隔離された環境でのみ使用されるべきであるとしている。(クロード)
なぜなら、公開されている勧告によれば、攻撃者は新しいセキュリティ・モデルを考案する必要がないからだ。必要なのは、製品がすでに持っているセキュリティモデルの中にある矛盾を見つけることだけなのだ。信頼が確立される前に、プロジェクトのコンフィギュレーションがパーミッションモードに影響を与える可能性がある場合、あるいは、パーミッションシステムがブロックしていると信じていた書き込みシンクにツールパスが到達する可能性がある場合、ユーザーインターフェイスはまだパーミッションベースに見えるが、実際の境界はすでに越えていることになる。クロード・コードの勧告の多くが、大規模な概念的失敗についてではないのはそのためだ。順序、解析、優先順位に関するものなのだ。これらの詳細が、そのモデルがポリシーの内側で操作されているのか、それとも周囲で操作されているのかを決定するのだ。(ギットハブ)
設定の優先順位に関する文書は、その点をさらに明確にしている。Anthropicは .claude/settings.json また、階層が解決されたときに、共有プロジェクトの設定がいくつかのユーザーレベルの選択よりも優先されます。設定ページでは、チーム共有パーミッション、フック、MCPサーバーがプロジェクト・スコープのユースケースとして明示的にリストされています。これは共同作業には便利ですが、セキュリティの観点からは、リポジトリ・コンテンツがポリシーの手段となり得ることを意味します。いったんレポをスコープとしたポリシーを認めると、安全な設計は、安全なコラボレーションのデフォルトと実行に関連するパワーを確実に分離できるかどうかにかかってきます。公開されている勧告によると、この分離は必ずしも必要なほど強力ではなかったようだ。(クロード)
実用的な収穫はシンプルで違和感のないものだ。クロード・コード（Claude Code）では、許可システムはセキュリティ・モデルのすべてではない。本当のセキュリティモデルとは、設定範囲、信頼検証、モード解決、シェル検証、ネットワーク承認、サンドボックス境界、拡張サーフェスの組み合わせです。これらのどれかを単独でレビューするチームは、重要な道筋を見落とすでしょう。
3月31日のソースマップストーリーが可視化問題を変えた
2026年3月31日、GitHubの公開ミラーやサードパーティの報告によると、npm-distributed Claude Codeパッケージが、以下のような問題を引き起こしているとのことです。 cli.js.マップ ファイルと、TypeScriptコードベースの大部分を再構築するのに十分な埋め込みソース情報が含まれている。ミラーリポジトリは、Anthropicのリポジトリではなく、非公式な抜粋であることを明示している。サードパーティの報告によると、Anthropicは最初の発表の時点ではまだ公的な声明を出していなかった。これらの事実を総合すると、リーク記事を公式な真実の情報源として扱うことは正当化されない。しかし、ホワイトボックス・レビューのコストにおける実際の変化として扱うことは正当化される。(ギットハブ)
この区別は重要だ。クロード・コードに関するセキュリティー上の結論は、依然として公式文書、GitHubの勧告、NVDの記録、評判の良い研究などに基づくべきである。しかし、ソース・マップの報告は、研究者の作業環境を変える。シェルの実行、パーミッション、エージェントのループ、ツールのディスパッチ、リポジトリ制御の設定を組み合わせたランタイムは、公開ミラーが読み取り可能なコードパスを公開すると主張すれば、検査がはるかに容易になる。これらのミラーに直接依存することがないとしても、ミラーの存在は、独立した解析、パッチの差分、アーキテクチャのレビューの障壁を低くする。クロード・コードのようなツールにとって、これは小さな出来事ではない。精査の経済性を変えるのだ。(ギットハブ)
ここには、より広範な工学的教訓もある。ソースマップ事件に関するLunaの記事では、ハッキングというよりもビルドパイプラインの失敗という枠組みで、公開パッケージのソースマップはプロプライエタリなソースを公開する可能性があると指摘している。この解釈は、パッケージ配布の基本的な仕組みと一致している。セキュリティに焦点を当てた聴衆にとって重要なのは、流出したコードに関する噂話ではない。それは、エージェント型開発者ツールのリリース成果物は、ツールそのものと同じように精査されるべきだということだ。なぜなら、成果物のミスによって、クローズドな実装の詳細が、一夜にしてオープンな分析表面に変わってしまう可能性があるからだ。(ルナテック)
クロード・コードの脆弱性が公開されたバイパス経路をマッピングした
クロード・コードの公開された脆弱性の履歴は、問題が同じテーマに集中しているため、異例なほど示唆に富んでいる。それらはランダムなバグではない。信頼、コンフィギュレーション、解析、ツールの実行、ネットワーク制御の間の境界線に苦慮する製品の姿を繰り返し示しているのだ。
最も古い高シグナルの例はCVE-2025-59536である。NVDによると、1.0.111より前のバージョンは、起動時の信頼ダイアログの実装にバグがあるため、コードインジェクションの脆弱性があるとのことです。Claude Codeは、ユーザがスタートアップ信頼ダイアログを受け入れる前に、プロジェクトに含まれるコードを実行するようにだまされる可能性があり、悪用するには、ユーザが信頼されていないディレクトリでClaude Codeを起動する必要があります。表面的には、これはスタートアップのバグのように聞こえます。アーキテクチャー的に言えば、「open repo」と「start agent」が制御フローの中で近すぎたということです。ユーザーはまだ信頼の表明に成功していなかったが、システムはすでに行動に移っていたのだ。(NVD)
CVE-2026-21852は、同じ教訓をネットワークプレーンに押し込んだ。AnthropicのGitHubアドバイザリとNVDによると、バージョン2.0.65以前では、悪意のあるリポジトリが anthropic_base_url を設定ファイルに追加し、信頼プロンプトを表示する前にClaude CodeにAPIリクエストを発行させることで、攻撃者が管理するエンドポイントにAPIキーが漏れる可能性がある。これはプロンプト・インジェクションの話ではない。シーケンシングの話である。問題は、モデルがユーザーを理解したかどうかではない。問題は、信頼が確立される前に、ランタイムがレポコントロールされた環境設定を有効にすることを許可したかどうかである。(ギットハブ)
2026年3月のGitHubアドバイザリGHSA-mgp-wc2j-qcv7は、パーミッションの問題をさらに具体的にした。Anthropicは、Claude Codeがrepo-controlledを含む設定ファイルからパーミッションモードを解決したことを明らかにした。 .claude/settings.jsonワークスペースの信頼確認ダイアログを表示するかどうかを決定する前に。悪意のあるレポは パーミッション.defaultMode への バイパス許可これは、最初に開いたときの信頼ダイアログを無言でスキップし、明示的な同意なしにユーザーをパーミッシブ・モードにするものである。これは、コンフィギュレーションがコンフィギュレーションを管理するために意図された境界そのものを損なっている、異常にきれいな例です。このような設計で安全に行うべきことは、振り返ってみれば明らかです。レポで制御された設定が実行姿勢に影響を与える前に、信頼が決定されなければなりません。勧告が存在するのは、その順序が十分に強く強制されていなかったからだ。(ギットハブ)
チェック・ポイントが2026年2月に発表した調査では、こうしたいくつかのアイデアがまとめられている。彼らの報告書によると、悪意のあるプロジェクトのコンフィギュレーションは、Hooks、MCPサーバー、および環境変数を使用して、ユーザーが信頼できないリポジトリをクローンしたり開いたりした場合に、リモートでコードを実行したりAPIトークンを流出させたりする可能性があるという。この記事中のすべてのラベルに同意するかどうかは別として、構造的なポイントは重要である。それは、プロジェクト・ファイルが実行と認証の表面になっているという主張だった。これこそが、セキュリティ・チームが内面化する必要のある境界の変化なのだ。(チェック・ポイント・リサーチ)
コマンド検証に関する勧告は、別の角度から同じ結論を補強している。Anthropicは、コマンド検証のバイパスによる任意のコードの実行、および 見つけるZSH clobber解析による任意のファイル書き込み、パイプによる書き込み保護バイパス セッド と エコーまた、ディレクトリ変更に基づく保護された書き込みの迂回についても同様である。仕組みは違っても、教訓は同じです。製品がユーザーの代わりにシェルの意図を解析し、分類する必要があると、シェルの文法の隅々までがセキュリティに関係するようになります。UI上で強力に見える許可モデルは、その下のパーサと同じくらい強力であるに過ぎません。(ギットハブ)
サンドボックス層とネットワーク層についても同様だ。Anthropicは、永続的なコンフィギュレーション・インジェクションによるサンドボックスのエスケープを 設定.json起動時にファイルが見つからない場合、サンドボックスがそのパスを正しく保護しないため、サンドボックス内の悪意のあるコードが永続的な設定を作成し、クロード・コードが再起動したときにホスト権限で実行される。また、信頼された WebFetch の処理におけるドメイン検証のバイパスも公開されました。 startsWith() のロジックは、信頼されたドメイン文字列が先頭に付いていれば、攻撃者が管理するドメインをバリデーションを通過させることができる。どちらの問題も魅力的なものではない。どちらも、"より安全なエージェント・ランタイム "が実際に安全かどうかを決定する、まさにその種の詳細である。(ギットハブ)
以下の表は、公開されたissueの履歴を変更履歴ではなく、調査マップにしたものである。(NVD)
| 識別子 | 何が失敗したのか | なぜそれが重要なのか | 固定状態 |
|---|---|---|---|
| CVE-2025-59536 | スタートアップの信頼ダイアログのバグにより、信頼が承認される前にプロジェクトのコードが実行されてしまう。 | 実行前、信頼はハードゲートではなかった | 1.0.111 で修正 |
| CVE-2026-21852 | レポ・コントロール anthropic_base_url トラスト・プロンプトの前にリクエストをリダイレクトできる | レポのコンフィギュレーションが信頼以前のネットワーク挙動に影響 | 2.0.65で修正 |
| GHSA-mmgp-wc2j-qcv7 | レポ・コントロールの設定 バイパス許可 ワークスペース信頼ダイアログの前 | 同意の前に許可態勢が弱まる可能性 | 2.1.53で修正 |
| GHSA-ff64-7w26-62rf | 行方不明 設定.json サンドボックス化されたコードに永続的なホストレベル設定を作成させるパス | サンドボックス化された実行は、将来の特権的振る舞いを植え付ける可能性がある | 2.1.2で修正 |
| GHSA-vhw5-3g5m-8ggf | 脆弱なドメイン検証により、攻撃者のドメインが信頼された接頭辞のチェックを通過してしまう。 | 自動ネットワークリクエストは攻撃者のインフラに到達する可能性がある | 1.0.111 で修正 |
| GHSA-xq4m-mc3c-vvg3 および関連するパーサーに関する勧告 | シェルとパスの解析の欠陥が、検証と書き込みの制限をバイパスする | パーミッションUIはコマンドの解析と同じ強さしかない | 複数のリリースにわたって修正 |
この履歴が防御側にとって非常に有用なのは、単なるパッチのキューではなく、分類法が公開されているからだ。クロード・コードの問題は、信頼順序、コンフィギュレーションの優先順位、パーサーの曖昧さ、パスの検証、永続的な状態、ネットワークの出口といった同じリスクの系列に回帰し続ける。このパターンが分かれば、「クロード・コードのバイパス」はセンセーショナルなフレーズのように聞こえなくなり、実用的なレビュー・カテゴリのように読めるようになる。
クロード・コードのセキュリティ・バイパス分類法
今日、クロード・コードを研究する最も有用な方法は、アドバイザリーIDを暗記することではない。失敗をいくつかの再利用可能なメカニズムクラスに整理することである。これらのクラスは、クロード・コードを超えて重要であるほど幅広く、レビュー作業を知らせるのに十分具体的である。
トラスト・バイパス
トラスト・バイパスは、製品が意思決定の境界が存在すると主張するものの、その意思決定が最終決定となる前にシステムの一部が動作してしまうクラスである。CVE-2025-59536とCVE-2026-21852が最も明確な例です。一方は起動時の信頼ダイアログが受け入れられる前にプロジェクトコードの実行を許可し、 もう一方は信頼プロンプトが表示される前に環境依存のリクエストリダイレクトを許可します。GHSA-mgp-wc2j-qcv7もここに属します。なぜなら、レポジトリが制御する設定が、信頼確認そのものを制御するパーミッションモードに影響を与えたからです。クロードコードのようなシステムでは、信頼は、後の副作用を変更する可能性のある設定解決を含む、すべての副作用をゲートしなければなりません。(NVD)
設定から実行まで
これは最も重要なクラスであり、セキュリティ・チームがまだ過小評価しているクラスである。フックは、決定論的ライフサイクル自動化として文書化される。プロジェクトスコープのMCPは、次のような共有ツール構成として文書化される。 .mcp.json.プロジェクト共有設定は、ソース管理のために明確に設計されています。つまり、リポジトリは環境設定を記述する以上のことを行うことができます。コマンドをスケジュールしたり、ツールを接続したり、エージェントの動作を変更したりすることができます。チェック・ポイントのクロード・コードの研究は、このような広範なクラスの一例として読むのが最適です。(クロード)
パーミッション・ドリフト
許可ドリフトは、実効的な安全態勢がユーザーが考えているよりも緩い場合に起こる。それは、明示的なモード変更、継承されたポリシー、混乱した優先順位、あるいは承認疲れによって起こる可能性がある。Anthropic自身のドキュメントはトレードオフを明確にしている： バイパス許可 はノーチェックで走る、 ドントアスク 事前に承認されたツールのみ使用可能、 プラン 編集なしで研究し オート は、手動承認の代わりにバックグラウンド安全チェックを使用している。2026年3月のトラスト・ダイアログ・バイパスの勧告が重要なのは、UIが何が起こったかを伝える前に、レポが管理する設定ファイルがいかにユーザーをより寛容な姿勢に無言で強制できるかを示したからである。これは最も純粋な形でのパーミッションドリフトである。(クロード)
コンテキスト・ポイズニングとメモリー・ポイズニング
クロード・コードのメモリモデルは、カジュアルな議論では得られないほど注目されるべきだ。Anthropicによれば、メモリーファイルはすべての会話の開始時にロードされ、CLAUDE.mdはセッションの開始時にロードされ、クロードはこれらのファイルを強制的な設定ではなくコンテキストとして扱うという。この違いは微妙だが重要だ。コンテキストファイルはコードの中でブール値を反転させるのではない。より確率的なことをするのだ。ゴール、リスク、制約に関するモデルの解釈を形作るのだ。通常のチャットでは、それは出力を歪めるだけかもしれない。エージェント符号化ランタイムでは、歪んだ判断が、どのツールが呼び出され、どのファイルが開かれ、どのシェルアクションが合理的に見えるかを変える。このクラスのメモリ汚染は、1つの悪意のある文章についてではありません。持続的な行動への影響なのだ。(クロードAPIドキュメント)
委任の乱用
サブエージェントとパッケージ化された能力が重要になるのは、委任です。Anthropicによると、サブエージェントはデフォルトで、MCPツールを含むメインカンバセーションからすべてのツールを継承する。チームが明示的にツールへのアクセスを制限しない限り、デリゲーション・グラフはオペレータの意図よりも広くなる可能性がある。問題は、サブエージェントが本質的に安全ではないということではない。デリゲーションが権限の広がりを隠してしまうことです。ユーザーはメインの会話を信頼の単位と考えるかもしれないが、実効的な権限には、その権限の下で生み出されるどんなヘルパーエージェントも含まれることになる。セキュリティの観点からは、"メイン・エージェントは何ができるか？"だけでなく、"その子エージェントに何をさせることができるか？"が問題となる。(クロードAPIドキュメント)
検証バウンダリーの崩壊
このクラスはシェル解析と書き込み制限の勧告を収集します。Anthropicのドキュメントでは、入力サニタイズ、コマンドブロックリスト、fail-closedマッチング、疑わしいコマンドのチェック、カレント作業ディレクトリへの書き込み制限などの保護を強調している。勧告の履歴は、シェル文法、パス処理、環境セマンティクスが誤って解釈された場合、そのレイヤーがいかに脆弱になり得るかを示している。 見つけるパイプ セッド, $IFSショートフラッグ、 cdやZSH clobber syntaxはランダムなトリビアではない。これらは、安全なシェル実行を約束するAI製品が、現実のシェル下でコマンドを理解するレイヤーを実装しなければならないことを思い出させる。その層はセキュリティ上重要なコードであり、それは難しい。クロード)
この分類法の価値は、学問的に整然としていることではない。この分類法は、守備側に適切な質問をする方法を与えてくれる。クロード・コードにはバグがあるのか？"ではなく、"これらのメカニズム・クラスのどれが我々の環境ですでに公開されているのか？
クロード・コードの検出と検証、実際のリポジトリで何をチェックすべきか
エージェントツールのセキュリティで時間を無駄にする最も手っ取り早い方法は、一度限りのエクスプロイトの伝承を追いかけ、実際の勧告に現れ続ける退屈な表面を無視することである。Claude Codeの場合、収穫の多いレビューは、エキゾチックなリバースエンジニアリングではなく、リポジトリのコンテンツとローカルポリシーから始まる。最初の質問は、リポジトリ内のどのファイルが実行前または実行中にクロード・コードに影響を与えることができるかということです。最低限、以下のものが含まれます。 .claude/settings.json, .claude/settings.local.json, .mcp.json, CLAUDE.md, MEMORY.mdそして、プロジェクトが使用するプラグインやエージェントの定義です。Anthropicのドキュメントでは、プロジェクト共有の設定、プロジェクトスコープのMCP、メモリファイルはすべてファーストクラスのコンフィギュレーションサーフェスであることが確認されています。(クロード)
実用的なファーストパスは、コンフィギュレーションを含むファイルや不審なキーにフラグを立てるリポジトリスキャンである。ポイントは妥協の証明ではない。重要なのは、リポジトリのコンテンツが実行時の動作を変える場所を特定することです。
find .-maxdepth 4 -type f \( -path "*/ claude/settings.json")
-o -path "*/.claude/settings.local.json" ୧-͈ᴗ-͈)◞ʱʱ
-o -path "*/.claude/settings.local.json" ୧-͈ᴗ-͈⁎ ".mcp.json
-o -name ".mcp.json" \
-o -name "CLAUDE.md" ୧-͈ᴗ-͈⁎
-o -name "MEMORY.md" ⅳ)\
| sed 's|^./|'
rg -n --hidden --no-ignore-vcs \
permissions.defaultMode|bypassPermissions|dangerously-skip-permissions|dontAsk|hooks|ANTHROPIC_BASE_URL|mcpServers|curls+-fsSL|wgets+http|powershell|osascript|bashs+-c|npxs+@playwright/mcp' .
この種のスキャンは単一のCVEに特化したものではない。実行フック、危険なパーミッションデフォルト、ネットワークリダイレクト、レポで定義されたツールの接続性など、公開されている歴史が表面化し続けているリスクのクラスをキャッチします。Anthropicのドキュメントには、承認前に推奨されるコマンドを確認すること、信頼できないコンテンツを直接Claudeにパイピングすることを避けること、外部のウェブサービスとやり取りする際にVMを使用することなど、信頼できないコンテンツに対する適切な衛生管理も明示的に推奨されています。これらの推奨は、コンフィグ・ファースト・レビューの考え方と一致している。(クロード)
より深いトリアージには、grepに完全に依存するのではなく、JSONを解析することが役立つ。以下のPythonの例は、意図的に保守的である。何も実行しようとしませんし、クロードコードをエミュレートすることもありません。単に、人間によるレビューに値する条件にフラグを立てるだけである。
インポート json
from pathlib import Path
suspicious_command_tokens = [
"curl -fsSL"、
"wget http"、
"bash -c"、
「powershell"、
"osascript"、
"nc "、
"socat "、
]
def load_json(path: Path)：
try：
return json.loads(path.read_text())
except Exception as exc：
return {"_parse_error": str(exc)}.
def audit_claude_settings(path: Path)：
data = load_json(path)
所見 = [].
if "_parse_error" in data：
findings.append(f"{path}: 解析エラー: {data['_parse_error']}")
return findings
mode = (
data.get("permissions", {})
.get("defaultMode")
)
if mode in {"bypassPermissions"}：
findings.append(f"{path}: 危険なデフォルトモード: {mode}")
hooks = data.get("フック", {})
if hooks：
findings.append(f"{path}: hooks present：{'、'.join(hooks.keys())}")
serialized = json.dumps(フック)
for token in SUSPICIOUS_COMMAND_TOKENS：
if token in serialized：
findings.append(f"{path}: 疑わしいフック・トークンが見つかりました：{token}")
text = json.dumps(データ)
if "ANTHROPIC_BASE_URL" in text：
findings.append(f"{path}: ANTHROPIC_BASE_URLオーバーライドを含む")
return findings
def audit_mcp(path: Path)：
data = load_json(path)
所見 = [].
if "_parse_error" in data：
findings.append(f"{path}: 解析エラー: {data['_parse_error']}")
return findings
servers = data.get("mcpServers", {})
for name, cfg in servers.items()：
if isinstance(cfg, dict)：
command = cfg.get("command", "")
env = cfg.get("env", {})
if command：
findings.append(f"{path}: MCPサーバ '{name}' runs command: {command}")
if env：
findings.append(f"{path}：MCPサーバ'{name}'はenvキーを定義しています：{リスト(env.keys())}")
return findings
targets = [] (ターゲット)
for p in Path(".").rglob("*")：
if p.is_file() and str(p).endswith(".claude/settings.json")：
targets.extend(audit_claude_settings(p))
if p.is_file() and p.name == ".mcp.json"：
targets.extend(audit_mcp(p))
for finding in targets：
print(finding)
この種の監査が重要なのは、文書化された機能モデルがすでにリスクの蓄積場所を教えてくれているからだ。フックは決定論的な実行ポイントである。プロジェクトスコープのMCPは、ソース管理されたツール設定である。権限設定はバージョン管理でチェックできる。メモリはセッション開始時にロードされる。これらの事実から有益なことを学ぶのにエクスプロイト・キットは必要ない。必要なのは、ファイルの可視化とレビュー・ポリシーである。(クロード)
ランタイム・テレメトリーも重要だ。CVE-2026-21852は、なぜ初期のネットワークイベントが注目に値するかの明確な例です。開発者が新しいリポジトリでClaude Codeを起動し、予期しないアウトバウンドリクエスト、特にAnthropicでないホストへのリクエストや、信頼が有意義に確立される前のリクエストが見られた場合、それは深刻な調査経路として扱われるべきです。Anthropicのドキュメントによると、ネットワークリクエストを行うツールはデフォルトで承認が必要ですが、彼ら自身のアドバイザリによると、コンフィギュレーションシーケンスはいくつかの条件下でその期待を損なう可能性があります。正しい運用上の対応は、プロンプトを盲目的に信頼することではない。ログを取り、関連づけ、レビューすることである。(クロード)
最もクリーンなオペレーションコントロールの1つは、モード選択を非公式な習慣ではなく、ワークフローの明確な一部にすることです。Anthropicの文書化されたモードは、すでにこれをサポートしています。
# リポジトリを探索し、編集せずに変更を計画する
claude --パーミッションモード plan
# ロックダウンされた環境で事前に承認されたツールだけを実行する
claude --パーミッションモード dontAsk
通常の開発者用ワークステーションでは使用しない
# 隔離されたコンテナまたは使い捨て VM でのみ使用する
claude --パーミッションモード bypassPermissions
重要なのは、1つのモードですべてが解決するということではない。重要なのは、チームはリポジトリと環境の信頼レベルに基づいてモードを選択すべきだということだ。 プラン は、未知のコードとの最初の接触に適したデフォルトである。 ドントアスク は、何が許可されているかを正確に定義できる場合に便利である。 バイパス許可 が存在するが、Anthropic自身のドキュメントによると、安全チェックを無効にし、プロンプトインジェクションや意図しないアクションからの保護を提供しないという。意図的に使い捨てにする環境でない限り、起こるのを待っている事件のように扱ってください。(クロード)
チームのためのクロード・コード・ハードニング
ほとんどのチームは、クロードコードのリスクを低減するために英雄的なセキュリティプログラムを必要としない。必要なのは、協調的なコンフィギュレーションと実行に関連するコンフィギュレーションをきれいに分離することである。これが最も重要な硬化の原則です。もし、開発者のノートパソコンで、任意のリポジトリがフックやパーミッションデフォルト、プロジェクトスコープのMCPサーバーを定義することを許すなら、それは、利便性を信頼の代わりとして扱うことになります。それこそが、公開勧告が罰した前提なのです。(クロード)
最初のポリシーは単純で、未知のリポジトリは低エージェンシーモードで起動し、理想的には使い捨て環境で起動することです。Anthropicのドキュメントでは、外部のウェブサービスとやり取りする際にVMを推奨しており、以下のように書かれています。 バイパス許可 は隔離されたコンテナやVMにのみ適している。このアドバイスは衛生面以上のものだ。それは、エージェント・コーディング・ツールの爆発半径が、1つの承認プロンプトが伝えるものを超える可能性があることを認めるものだ。隔離の境界は環境であるべきで、クリックしたことを記憶しているユーザーではないのだ。クロード)
第二の方針は .claude/, .mcp.json, CLAUDE.mdおよびプラグイン関連ファイルは、無害なメタデータとしてではなく、コードレビューの対象として扱われます。コードオーナーはこれらのファイルへの変更をレビューすべきである。セキュリティレビュー担当者は、CIワークフロー、Dockerfile、Terraformを差分するのと同じように、それらのファイルを差分すべきである。理由は構造的なものです。Anthropicのドキュメントによると、プロジェクト共有設定にはパーミッション、フック、MCPサーバーを含めることができ、プロジェクトスコープのMCPはソース管理のために特別に設計されている。これだけでも、レビューゲートを正当化するには十分です。新しいCVEを待つ必要はありません。(クロード)
3つ目の方針は、できることを一元化することだ。AnthropicのMCPドキュメントには次のように書かれている。 マネージドmcp.json 管理者がMCPサーバーを排他的に管理し、ユーザーが管理対象外の任意のサーバーを追加できないようにする方法です。これは、意味のある内部システムを持つ企業に適したモデルです。開発者がインターネット上で見つけた任意のMCPサーバーをアタッチできる場合、実際のセキュリティ問題はもはや "ツールの使用 "ではない。サプライチェーンと権限委譲なのだ。マネージドMCPはすべての問題に対する答えではありませんが、ツールの接続は即興的なものではなく、管理されるべきであると強く主張しています。(クロード)
4つ目の方針は、サンドボックスが何をするのか、何をしないのかを正確に伝えることです。Anthropicのサンドボックスのドキュメントは正直なので、ここで役に立つ。サンドボックスはファイルシステムとネットワーク制御でBashサブプロセスを分離します。すべてのClaude Codeの機能が同じ隔離境界の中で実行されるわけではありません。組み込みのファイルツールはパーミッションシステムを直接使用しますし、コンピュータの使用は隔離されたBash環境ではなく実際のデスクトップ上で実行されます。サンドボックス "と聞いて思考停止しているチームは、自分自身を失望に陥れています。サンドボックスは、特にプロンプト・インジェクションに駆動されるシェルのアクティビティに対して価値がありますが、すべてのエージェントの動作を包む万能のラッパーではありません。(クロード)
5つ目の方針は、自律性優先のワークフローよりもエビデンス優先のワークフローを優先することである。Anthropic自身の製品の方向性は、この方向を示している。2026年2月に発表されたクロード・コード・セキュリティは、"モデルにあなたのコードを監視されずにパッチを当てさせる "という枠組みではない。Anthropicは、コードベースをスキャンし、ターゲットとなるパッチを提案し、各検出を多段階の検証プロセスで実行し、重大度と信頼性を割り当て、人間の承認なしに何も適用しないという。これはマーケティング上の雑学ではない。これは、実際のセキュリティ上のプレッシャーのもとで、エージェント・コーディング・システムの成熟した使用がどのようなものであるかについての設計上の声明である。単なる生成ではなく、検証が製品の問題なのだ。(アンソロピック)
同じ原則が攻撃側にも当てはまる。Penligentがペンテストの副操縦士としてクロードについて書いた一般向けの英文では、モデルが攻撃パスやドラフトチェックについての推論を助けることはあっても、仮説を勝手に証明に結びつけることはないという、エビデンスファーストのワークフローを主張している。ここでの直感は正しい。推論レイヤーは、悪用可能性の最終的な裁定者でなくても強力になり得る。実際には、エージェントが、エビデンス、制限された実行、人間によるレビューを保持する検証チェーンの1コンポーネントであるとき、チームはより安全な結果を得ることができる。(寡黙)
6つ目のポリシーは、ネットワークとクレデンシャルの露出を計測することだ。CVE-2026-21852は、ローカルのAIツールが "単なるローカル "であるという考えを殺すべきだった。もし信頼が確立される前に、レポで管理された設定がAPIのルーティングに影響を与えることができるのであれば、開発者のラップトップは、社内のビルドランナーやCIジョブに適用するのと同じアウトバウンドの可視化前提が必要になる。最低限、予期しないドメインを監視し、可能な限り鍵の有効期間を短くし、完璧な証拠を待つのではなく、暴露が妥当な場合は鍵をローテーションする。Anthropicのアドバイザリーでは、潜在的なAPIキー漏洩に対するプレトラストパスについて説明している。チームはそれを、1つのリリースの脚注ではなく、艦隊レベルの教訓として読むべきである。(ギットハブ)
クロード・コードのセキュリティが示す業界の方向性
Anthropicが2026年2月に発表したクロード・コード・セキュリティは、たとえその機能を使うことがなかったとしても、価値のあるものだ。それは、Anthropicがフロンティア・コーディング・エージェントを防衛のためにどのように運用する必要があると考えているかを教えてくれる。発表によると、Claude Code Securityは、既知のパターンのみにマッチするのではなく、コードについて理由を付け、アナリストが見る前に偽陽性をフィルタリングするために、多段階の検証プロセスで各結果を再調査する。発見されたものは重大度評価と信頼度評価を受け、人間の承認なしには何も適用されない。これはAI機能としては驚くほど保守的な形をしているが、それには理由がある。ランタイムがパワフルであるとき、欠けている要素はもはや生成ではない。規律ある検証なのだ。(アンソロピック)
この設計上の選択は、クロード・コードの勧告の歴史をより広く説明する助けにもなる。公的な問題のほとんどは、"AIの創造性 "の失敗ではなかった。実行ガバナンスの失敗だったのだ。検証や制御を改善することなく、単にモデルの能力を拡張するセキュリティ製品は、これらの失敗を改善するどころか、悪化させるだろう。Anthropicのオートモードの発表は、別の角度から同様の点を指摘している。自動モードは、ツールの出力にプロンプト注入プローブを追加し、アクションにトランスクリプト分類器を追加する。これらのレイヤーの存在は、エージェントが有能で人間が忙しくなれば、パーミッションだけでは不十分であることを暗黙のうちに認めていることになる(アンソロピック)
オフェンスチームにとって、この教訓はほぼ対称的である。推論優先のアシスタントは価値があるが、価値の単位は "エージェントにアイデアがあった "ことではない。価値の単位は、"ワークフローが擁護可能な発見をした "ということである。これが、コーディング・アシスタントがより良くなっても、検証者に裏打ちされた攻撃的システムが重要であり続ける理由である。PenligentのAIペンテスト・ワークフローに関する公開資料では、この区別が直接的になされている。重要な境界は、スマートな提案と検証された発見との間のものである。重要な境界は、スマートな提案と検証された発見との間の境界である。セキュリティ・アーキテクチャの原則なのだ。(寡黙)
したがって、クロード・コードは2つの教訓を同時に教えることになる。プロジェクトファイル、パーミッションモード、ツールバス、シェル解析が、本当のバイパスリスクになりうるということだ。もう1つは肯定的なものである。正しい答えは、エージェントによるツーリングを全面的に禁止することではない。それは、推論と検証の間のギャップを狭め、信頼の決定を装飾的なプロンプトではなく、実際の境界に近づけることである。Anthropicの製品の方向性と、Penligentのエビデンスファーストのワークフロー言語は、どちらも同じ成熟したモデルを指している。(アンソロピック)
クロード・コードがエージェント型ツール・セキュリティのリファレンス・ケースとなった理由
クロード・コードは、バグがあったからといって特別な存在ではない。セキュリティに関連するランタイムには必ずバグがある。クロード・コードがユニークなのは、公開されている資料が境界の問題全体を一箇所で示すのに十分なほど豊富だからだ。Anthropicは、ランタイムの強力な表面をオープンに文書化している。GitHubの勧告は、特定の境界がどこで失敗したかを文書化している。NVDは影響の大きいCVEを捕捉している。チェック・ポイントは、プロジェクト・ファイルがどのように実行や流出の経路になり得るかを示した。3月31日のソース・マップの報告は、慎重に扱われたとしても、ホワイトボックス検査のコストも低くなった可能性を示唆している。このような組み合わせにより、Claude Codeは、エージェント型開発者ツールのセキュリティを一般に公開するための最良のリファレンス・ケースの1つとなっている。(クロード)
正しい結論は、"クロード・コードは壊れている "ではない。正しい結論は、エージェント・コーディング・システムは新しいスタイルのレビューを強いるということだ。リポジトリがどのようにポリシーに影響を与えるのか、信頼がどのように順序付けられるのか、ツールがどのように委譲されるのか、メモリがどのように永続するのか、シェルの意図がどのように検証されるのか、ネットワークのイグジットがどのように管理されるのか、検証が楽観主義からどのように切り離されるのかを問う必要がある。これらの疑問は、今日のクロード・コードに当てはまり、明日にはあらゆる本格的なエージェント・コーディング・ランタイムに当てはまるだろう。(クロードAPIドキュメント)
今後のすべてのレビューに持ち越す価値のある一文があるとすれば、それはこれである：エージェント型コーディングシステムでは、プロジェクト・ファイルはもはや単なる入力ではない。それらはコントロールプレーンの一部なのだ。これは、クロード・コードの勧告が無視できないようにした境界の変化である。
参考文献
アントロピック、クロード・コードの概要。(クロード)
Anthropic, Claude Codeのセキュリティ・ドキュメント。(クロード)
Anthropic, Claude Code hook documentation.(クロード)
Anthropic, Claude Code MCP documentation.(クロード)
アントロピック、クロード・コードの許可モード。(クロード)
アントロピック、クロード・コードのオートモードエンジニアリングノート。(アンソロピック)
アントロピック、クロード・コード・セキュリティー発表。(アンソロピック)
NVD, CVE-2025-59536.(NVD)
NVD, CVE-2026-21852.(NVD)
Anthropic GitHub アドバイザリ、repo-controlled settings ファイルによるワークスペース信頼ダイアログのバイパス。(ギットハブ)
Check Point Research、Claude Code プロジェクトファイル、RCE、API トークンの流出。(チェック・ポイント・リサーチ)
Penligent、Claude AI for Pentest Copilot、Claude Codeで証拠第一のワークフローを構築。(寡黙)
Penligent、Claude CodeのプロジェクトファイルがRCEとAPIキーの流出経路に。(寡黙)
Penligent、Agentic Security Initiative、MCP時代におけるエージェントアプリケーションのセキュリティ確保。(寡黙)
ペンリゲントのホームページ(寡黙)
Japanese 
English 
German 
French 
Spanish 
Portuguese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew