ツールが発火する前に、受信したプロンプトだけでなく各ターンをインジェクションについてスキャンします。VeriSwarm Guardは2つの検出レイヤー——高速な構造的パターン分析と、それに続く自己ホスト型のDeBERTa分類器——をすべて自社インフラ内で実行します。サードパーティの検出APIへの呼び出しはなく、判定を得るためにリクエストペイロードが境界外に出ることもありません。
堅牢化されたシステムプロンプトやクリーンなレッドチーム評価は、本番環境で本当に重要となる攻撃を止めません。エージェントがサポートチケットを読み取り、チケット本文に隠された指示が請求レコードを照会してその結果をWebhookへ転送するよう指示します。モデルは自身のシステムプロンプトに違反することは決してありません——ツールを呼び出すだけです。ツールが実行されます。データが流出します。検出は、ユーザーが入力した内容だけでなく、まさにツール呼び出しを引き起こそうとしているテキストに対して実行されなければなりません。
プロンプト層での防御がこの攻撃経路を見逃す理由についての完全な論拠は、プロンプトインジェクションはLLMで止まらない。ツール呼び出しを通じて伝播する。.
正規表現ベースで、モデルのコストはゼロ。プロトコルレベルの操作を捉える——チャット形式の区切り文字インジェクション(偽の<|im_start|>、[INST]や、あるメッセージがどこで終わり別のメッセージがどこで始まるかについてモデルを混乱させることを意図した同様のマーカー)、および base64 や類似のエンコーディング内に密輸されたペイロードを捉えます。これらは構造的なシグナルであり、キーワードの一致ではないため、ワードリストでは完全に見逃してしまうようなプロトコルのトリックにも反応します。
DeBERTaベースのモデル(protectai/deberta-v3-base-prompt-injection-v2)は一度だけロードされ、ONNX Runtimeを介してローカルで提供されます。表面的なパターンではなく意図を読み取るため、言い換えられた攻撃、多言語インジェクション、既知のパターンに一致しないほど新しい回避技術を捉えることができます。モデルのロードに失敗した場合、検出はフェイルオープンするのではなく構造的分析にフォールバックします。
この2つのレイヤーは順番に実行されます——まず構造的分析。これはコストが低く、最も露骨な攻撃をすぐさま捉えるためです。その後、構造的分析でまだフラグが立てられていないものすべてに対して分類器が実行されます。
POST /v1/suite/guard/scanは、次のボディ { "text": "...", "scan_injection": true, "scan_moderation": true } を受け取り、{ "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." } を返します。injection オブジェクトには、一致したカテゴリ、信頼度スコア、そしてどのレイヤーが判定を下したかが含まれます。ツール呼び出しを引き起こす可能性のあるテキスト——ユーザーメッセージ、ナレッジベースから取得したコンテンツ、上流の連携からのWebhookペイロードなど——には、その呼び出しが発生する前に、このAPIを呼び出してください。
Guard ProxyはVeriSwarmの透過的なMCPインターセプション層であり、インジェクションスキャンはそのパイプラインにおける固定ステップです。ツールサーバーから返ってくるすべてのレスポンスは、エージェントに到達する前に、PIIトークン化やポリシー適用と並んでインジェクションの試みがないかチェックされます。エージェントのMCPクライアントを、ツールサーバーに直接ではなくプロキシに向けてください——エージェント側のコード変更はゼロです。
ターンごとのスキャンは、単一のメッセージに現れるインジェクション試行を捉えます。一部の攻撃はそうではありません——会話全体にわたってリスクを蓄積し、システムプロンプトを抽出したりカナリア値を少しずつ外部に流出させたりする、じわじわとした試みです。Session Sentryは、ターンごとではなくセッション全体でリスクをスコアリングする補完的なレイヤーとして機能し、上記の構造的レイヤーおよびDeBERTaレイヤーの代わりではなく、それらと並行して動作します。
インジェクション検出は、操作されたツール呼び出しが発火するのを防ぎます。これは、正当なツール呼び出しが本来してはならないPIIを運んでしまう場合に起きることとは関連しつつも別の問題です——詳しくはAIエージェントによるデータ漏洩を防ぐ方法で扱っています。Guardは両方のチェックを同じパイプラインで実行します。
なぜなら、ペイロードは危険であるためにジェイルブレイクのように見える必要はないからです。サポートチケットやスクレイピングされたWebページに隠された指示は、モデル自身のシステムプロンプトには一切触れないまま、どのツールが、どの引数で、誰のデータに対して呼び出されるかを変えてしまうことがあります。呼び出しがツールサーバーに到達する頃には、モデルはすでにループの外にあり、実行するのはプロトコルです。ツール呼び出しが発火する前にレスポンスをスキャンすれば、このクラスの攻撃を捕えられます。受信プロンプトだけをスキャンしても捕えられません。
レイヤー1は構造的分析——正規表現ベースで、チャット形式の区切り文字インジェクション(モデルにメッセージ境界を誤認させることを狙った偽の<|im_start|>や[INST]マーカー)やbase64・エンコーディングによる密輸といった、プロトコルレベルの操作を検出します。高速であり、意味的な理解すら必要としない攻撃も捉えます。レイヤー2は機械学習分類器で、テキストの実際の意図を読み取り、言い換えられた攻撃、多言語インジェクション、そしてパターンマッチングだけでは見逃してしまう新しい回避技術を捉えます。
DeBERTaベースの分類器(protectai/deberta-v3-base-prompt-injection-v2)で、ローカルにロードされ、VeriSwarm自社インフラ内でONNX Runtimeを介して提供されます。サードパーティのインジェクション検出APIへの発信呼び出しは一切なく、判定を得るためにリクエストペイロードがテナント境界を越えることもありません——検出は完全に自己完結しています。何らかの理由でモデルのロードに失敗した場合、検出はフェイルオープンするのではなく、構造的分析のみにフォールバックします。
はい——POST /v1/suite/guard/scanは{ "text": "...", "scan_injection": true, "scan_moderation": true }を受け取り、{ "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." }を返します。injectionフィールドには、カテゴリ、信頼度スコア、そしてどのレイヤー(structuralまたはml)が判定を下したかが含まれます。信頼できないテキスト——ユーザーメッセージ、RAGコンテンツ、Webhookペイロードなど——には、ツール呼び出しを引き起こしうるステップに到達する前に、このAPIを呼び出してください。
すでにGuard Proxyを稼働させているなら不要です。Guard Proxyは VeriSwarmの透過的なMCPインターセプション層であり、プロンプトインジェクションのスキャンはその固定パイプラインの1ステップです。ツールサーバーから返ってくるすべてのレスポンスは、エージェントに到達する前に、PIIトークン化やポリシー適用と並んでインジェクションの試みがないかチェックされます——エージェント側のコード変更はゼロです。直接呼び出せるスキャンAPIは、プロキシの経路の外でテキストを自分でチェックしたい場合のために用意されています。
はい、独立した補完的レイヤーとして検出します。Session Sentryは、単一のターンを個別に評価するのではなく、会話全体にわたってリスクシグナル——カナリートークンの露出、システムプロンプト抽出の試みなど——を蓄積します。これにより、個々のメッセージ単体では検知されないような、じわじわとした流出試行を捉えることができます。ターンごとの構造的レイヤーおよびDeBERTaレイヤーの代わりではなく、それらと並行して動作します。
Guard——スキャンベースのインジェクション検出とGuard Proxyの自動スキャンを含む——はMaxプランの機能です。Gateの無料ティアは、まずトラストスコアリングとイベントの可視性を提供します。Guardで初めて強制力(エンフォースメント)がオンになります。
Guardのインジェクション検出——APIおよびGuard Proxyの自動スキャン——はMaxプランの機能です。Gateの無料ティアは、まずトラストスコアリングとイベントの可視性を提供します。