TrueFoundryとのPillar Security統合

‍この度、Pillar Securityとの提携を発表いたします。この提携により、適応型ランタイムガードレールがAIエージェントおよびLLMトラフィックの経路に直接組み込まれます。

TrueFoundryのAI Gatewayを介してモデルおよびエージェントのトラフィックをルーティングしているチームは、Pillar Securityをファーストクラスのガードレールプロバイダーとして接続できるようになりました。これにより、本番環境におけるプロンプト、応答、ツール呼び出し、MCPインタラクション全体でリアルタイムのスキャンとポリシー適用を実現できます。この統合は、ゲートウェイによって公開されている4つのガードレールフックで実行され、エージェントまたはアプリケーションコードの変更は不要です。

この記事では、この統合のアーキテクチャについて説明します。TrueFoundry AI Gatewayがランタイムでガードレールを実行する方法、Pillarのスキャナーパイプラインがその実行モデルにどのように組み込まれるか、そしてチームが特定のモデル、MCPサーバー、ユーザー層を対象とするルールをどのように構成するかを解説します。

エンタープライズ向けエージェントAIに2つのレイヤーが必要な理由

TrueFoundry は、本番AIシステム向けの制御レイヤーを提供します。AI Gatewayを通じて、チームはLLM、ツール、MCP接続ワークフロー全体で、モデルルーティング、キー管理、アクセス制御、可観測性、ガバナンスを一元化します。すべてのリクエストは単一のプロキシレイヤーを通過し、そこでIDが検証され、レート制限が適用され、トレースがキャプチャされます。

Pillar Security は、ランタイムセキュリティレイヤーを提供します。その検出モデルは、プロンプトと応答をスキャンし、ジェイルブレイク試行、プロンプトインジェクション、PIIおよびPCIデータ、シークレット、有害な言語、不可視文字攻撃を検出します。Pillarの適応型ガードレールは、同じアプリケーションに対して実行されたレッドチーム演習によって情報が提供され、エージェントの定義されたビジネス目的に合わせて調整され、誤検知を削減します。

これら2つのソリューションを組み合わせることで、チームはクリーンな本番アーキテクチャを実現できます。TrueFoundryはデプロイ、ルーティング、運用制御を処理し、Pillarはランタイム検査、脅威検出、ポリシー適用を処理します。Pillar Securityは、TrueFoundryゲートウェイ内でファーストクラスのガードレールプロバイダーとしてサポートされており、llm_input_guardrails、llm_output_guardrails、mcp_tool_pre_invoke_guardrails、mcp_tool_post_invoke_guardrailsにフックを備えています。

本番エージェントのデプロイにおけるギャップ

AIエージェントを構築するほとんどのチームは、デプロイと信頼性の確保に注力しています。エージェントは適切なツールを呼び出し、長時間の会話でコンテキストを管理し、再試行を処理し、ユーザー全体にスケールする必要があります。この作業は必要不可欠ですが、ランタイムセキュリティの問いには答えていません。

多くのエージェントAIデプロイにおけるセキュリティは、境界で止まっています。プラットフォームのアクセス制御、MCPサーバーの許可リスト、ツールレベルの権限、ダウンストリームシステム用のスコープ付き認証情報などはすべて整備されています。これらの制御は重要ですが、ランタイムパスは検査されないままです。

境界では答えられない疑問には、エージェントが実行を開始した後に実際に何をしているのか、どのツールをどのような順序で、どのようなデータで呼び出しているのか、といったものがあります。もしプロンプトインジェクションが取得されたコンテキスト、MCPサーバーの応答、または外部APIの結果を介して侵入した場合、境界には、エージェントがそれに基づいて行動しようとしているかどうかを把握する術がありません。

ゲートウェイパス上のランタイムガードレール

この統合の背後にあるアーキテクチャの考え方は直接的です。すべてのモデル、ツール、MCPトラフィックがすでにゲートウェイを通過している場合、ゲートウェイはランタイムセキュリティを適用するのに適切な場所です。PillarをTrueFoundry AI Gatewayに接続することで、チームはエージェントトラフィックがすでにルーティングおよび管理されているのと同じパスでガードレールを適用できます。評価はライブトラフィックに対して行われ、実行後にレビューされるトレースに対してではありません。

Pillar Argusは、適応型ランタイムレイヤーとして動作します。Pillarは、本番環境におけるすべてのインタラクションにスキャナーを適用するため、プラットフォームチームとセキュリティチームは、エージェントの動作中にそれを監視、評価し、ポリシーを適用できます。スキャナーの出力には、セッション識別子、フラグ付きブール値、カテゴリごとのトリガー、および問題のあるテキストとその入力内の位置を含む証拠配列が含まれます。

