AIエージェント設定のセキュリティはサプライチェーンのセキュリティです

2026年4月29日、セキュリティチーム各社は、認証情報の窃取だけでは終わらないSAPエコシステムのパッケージ侵害を報告しました。Mini Shai-Huludキャンペーンは、開発者設定にも永続化の仕組みを書き込んでいました。Claude Codeフック、VS Codeタスク、リポジトリのワークフローファイルです。¹²³

この一点で、レビューすべき境界は変わります。汚染されたパッケージは、開発者が信頼しているファイルに起動コマンドを残せるなら、インストールされたままである必要すらありません。依存関係を削除すれば、最初のトリガーは消えるかもしれません。しかし、エージェントやエディタの設定が、次のトリガーを生かし続けることがあります。

AIエージェント設定は、実行可能なソフトウェアです。フック、タスク、MCPサーバー定義、スキル、プラグイン、パッケージスクリプト、ワークフローファイルは、すべてソフトウェアサプライチェーンの一部として扱うべきです。人間がdiffを読む前に、どのコードを実行するかをそれらのファイルが決められるからです。

要約

Mini Shai-Huludは、依存関係のインストールから開発者ツールへの永続化へ進む、現実的な経路を示しました。セキュリティ研究者は、悪意あるnpmパッケージがインストール時にライフサイクルスクリプトを使い、開発者とCIの認証情報を収集し、信頼された開発者ツール上でコードを再実行するために.claude/settings.jsonと.vscode/tasks.jsonを書き込んだと報告しています。¹²⁴ 公式ドキュメントからも、土台となる実行領域に実際の権限があることが確認できます。Claude Codeフックはライフサイクルコマンドを実行し、コマンドフックはユーザー権限で実行されます。VS CodeのfolderOpenタスクも、そのフォルダで自動タスクを許可した後、フォルダを開いたタイミングで実行され得ます。⁵⁶

教訓は「エージェントを止めよう」ではありません。もっと明確です。エージェント設定は、依存関係レビュー、コードレビュー、インシデント対応、リリース基準に含めるべきです。以前はローカルの好みのように見えていたドットディレクトリが、いまは実行経路の上にあります。真剣なAIエンジニアリングには、設定diff、フックレビュー、タスクレビュー、最小権限のトークン、起動時に動く領域の監査が必要です。

重要なポイント

