ツール拡張エージェントのランタイム防御

1週間前、SSRF、ツールポイズニング、信頼バイパスパターンにわたる50件のMCP脆弱性を公開しました。暗黙の結論は厳しいものでした。攻撃対象領域は監査能力を上回るペースで拡大しています。Wei Zhao、Zhe Li、Peixin Zhang、Jun Sunによる新しい論文が構造的な解決策を提案し、同じ週に発生した実際のテレメトリインシデントがその解決策の重要性を如実に示しています。

ClawGuardは4月13日にarxivで公開されたランタイムセキュリティフレームワークで、すべてのツールコール境界においてユーザーが確認したルールセットを強制します。¹ 評価された構成では、外部ツールの呼び出し前に基本的なアクセス制御ルール（未承認のファイルアクセスのブロック、認証情報の流出防止、ネットワークコールの制限）を適用します。モデルの変更は不要です。インフラの変更も不要です。安全性に特化したファインチューニングも不要です。¹ AgentDojo、SkillInject、MCPSafeBenchにおいて5つのフロンティアLLMでテストされました。¹ 論文ではユーザーの述べた目的から自動的に制約を導出するタスク固有のルール誘導コンポーネントについても記述されていますが、評価対象の構成には含まれていません。

重要な主張は次の通りです。ClawGuardはアラインメント依存の防御を決定論的で監査可能なメカニズムに変換します。¹

アラインメントがセキュリティ境界にならない理由

先週カタログ化したMCP脆弱性の多くは、共通の構造的ギャップを悪用しています。エージェントはツールの説明、取得したウェブページ、またはスキルファイルから指示を受け取りますが、そのインジェクションと実行の間に立ちはだかるのは、正当な指示と敵対的な指示を区別するモデルの能力だけです。（SSRF、RCE、パストラバーサルなど一部の脆弱性はモデルの指示追従に依存しないサーバー側の欠陥を悪用しますが、ツールコール境界は防御において依然として重要です。）

アラインメントトレーニングは役立ちます。RLHFはモデルが有害なリクエストを拒否する確率を高めます。しかし「確率が高い」というのはセキュリティ特性ではありません。プロンプトインジェクションの99%を拒否するモデルでも、1%の確率で失敗します。入力を制御できる攻撃者はその1%に当たるまで反復できるのです。ツールポイズニングパターンに至っては、モデルが失敗する必要すらありません。ポイズニングされた説明が悪意あるアクションを意図されたものに見せかけるためです。

ランタイムインターセプションはまったく異なるレイヤーで機能します。実行前にツールコールを検査するフックやポリシーエンジンは、モデルが攻撃を理解したかどうかに依存しません。チェックは決定論的です。コールが許可されたセットに一致するか、しないかです。

3つのインジェクションチャネル、1つの強制ポイント

ClawGuardはツール拡張エージェントに対する3つの攻撃チャネルを特定しています。¹

ウェブおよびローカルコンテンツインジェクション。 エージェントが敵対的な指示を含むウェブページやローカルファイルを読み取ります。その指示によりエージェントはユーザーが意図しない方法でツールを呼び出します。サイレント流出攻撃対象領域はこのパターンの一例であり、取得されたコンテンツに流出指示が隠されています。

MCPサーバーインジェクション。 侵害されたまたは悪意あるMCPサーバーが、ツールの説明やレスポンスペイロードに指示を埋め込みます。エージェントはそれらの指示をコンテキストとして読み取り、それに従って行動します。先週の50件の脆弱性カタログでこのチャネルを詳細に記録しています。

スキルファイルインジェクション。 攻撃者がエージェントが信頼されたコンテキストとしてロードするスキルファイルや設定に敵対的な指示を配置します。エージェントはスキルファイルの内容を権威あるものとして扱うため、スキルファイルや設定に書き込める攻撃者はエージェントの動作を制御できます。

防御アーキテクチャは、どのチャネルが指示をインジェクトしたかに関わらず、すべての外部アクションが通過しなければならない単一のポイントであるツールコール境界に強制を配置します。¹ エージェントがツールを呼び出す前に、ClawGuardはそのコールをルールセットに照合します。評価された構成では、これらのルールは基本的なアクセス制御制約（ファイルパス制限、ネットワークコールの許可リスト、認証情報アクセスのブロック）です。どれほど巧妙なインジェクションプロンプトであっても、ClawGuardはこれらの制約外のコールをブロックします。