Pillarは、ランタイムで以下の検出カテゴリを公開しています。 ジェイルブレイク検出 モデルの安全性トレーニングを回避しようとする試みを特定します。 プロンプトインジェクション 検出は、取得されたコンテキストやツール出力による直接的および間接的なインジェクションの両方を対象とします。 PIIおよびPCI検出 40以上の個人データおよび決済カードデータのカテゴリを網羅し、データがモデルに到達する前のマスキングをサポートします。 シークレット検出 プロンプトまたはモデル出力に含まれるAPIキー、トークン、認証情報を特定します。 コンテンツモデレーション および 有害な言語 の検出は、安全でないコンテンツやポリシーに違反するコンテンツを対象とします。 不可視文字 検出は、人間によるレビューをすり抜けて指示を密かに送り込むために使用される、隠されたUnicodeペイロードを検知します。

エージェントシステムの場合、Pillarは単一のプロンプトと応答のペアだけでなく、ツール呼び出し、MCPリクエスト、多段階の実行コンテキストも評価します。多くのエージェントAIの障害は、単一のモデル呼び出しではなく、一連の行動全体にわたって発生します。

ゲートウェイがガードレールを実行する方法

TrueFoundry AI GatewayはHonoフレームワーク上で動作し、単一のゲートウェイポッドは1 vCPUと1 GBのRAMで毎秒250以上のリクエストを約3ミリ秒の追加レイテンシで処理します。ゲートウェイポッドはステートレスでCPUバウンドであり、追加のポッドによって数万RPSまで水平にスケールします。コントロールプレーンとゲートウェイプレーンは分離されています。ガードレールルール、モデル定義、レート制限を含む設定はコントロールプレーンに存在し、NATSを介してゲートウェイポッドに同期されます。実際の要求パスは、LLMプロバイダー以外の外部呼び出しなしにメモリ内に留まります。

ガードレールは、リクエストのライフサイクルにおける4つの個別のフックで実行されます。

llm_input_guardrails モデルに到達する前にプロンプトを傍受します。ゲートウェイはまず入力ペイロードをPillarに送信します。Pillarが以下を返した場合、 flagged: true 設定されたスキャナーに対しては、リクエストはブロックされ、LLMは呼び出されません。入力ガードレール呼び出しは、最初のトークンまでの時間を最適化するためにモデルリクエストと並行して実行され、違反があった場合はプロバイダー費用が発生するのを避けるため、モデル呼び出しは直ちにキャンセルされます。

llm_output_guardrails LLMが応答した後、かつその応答が呼び出し元に返される前に発動します。出力ガードレールは順次実行されます。ゲートウェイはモデルの出力を待ち、クライアントに配信する前にスキャンするためにPillarに送信します。これは、PII漏洩、機密情報の露出、有害な生成、およびモデルが生成したあらゆる安全でないコンテンツを捕捉するための適用ポイントです。

mcp_tool_pre_invoke_guardrails エージェントによってツールが実行される前に発動します。Pillarはツール名、引数、および呼び出しコンテキストを評価します。引数に機密データが含まれている場合、または範囲外のリソースアクセスを示している場合、実際の行動が発生する前にツール呼び出しはブロックされます。

mcp_tool_post_invoke_guardrails ツールが結果を返した後、かつその結果がエージェントの推論ループに戻される前に発動します。これは、ツール出力における間接的なプロンプトインジェクション、MCPサーバーからの認証情報漏洩、およびアップストリームAPIによって返されるPIIを検出するための適用ポイントです。ここで阻止することで、エージェントが汚染されたコンテキストに基づいて行動するのを防ぎます。

各フックは3つの強制戦略をサポートしています。 強制 違反時、またはガードレールサービスエラー時にブロックします。 エラー時は無視して強制 違反時にはブロックしますが、ガードレールサービス自体に到達できない場合はリクエストの続行を許可します。 監査 判定をログに記録し、決してブロックしません。各ガードレールは、2つの動作モードもサポートしています。 検証 モードは、ブロックまたは通過の決定を生成します。 変異 モードでは、ガードレールサービスが処理中のコンテンツを変更できます。これがPillarのマスキング機能が組み込まれている方法です。マスクモードはPillar側で設定され、プロンプトがモデルに到達する前に、一致したPIIと機密情報について編集された値を表示します。

統合インターフェース

Pillarは、TrueFoundryコントロールプレーンで、2つの入力を持つガードレール統合として構成されます。1つ目は、Pillarコンソールによって発行されたAPIキーです。2つ目は、この統合でどの検出カテゴリを実行するかを選択するスキャナー構成です。