開発者向け: - リポジトリを信頼する前に、.claude/settings.json、.vscode/tasks.json、.github/workflows/*、package.jsonスクリプト、MCP設定、エージェントのプラグインやスキルのマニフェストを確認しましょう。 - 新しい起動フックや、フォルダを開いたときに動くタスクは、新しい実行可能ファイルと同じように扱ってください。 - 不審なインストールがあった後は、永続化ファイルを削除し、認証情報をローテーションします。パッケージを削除しただけでは、クリーンアップできた証明にはなりません。

セキュリティチーム向け: - エージェント設定ファイルを、サプライチェーン検知、CODEOWNERS、シークレット対応、インシデント範囲特定に含めてください。 - 起動時の実行、広範なシェルコマンド、不透明なダウンロード済みバイナリ、隠れたドットディレクトリ内のペイロードを追加するPRは、すべてフラグを立てます。 - 公開用認証情報は短命にし、インストール用認証情報は読み取り専用を優先します。長命の書き込みトークンは、ワームの燃料であり続けます。

エージェントプラットフォーム構築者向け: - 実行領域を見えるようにし、レビュー可能で、説明可能にしてください。 - 文脈読み込み用フックと、コマンド実行用フックを分離します。 - 起動時アクション、外部ネットワーク呼び出し、変更された設定を監査できる第一級のビューをユーザーに提供してください。

Mini Shai-Huludが変えたこと

パッケージマネージャーへのサプライチェーン攻撃には、すでにおなじみの流れがあります。信頼されているパッケージに悪意あるバージョンが入ります。インストールスクリプトが実行されます。ペイロードがトークンを盗みます。レジストリでの削除やバージョンのロールバックは、その悪いバージョンを一部の開発者やCIジョブがすでにインストールした後に届きます。

Mini Shai-Huludは、そこにエージェント時代ならではの一手を加えました。Endor Labs、Wiz、Socket、StepSecurity、Cloud Security Allianceの報告は、大枠として同じ形を説明しています。SAP開発者エコシステム内の侵害されたパッケージがnpmのインストール時実行を使い、GitHub、npm、クラウド、CIの認証情報を収集し、開発者ツールの設定を通じて永続化を作っていました。¹²³⁴⁷

Wizは、将来Claude CodeやVS Codeでリポジトリを開いたときに実行を再トリガーできるよう、リポジトリ内にファイルを置くフォールバック経路を記録しています。² Endor Labsは、Claude CodeのSessionStartフックと、runOn: "folderOpen"を持つVS Codeタスクを説明しています。¹ Socketのキャンペーントラッカーは、npmとPyPIパッケージの侵害と並べて、.claude/settings.jsonと.vscode/tasks.jsonによる永続化を挙げています。³

具体的なペイロードの詳細は、一般的なエンジニアリング記事ではなく、インシデント報告に属する話です。ここで残すべき教訓は、次のとおりです。

標的は、1つのパッケージバージョンから、そのパッケージを取り巻く開発者環境へ移りました。

設定ファイルは起動プログラムになりました

Claude Codeのフックリファレンスでは、フックはライフサイクルイベントで自動的に実行される、ユーザー定義のシェルコマンド、HTTPエンドポイント、またはLLMプロンプトだと説明されています。⁵ 同じドキュメントは、SessionStartがClaude Codeの起動時または作業セッション再開時に実行されるとし、セキュリティセクションでは、コマンドフックがユーザーの完全な権限で実行されると警告しています。⁵

VS Codeのタスクドキュメントにも、別の実行領域があります。タスクはrunOnにfolderOpenを設定でき、VS Codeは、そのフォルダで自動タスクの実行をユーザーが許可した後、対象フォルダを開いたときにタスクを実行します。⁶ この同意プロンプトは重要です。すべてのマシンで黙って実行される場合より、リスクは下がります。それでも、そのファイルが無害になるわけではありません。信頼されたリポジトリ、疲れた開発者、すでに許可済みのワークスペース、組織ポリシーのいずれかによって、設定変更がコード実行に変わり得ます。

npmは、インストール時の橋渡しを加えます。npm scriptsドキュメントは、npm ciとnpm installで動くライフサイクルスクリプトの中にpreinstall、install、postinstallを挙げています。またnpmのベストプラクティスでは、対象アーキテクチャ向けのコンパイルを除き、作者がpreinstallやinstallスクリプトを明示的に設定するべき場面はほとんどないとされています。⁸

この3つの事実が、攻撃チェーンを作ります。

1. 依存関係のインストール中にインストールスクリプトが実行されます。
2. そのスクリプトが、開発者ツールの設定を書き込むかパッチします。
3. 後でエディタやエージェントが、設定された起動時アクションを実行します。
4. プロンプトやUIが普段の作業に見えるため、開発者はそのツール領域を信頼します。

危険なのは、どれか1つの機能ではありません。インストールスクリプト、フック、タスク、ワークフローは、どれも正当な自動化を支えています。危険なのは、信頼の連鎖です。パッケージのインストールが、将来のすべてのエージェント作業やフォルダオープンで実行される内容を、黙って定義できてはいけません。

レビュー境界が間違っています

多くのコードレビュー習慣では、ソースファイルを主な成果物として扱い、設定ファイルは補助資料として見ています。設定ファイルがコマンドを実行する場合、この習慣は破綻します。

新しいフックは、新しいシェルスクリプトと同じレビューを受けるべきです。新しいタスクは、新しいバイナリと同じレビューを受けるべきです。新しいMCPサーバーは、新しいネットワーク連携と同じレビューを受けるべきです。新しいパッケージライフサイクルスクリプトは、テストより前に実行される新しいコードと同じレビューを受けるべきです。

レビュー表を使いましょう。

ツール拡張エージェントの実行時防御では、強制はツール呼び出しの境界に置くべきだと論じました。Mini Shai-Huludは、同じ基準をさらに1層手前に押し出します。起動境界にも強制が必要です。

起動時の権限には最小権限が必要です

チームはすでに、APIキーには最小権限を適用しています。エージェント設定にも同じルールが必要です。

Claude Codeは、PreToolUse、PostToolUse、SessionStartといったフックイベントを分離しています。⁵ その分離は、ポリシーにも反映されるべきです。静的な文脈を読み込むフックに、シェルアクセスは不要です。コマンドを検証するフックに、ネットワークアクセスは不要です。ローカルメタデータを記録するフックに、認証情報は不要です。

同じルールは、VS CodeタスクとCIワークフローにも当てはまります。

npmのtrusted publishingドキュメントは、短命の認証情報がなぜ重要かを説明しています。Trusted publishingはOIDCを使うため、長命のnpmトークンなしでパッケージ公開を実行できます。またnpmは、trusted publisherの設定後に従来型のトークンベース公開を無効にすることを推奨しています。⁹ npmはさらに、OIDCで公開する場合、プライベート依存関係のインストールには読み取り専用の粒度付きアクセストークンを推奨しています。⁹

この助言は、ワークフローリスクを消すものではありません。侵害されたワークフローは、権限が大きすぎれば今でも被害を出せます。教訓は、両側を小さくすることです。認証情報は短命にし、ワークフローは狭くします。

エージェント設定を依存関係として扱う

依存関係レビューでは、通常どのパッケージバージョンが変わったかを確認します。エージェント時代のレビューでは、どの実行領域が変わったかを確認するべきです。

依存関係の更新、プラグインのインストール、生成された設定、テンプレート変更を受け入れる前に、次を確認してください。

目的は、疑心暗鬼になることではありません。分類を正しくすることです。フックファイルは設定に見えるかもしれませんが、コードのように振る舞います。タスクファイルはエディタ設定に見えるかもしれませんが、シェルを起動できます。ワークフローはリリース配管に見えるかもしれませんが、認証情報に届く可能性があります。

AIエージェントの安全性は小さなソフトウェアから始まるでは、デザイン側から関連する主張をしました。狭いツールほど、ミスが隠れる場所が少なくなります。セキュリティ版の言い方をすれば、狭い設定ほど、永続化が隠れる場所が少なくなります。

安全な設定確認

防御的なレビューでは、不審なコードを実行する必要はありません。まずは読み取り専用の確認から始めます。

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

これらのコマンドは、マシンがクリーンだと証明するものではありません。設定を実行に変えやすい領域を、レビュアーが最初に見るための入口です。不審なインストールがすでに起きていた場合は、検索結果がきれいだったことを安心材料にせず、インシデント対応へ移ってください。

復旧には設定確認が必要です

侵害された依存関係へのインシデント対応は、パッケージのアンインストールで止めてはいけません。

復旧手順は次のとおりです。

1. 影響を受けたパッケージバージョンが、開発者マシンまたはCI実行環境にインストールされたかを特定します。
2. その環境がさらに作業を進める前に凍結します。
3. リポジトリ内の起動設定ファイルと、ホームディレクトリ内のエージェントまたはエディタ設定を監査します。
4. 不審なフック、タスク、ワークフロー、生成されたペイロードファイル、予期しないブランチを削除します。
5. 影響を受けたプロセスがアクセスできたすべての認証情報をローテーションします。パッケージトークン、GitHubトークン、クラウドキー、SSHキー、CIシークレットを含みます。
6. パッケージ公開者アクセスとリポジトリ書き込みアクセスを検査します。
7. シークレット露出や予期しない外向き通信がないか、ワークフローログを確認します。
8. クリーンなcheckoutと既知の安全な依存関係セットから環境を再構築します。

GitHubのActionsセキュリティガイダンスは、この対応のうち認証情報側を支えています。ワークフロートークンには最小権限を使うこと、露出したシークレットをローテーションすること、シークレットの扱いを監査すること、ジョブがenvironment secretsにアクセスする前にレビューを必須にすることを検討することが示されています。¹⁰ GitHubはまた、.github/workflows配下の変更に指定レビュアーの承認を必須にできるよう、ワークフローファイルにCODEOWNERSを使うことも推奨しています。¹⁰

エージェント設定も、同じ統制経路に入れてください。.github/workflows/*がシークレットに触れ得るためコードオーナーレビューに値するなら、.claude/settings.jsonと.vscode/tasks.jsonも、シークレットの近くでコマンドを実行し得るためレビューに値します。

エージェントプラットフォームが作るべきもの

エージェントプラットフォームとエディタは、起動時の権限を明示することでレビュー負荷を下げられます。

有用なプロダクト領域は次のとおりです。

これらの領域は、モデルがJSONファイルを読んで判断することに依存すべきではありません。実行環境そのものが、権限を直接見せるべきです。ユーザーには、「READMEから文脈を読み込む」と「作業セッション開始時にシェルコマンドを実行する」の違いがはっきり見える必要があります。

MCPツールにはアクション単位の認可が必要ですでは、bearer-token検証は、ツール単位、役割単位、アクション単位のチェックにつながるべきだと論じました。エージェント設定にも同じ形が必要です。すべての起動時アクションは必要な権限を宣言し、実行環境は実行可能な最小セットを強制するべきです。

実用的なローカルポリシー

プラットフォームのインターフェースが改善される前でも、チームは小さなポリシーファイルから始められます。

良いポリシーは、ファイルと権限を名指しします。「エージェントツールには気をつける」のような曖昧なルールは、実作業に耐えません。「所有者レビューなしのSessionStartコマンドフックは禁止」のような明確なルールなら、レビュアーが強制できます。

FAQ

AIエージェント設定は本当にサプライチェーンの一部ですか？

はい。サプライチェーンリスクは、ファイル拡張子ではなく、実行と信頼に沿って広がります。パッケージインストール、プラグイン、テンプレート、リポジトリ変更が、後でコマンドを実行するエージェント設定を変更できるなら、その設定はサプライチェーンの中にあります。

チームはClaude CodeフックやVS Codeタスクを禁止するべきですか？

いいえ。フックやタスクは、正当な自動化を支えています。チームがすべきことは、レビューし、範囲を絞り、ログを残すことです。文脈読み込み用フックと、起動時にシェルを実行するフックに、同じ信頼を与えるべきではありません。

VS Codeはフォルダオープンタスクの実行前に確認しますか？

VS Codeのドキュメントでは、ユーザーがfolderOpenタスクを含むフォルダを初めて開くとき、そのフォルダで自動タスクを許可するか確認すると説明されています。⁶ このプロンプトは助けになりますが、承認後はそのファイルが実行経路になるため、タスクにはやはりコードレビューが必要です。

npm trusted publishingはパッケージ侵害を解決しますか？

いいえ。Trusted publishingは、短命のOIDCベース認証情報を使うことで、長命のnpm書き込みトークンのリスクを下げます。⁹ それでもチームには、ワークフローレビュー、最小権限、パッケージ監視、侵害されたリポジトリや悪意あるインストールスクリプトへのインシデント対応が必要です。

不審なインストール後、最初に何を監査すべきですか？

インストール時スクリプト、エージェントとエディタの起動設定、ワークフローファイル、予期しないドットディレクトリ内ファイル、新しいブランチ、影響を受けたプロセスに露出していた認証情報を監査してください。その後、影響を受けた環境から認証情報をローテーションします。

終わりに

AIコーディングエージェントは、設定をより強力にします。同時に、設定をより危険にもします。

必要なのは、自動化を恐れることではありません。実行がどこにあるのかを正直に見ることです。コマンドを実行できる、データを取得できる、シークレットを読める、パッケージを公開できる、エージェントの振る舞いを変えられる。そうしたファイルは、レビュー経路に入れるべきです。

エージェント設定は、その線を越えました。コードとして扱いましょう。

参考文献