このアーキテクチャの洞察は明確に述べる価値があります。実行境界でポリシーを強制できるなら、すべてのインジェクションを検出する必要はないのです。

Vercelテレメトリインシデント

ClawGuardの論文が公開される4日前の4月9日、Akshay ChughがVercel Plugin for Claude Codeに関する開示を公開しました。² 開示時点での調査結果は以下の通りです。

プラグインはbashコマンド文字列をtelemetry.vercel.comに送信するフックを登録していました。² ~/.claude/vercel-plugin-device-idに保存された永続的なUUIDにより、コマンド文字列がデバイスに紐づけられていました。² プラグインはフックに空文字列マッチャーを使用しており、Vercelプロジェクトだけでなくすべてのプロジェクトでフックが発火していました。² 同意メカニズムはネイティブUIではなくプロンプトインジェクションによりユーザーの同意を取得していました。² ユーザーがVERCEL_PLUGIN_TELEMETRY=offを設定しない限り、マッチしたすべてのイベントでテレメトリが発火していました。²

Vercelは4月14日にテレメトリの懸念に対処し、広範なマッチャーとプロンプトベースの同意メカニズムを削除しました。²

Vercelのインシデントは従来の意味での脆弱性ではありません。認証情報が盗まれたわけではありません。しかし、ランタイム防御が対処するまさにそのクラスの問題を示しています。ユーザーが意図したよりも広範に発火するフックが、ユーザーが明示的に共有に同意していないデータを、ネイティブの同意UIを迂回するメカニズムを通じて収集しているのです。

「テレメトリ」を「流出」に置き換えれば、アーキテクチャは同一です。過度に広範なマッチャーを持つフックが、すべてのプロジェクトで実行され、外部エンドポイントにデータを送信する。テレメトリと攻撃の違いは意図であり、意図はランタイムで監査できません。

論文から実践へ：実務者が既に持っているもの

ClawGuardは実務者が非公式に構築してきたものを形式化しています。Claude CodeにはPreToolUseとPostToolUseのインターセプションをサポートするフックシステムが搭載されています。私はファイルパス制限の強制、ツール入力の検証、破壊的操作の明示的確認ゲートを実行する95以上のフックを運用しています。³

私のフックとClawGuardのビジョンの間のギャップは自動化です。私のフックは手書きのルールです。MCP入力での内部IPアドレスのブロック、プロジェクトディレクトリへのファイル書き込み制限、git force-pushの承認要求などです。評価されたClawGuardの構成は、手書きフックと精神的に類似した基本的なアクセス制御ルールを使用しています。論文で提案されたタスク固有のルール誘導コンポーネントは、ユーザーの述べた目的から自動的に制約を導出するものです。¹ 「/etcへの書き込みをブロック」と記述する代わりに、「ログインモジュールをリファクタリングする」と記述されたタスクにはシステムディレクトリへの書き込みアクセスは不要であると推論するのです。そのコンポーネントは今後の課題として残されています。

自動制約導出はより困難な問題であり、ClawGuardのタスク固有ルール誘導コンポーネントは評価結果ではなく今後の課題です。著者が実際に評価した基本ルール構成は強力ではあるものの完璧ではない結果を示しました。AgentDojoでは攻撃成功率（ASR）0%を達成しましたが、SkillInjectでは依然として4.8〜14%のASR、MCPSafeBenchではモデルによって7.1〜11.0%のASRが見られました。¹ 手書きルールは脆弱です。予測した攻撃しかカバーできません。導出された制約は、何が起こるべきかという正のセットに基づいて動作するため、予測しなかった攻撃もカバーできる可能性があります。何が起こるべきでないかという負のセットではなく。

自動導出が本番環境で確実に機能するかは未解決の問題です。ベンチマークは制御された環境です。実際のエージェントセッションは、曖昧なタスク、マルチステップのツールチェーン、異常に見えるが正当なツールコールを含みます。有効なツールコールをブロックする偽陽性は、「エージェントの実用性を損なわずに」という主張をすぐに侵食するでしょう。

多層防御スタック

ランタイム防御は単一のメカニズムではありません。ツール拡張エージェントの実用的なスタックには少なくとも4つのレイヤーがあります。