統合が登録されると、ゲートウェイはそれをセレクターとして公開し、どのガードレールルールからも参照できるようになります。ルールはYAMLルールブロックを通じて設定され、各ルールは2つの条件を持つwhenブロックを使用します。 ターゲット モデル、mcpServers、mcpTools、またはリクエストメタデータに一致します。 サブジェクト ユーザーまたはチームのIDにinおよびnot_in演算子を使用して一致します。その後、ルールは4つのフックのどれでどのガードレール統合を実行するかを宣言します。

全てのチームが使用するOpenAIモデルに対して、入力と出力でPillarを実行するベースラインルールは次のようになります。‍

name: guardrails-control
type: gateway-guardrails-config
rules:
  - id: pillar-baseline
    when:
      target:
        operator: or
        conditions:
          model:
            values:
              - openai-main/gpt-4o
            condition: in
      subjects:
        operator: and
        conditions:
          in:
            - team:everyone
    llm_input_guardrails:
      - pillar/pillar-default-profile
    llm_output_guardrails:
      - pillar/pillar-default-profile
    mcp_tool_pre_invoke_guardrails: []
    mcp_tool_post_invoke_guardrails: []

エージェントチームが使用するMCPサーバー周辺にPillarスキャンを追加する2番目のルールは、そのMCPサーバーをターゲットとし、ツール呼び出し前後のフックで統合を適用します。一致する全てのルールはまとめて評価され、各フックでガードレールセットが結合されます。両方がターゲットとする2つのルール llm_input_guardrails は両方とも入力で実行されます。

リクエストごとのオーバーライドは、 X-TFY-GUARDRAILS ヘッダーを通じてサポートされています。このヘッダーには、4つのフックの任意の組み合わせに対するガードレールセレクターを指定するJSONオブジェクトが含まれています。これにより、アプリケーションチームはグローバル設定を変更することなく、特定の呼び出しに対してより厳格な、またはより寛容なポリシーを固定できます。

全てのガードレール決定はリクエストトレースに記録されます。スパンには、発火したフック、統合セレクター、判定、ガードレール呼び出しのレイテンシー、およびPillarによって返された証拠が含まれます。トレースはNATSを通じて非同期に発行され、OTEL経由でチームが設定した任意の可観測性バックエンドへエクスポートされます。Pillarのダッシュボードは、その側から同じイベントを表示し、コンプライアンスレビューのための完全な攻撃トランスクリプトとカテゴリ内訳を提供します。

アーキテクチャの概要

エンドツーエンドのリクエストフローは次のようになります。クライアントはチャット完了またはエージェントリクエストをゲートウェイに送信します。ゲートウェイはキャッシュされたIdPキーに対して呼び出し元を認証し、Virtual Modelルーティングを通じてモデル識別子を解決します。一致するガードレールルールはメモリ内で評価され、モデル呼び出しと同時に、入力ペイロードがPillarにディスパッチされます。Pillarが入力にフラグを立てた場合、モデル呼び出しはキャンセルされ、構造化されたエラーが返されます。入力がクリーンな場合、モデル応答が待機され、配信前にPillarの出力スキャナーに送信されます。エージェントトラフィックの場合も、それがエージェントコンテキストに再入する前に、各MCPツール呼び出し時および各ツール応答時に同じロジックが適用されます。全てのステップは、ガードレール判定が添付されたトレーススパンに記録されます。

アプリケーションで他に何も変更する必要はありません。クライアントにインストールするSDKはなく、エージェントと並行してデプロイするサイドカーもなく、サービスごとのセキュリティミドルウェアを維持する必要もありません。ゲートウェイは既にリクエストパス上にあり、PillarはそのAPIを通じてそのパスに接続します。既存のOpenAI互換クライアントコードは変更なしで動作し続けます。

これをクリーンにするアーキテクチャ原則は、ゲートウェイ層でのポリシー強制の一元化です。モデルトラフィック、ツールトラフィック、MCPトラフィックが全て単一のプロキシに集約されると、そのプロキシで設定されたガードレールは、アプリケーションごとのコードなしで、全てのモデル、全てのチーム、全てのAエージェントに一様に適用されます。Pillarのスキャナーは同じポイントでインラインで実行され、ゲートウェイのフックモデルは、ランタイム決定が実際に重要となる4つの強制ポイントへのアクセスをPillarに許可します。

開始する

について詳しくはこちら TrueFoundry AIゲートウェイ と Pillar SecurityプラットフォームTrueFoundryのガードレール設定でPillarを接続し、モデルまたはMCPサーバーをターゲットとする任意のルールから統合セレクターを参照してください。