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

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

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

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

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

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

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

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

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

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

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

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

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

この防御アーキテクチャは、ツールコール境界——どのチャネルから指示がインジェクションされたかに関わらず、すべての外部アクションが通過しなければならない単一のポイント——に強制を配置します。¹ エージェントがツールを呼び出す前に、ClawGuardはユーザーの元のタスクから導出された制約に照らしてコールを検査します。制約の範囲外のコールは、インジェクションプロンプトがどれほど説得力があっても、ブロックされます。

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

Vercelテレメトリ事件

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

このプラグインは、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つの貢献をしています：

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

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

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

未解決の課題

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

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

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

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

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

実践的な要点

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

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

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

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

自分のスタックに対してClawGuardを評価しましょう。 論文のコードは公開されています。既存のフックスタックに対して基本ルール構成を評価してください。タスク固有のルール帰納コンポーネントが成熟すれば、自動制約導出は手書きルールを置き換えるのではなく、補完するものとなるでしょう。

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

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

出典

よくある質問

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

Claude Codeのパーミッションシステムはツールレベルでユーザーの承認を求めます——特定のツールカテゴリを承認するか拒否するかです。ClawGuardは引数レベルで動作し、現在のタスクに基づいてツールコールが含むべき引数に対する制約を自動導出します。2つのメカニズムは補完的です：パーミッションがどのツールを実行できるかをゲートし、ランタイム制約がそれらのツールをどのように呼び出せるかをゲートします。

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

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

Vercelテレメトリ事件はセキュリティ脆弱性でしたか？

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

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

シェルスクリプトや軽量バリデーターを使用する手書きフックの場合、フックのドキュメントガイダンスに従えば、オーバーヘッドはツールコールあたり200ms未満に収まるはずです。ClawGuardの論文では制約評価のレイテンシ測定は報告されておらず、追加のオーバーヘッドが生じる可能性があります。インタラクティブセッションではツールコールあたりのレイテンシが重要になるため、複雑なバリデーションロジックをデプロイする前にテストしてください。