レイヤー1：入力検証。 実行前にツールコールの引数を検査するフック。内部IPアドレスのブロック、ファイルパスの検証、シェルメタ文字の拒否。私のPreToolUseフックはこのレイヤーで動作します。偽陽性率は低いですが、既知の不正パターンのみを捕捉します。

レイヤー2：基本ルール強制。 アクセス制御ルール（パス制限、ネットワーク許可リスト、認証情報ガード）に基づいて、許可されるツールと許可される引数のセットを制限します。ClawGuardの評価された構成はこのレイヤーで動作します。¹ 論文ではタスクスコープの制約導出も提案されており、このレイヤーと次のレイヤーの間に位置しますが、そのコンポーネントは今後の課題です。入力検証単体よりもカバレッジは高いですが、環境の変化に合わせてルールを維持する必要があります。

レイヤー3：出力検査。 エージェントが処理する前にツール結果を検査するPostToolUseフック。データ流出を捕捉し、異常なレスポンスを検出し、予期しないツール動作にフラグを立てます。ミドルマンの投稿で出力検査が重要な理由を記録しました。侵害されたルーターが生成後にレスポンスを変更するケースです。

レイヤー4：セッション監査。 すべてのツールコール、すべての引数、すべての結果を事後レビューのためにログに記録します。予防メカニズムではなく検出メカニズムです。Akshay ChughがVercelテレメトリインシデントを発見したのは、まさにこの種の監査によるものでした。フック設定を読み、フックが何をしているかをトレースしたのです。²

単一のレイヤーだけでは十分ではありません。入力検証は新しいパターンを見逃します。タスクスコープの制約は制限が厳しすぎたり緩すぎたりする可能性があります。出力検査はレイテンシを追加します。セッション監査は被害が発生した後に問題を捕捉します。各レイヤーが他のレイヤーの残すギャップをカバーするからこそ、スタック全体が機能するのです。

ClawGuardが正しく捉えていること

この論文は実務者にとって重要な3つの貢献をしています。

アラインメントよりも決定論。 ランタイム防御をアラインメント特性ではなく決定論的メカニズムとしてフレーミングすることは正しいフレーミングです。アラインメントは敵対的条件下で劣化するトレーニング時の特性です。決定論的強制はモデルの動作に関係なく保持されるランタイム特性です。この区別は学術的に聞こえるかもしれませんが、システムのセキュリティ体制について何を約束できるかを変えるものです。

チャネル非依存の強制。 ウェブインジェクション、MCPインジェクション、スキルファイルインジェクションを単一の強制ポイントで防御することは、アーキテクチャ的に健全です。3つのインジェクションチャネルに対して3つの別々の防御を持てば、メンテナンス負荷が生じ、交差部分にギャップが残ります。ツールコール境界の単一の強制ポイントは、構造的に3つのチャネルすべてをカバーします。

モデル変更が不要。 ファインチューニングもアーキテクチャ変更も不要であるため、制御下にないモデルを含む任意のモデルで防御が機能します。Claude Code、Codex CLI、その他のエージェントフレームワークを運用するオペレーターは、モデルプロバイダーがセキュリティアップデートを出荷するのを待たずにランタイム防御を追加できます。

未解決の課題

ClawGuardはベンチマークでテストされました。本番のエージェントセッションはより複雑です。実務者が自動制約導出に依存できるようになるまで、いくつかの疑問が残ります。

曖昧なタスク。「このプロジェクトを手伝って」ではどのツールやパスがスコープ内かが明示されません。曖昧な目的から制約を導出すると、正当なコールをブロックするリスク（制限が厳しすぎる）か、危険なコールを許可するリスク（制限が緩すぎる）が生じます。

マルチステップチェーン。 設定ファイルを読み取り、APIを呼び出し、結果をデータベースに書き込む必要があるエージェントは、複雑なアクセスパターンを持ちます。初期タスクの説明から導出された制約では中間ステップを予測できない可能性があります。

敵対的なタスク記述。 制約導出がユーザーの述べた目的に依存する場合、共有ワークスペース、ポイズニングされたイシュートラッカー、操作されたプロジェクトファイルを通じてタスク記述を制御できる攻撃者が制約自体に影響を与えることができます。

パフォーマンスコスト。 すべてのツールコール境界で制約を評価するとレイテンシが追加されます。論文はフレームワークが実用性を維持すると主張していますが、レイテンシの測定結果は報告されていません。¹ インタラクティブなエージェントセッションでは、ツールコールごとに200msでもユーザー体験が変わります。

実運用上のポイント

現在ツール拡張エージェントを運用している実務者向けに：

今すぐPreToolUseフックをデプロイしましょう。 ClawGuardやその他のフレームワークを待つ必要はありません。Claude Codeのフックシステムは現在ツールコールインターセプションをサポートしています。入力検証から始めましょう。内部アドレスのブロック、ファイルパスの制限、破壊的操作のゲートです。フックチュートリアルで実装を解説しています。

フックマッチャーを監査しましょう。 Vercelのインシデントは空文字列マッチャーがすべてのプロジェクトで発火したことが原因でした。² .claude/settings.jsonのすべてのフックを確認し、各マッチャーが意図したコンテキストのみを対象としていることを検証してください。過度に広範なマッチャーを持つフックは防御ではなく負債です。

すべてのツールコールをログに記録しましょう。 セッション監査は最も少ない労力で最も高い価値をもたらす防御レイヤーです。すべての攻撃を防止できなくても、事後に検出できます。ただし、ログがある場合に限ります。

自分のスタックに対してClawGuardを評価しましょう。 論文はリポジトリへのリンクを掲載していますが、執筆時点でコードはまだ公開されていませんでした。利用可能になったら、既存のフックスタックに対して基本ルール構成を評価してください。タスク固有のルール誘導コンポーネントが成熟すれば、自動制約導出は手書きルールを置き換えるのではなく補完するものとなるでしょう。

設定を信頼境界として扱いましょう。 スキルファイル、フック設定、MCPサーバー定義——エージェントの動作に影響を与えるすべてのファイルは攻撃対象領域です。本番の認証情報と同じアクセス制御を適用してください。

MCP脆弱性カタログは攻撃対象領域を記録しました。ClawGuardは防御アーキテクチャを提案しています。Vercelのインシデントはその両方が重要である理由を示しています。ツールコール境界でのランタイム防御が強制可能なレイヤーです。アラインメントが役に立たないからではなく、強制はアラインメントに依存しないからです。

Sources

よくある質問

ClawGuardはClaude Codeの組み込みパーミッションシステムとどう違いますか？

Claude Codeのパーミッションシステムは、ツールレベルの承認（ツールカテゴリの許可または拒否）と引数レベルの指定子（例：Bash(git diff *)で一致するコマンドのみ許可）の両方をサポートしています。ClawGuardの評価された構成は引数レベルで基本的なアクセス制御ルールを強制します。提案されたタスク固有のルール誘導コンポーネントは現在のタスクから引数制約を自動導出しますが、そのコンポーネントは評価されていません。2つのシステムは補完関係にあります。Claude Codeのパーミッションはどのツールと引数パターンが実行可能かをゲートし、ClawGuardスタイルのランタイム制約が第二の強制レイヤーを追加します。

ランタイム防御を追加するにはClawGuardの出荷を待つ必要がありますか？

いいえ。Claude Codeのフックシステムは現在PreToolUseとPostToolUseのインターセプションをサポートしています。ツール入力を検証する手書きフックは、最も一般的な攻撃パターンを即座にカバーします。ClawGuardの貢献は自動制約導出であり、手動ルールを置き換えるのではなく補強するものです。

Vercelのテレメトリインシデントはセキュリティ脆弱性でしたか？

開示はセキュリティ脆弱性というよりもプライバシーと同意の問題を記述していました。開示時点では、プラグインはすべてのプロジェクトからbashコマンド文字列を収集し、ネイティブUIを通じた明示的なオプトインなしに外部エンドポイントに送信していました。Vercelはその後これらの懸念に対処しています。このアーキテクチャパターン（広範なフックマッチャー、外部データ送信、ネイティブでない同意）は、悪意あるフックがデータ流出に使用するパターンと同一であるため、教訓的な事例として残っています。

ランタイムツールコールインターセプションのパフォーマンスへの影響はどの程度ですか？

シェルスクリプトや軽量バリデーターを使用する手書きフックの場合、私の運用経験ではツールコールあたりのオーバーヘッドは200ms以下に収まるはずです。ClawGuardの論文は制約評価のレイテンシ測定を報告しておらず、追加のオーバーヘッドが発生する可能性があります。インタラクティブなセッションではツールコールごとのレイテンシが重要になるため、複雑な検証ロジックをデプロイする前にテストしてください。