AktoがTrueFoundryと提携し、AIエージェントにセキュリティガードレールを提供

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support

Aktoとの提携を発表できることを嬉しく思います。これにより、AIエージェントのトラフィック経路に直接ランタイムセキュリティが導入されます。
TrueFoundryのAIゲートウェイを介してエージェントトラフィックをルーティングするチームは、Akto Argusをファーストクラスのガードレールソリューションとして接続できるようになりました。これにより、本番環境におけるプロンプト、応答、ツール呼び出し、エージェントワークフロー全体で、リアルタイムの可視性、ポリシー適用、ランタイム保護を実現できます。
より多くのチームが、単一のLLM呼び出しから、ツールを呼び出し、MCPサーバーに接続し、実際のシステムで動作するAIエージェントへと移行するにつれて、本番環境での準備には、2つの要素が連携して機能することが必要となります。
- エージェントトラフィックをデプロイ、ルーティング、管理するための信頼できる方法
- それらのエージェントがランタイムで何をするかを監視、制御、保護するための信頼できる方法
それこそが TrueFoundryとAktoの 提携が提供するものです。
エンタープライズ向けエージェントAIに2つのレイヤー(ゲートウェイとランタイムセキュリティ)が必要な理由
TrueFoundry は、本番AIシステムの制御レイヤーを提供します。AIゲートウェイを使用すると、チームはLLMトラフィックをプロキシレイヤー経由でルーティングし、LLM、ツール、MCP接続ワークフロー全体で、モデルルーティング、キー管理、アクセス制御、可観測性、ガバナンスを一元化できます。
Akto は、AIエージェント、MCPインタラクション、およびLLM搭載アプリケーション向けのランタイムセキュリティレイヤーを提供します。Akto Argusを使用すると、チームはエージェントのプロンプト、応答、ツール呼び出し、およびエージェントアクションにガードレールを適用し、プロンプトインジェクション、データ漏洩、安全でない出力、危険なエージェントの動作などの問題を発生時に検出し、対応できます。
これら2つのソリューションが連携することで、エンタープライズAI向けのクリーンな本番アーキテクチャを構築します。
- TrueFoundryはデプロイ、ルーティング、運用制御を担います
- Aktoはランタイム検査、AIリスク評価、ガードレールポリシーの適用を担います
この組み合わせにより、 エンタープライズ対応のエージェントAIシステムを 個々のエージェントやサービスにセキュリティロジックを組み込むことなく実行することが容易になります。TrueFoundryゲートウェイ内ではAktoガードレールに対するファーストクラスのサポートを提供しており、以下のフックをサポートしています。 beforeRequestHook, afterRequestHook, mcpPreTool, mcpPostTool

本番エージェントのデプロイにおける課題
AIエージェントを構築するほとんどのチームは、デプロイと信頼性に労力の大部分を費やしています。具体的には、エージェントが適切なツールを呼び出し、コンテキストを正しく管理し、リトライを処理し、ユーザーや環境全体でスケールさせることです。このアプローチは必要不可欠ですが、それだけでは十分ではありません。
多くのエージェント型AIデプロイにおけるセキュリティは、依然として境界レベルに留まっています。具体的には、プラットフォームのアクセス制御、MCPサーバーの許可リスト、ツールレベルの権限、ダウンストリームシステム用のスコープ付き認証情報、モデルルーティングポリシーなどです。
これらの制御は重要ですが、ランタイムにおける最も重要な問いには答えられません。
- エージェントは実行を開始すると、実際に何をしているのでしょうか?
- どのツールを、どのような順序で、どのようなデータを使って呼び出しているのでしょうか?
- 意図されたスコープ外のリソースにアクセスしていないでしょうか?
- 取得されたコンテキスト、MCPサーバー、または外部API応答を介してプロンプトインジェクションが入り込んだ場合、エージェントが動作する前にそれを阻止するものはあるのでしょうか?
AIエージェントのためのランタイムガードレール
この技術提携の背後にある主要なアーキテクチャのアイデアはシンプルです。すべてのモデル、ツール、およびMCPトラフィックがすでにゲートウェイを通過している場合、そこがランタイムセキュリティを適用するのに最適な場所となります。

Akto が TrueFoundry AI Gatewayと接続されることで、チームは ランタイムガードレールを エージェントトラフィックがすでにルーティングされ、管理されているのと同じパスで適用できます。これにより、チームは実行後にトレースをレビューするだけでなく、ライブのAIトラフィックを評価および制御できるようになります。
AktoはあなたのAIゲートウェイにどのようにセキュリティレイヤーを追加するのでしょうか?
Akto Argus は、AIエージェント、MCP接続ワークフロー、LLM搭載アプリケーション向けのランタイムセキュリティレイヤーです。
Aktoは ランタイムガードレール を本番環境で発生するインタラクションに適用し、チームがエージェントの動作をリアルタイムで監視、評価し、ポリシーを適用できるようにします。

Aktoの AIガードレール を有効にすると、チームは次のような制御を適用できます。
- プロンプト攻撃からの保護 プロンプトインジェクションやジェイルブレイクの試みを検知・ブロックするため
- 機密データ保護 PII、シークレット、認証情報、トークン、内部コンテキストを特定し、編集するため
- 出力フィルタリング 安全でない応答やポリシー違反の応答がダウンストリームシステムやエンドユーザーに到達する前に捕捉するため
- 行動異常検知 異常なツール使用、パターン外のワークフロー、または予期される範囲外のアクションを明らかにするため
- ポリシー適用 セキュリティチームとプラットフォームチームが、エージェントコードを再構築することなく、リスクのあるインタラクションを許可、編集、ブロック、またはフラグ付けできるようにするため
エージェントシステムの場合、Aktoは単一のプロンプト/応答ペアを超えて機能します。Aktoは以下を評価するように構築されています。 ツール呼び出し、MCPリクエスト、および多段階実行コンテキスト なぜなら、エージェントAIにおける多くの実際の障害は、単一のモデル応答で発生するわけではないからです。それらはアクションの連鎖全体で現れます。
技術提携はどのように機能しますか?
TrueFoundry AI Gatewayは、ガードレールルールの設定でYAMLフィールドとして宣言された4つの個別のフックを通じてAktoのガードレールを適用します。各フックはリクエストのライフサイクルにおける特定の適用ポイントに対応しており、エージェントコードの変更は必要ありません。
llm_input_guardrails モデルに到達する前にプロンプトを傍受します。ゲートウェイはまずリクエストをAkto Argusに送信し、違反が検出された場合はリクエストがブロックされ、LLMは呼び出されません。これは厳格な適用ポイントであり、Aktoが入力のクリアを承認するまでモデル呼び出しは進行しません。
llm_output_guardrails LLMが応答した後、その応答がダウンストリームに配信される前に発動します。このフックはノンブロッキングであり、Aktoが安全でない出力、データ漏洩、またはポリシー違反について非同期で評価している間も、ユーザーはすぐに応答を受け取ります。結果はコンプライアンスレビューのためにAktoダッシュボードに表示されます。
mcp_tool_pre_invoke_guardrails エージェントによってツールが実行される前に発動します。この時点でAktoはツール名、その引数、および呼び出しコンテキストを評価します。引数に機密データが含まれている場合、または範囲外のリソースアクセスを示している場合、実際の行動が発生する前にツール呼び出しをブロックできます。
mcp_tool_post_invoke_guardrails ツールが結果を返した後、その結果がエージェントに渡される前に発動します。これは、資格情報、PII、またはMCPサーバーによって返された内部コンテキストなどがエージェントの推論ループに入る前に、ツール出力におけるデータ漏洩を検出するための適用ポイントです。
ルールはゲートウェイでYAML rules ブロックを介して設定されます。各ルールは when ブロックを使用し、2つの条件があります。 target (一致する対象は model、 mcpServers、 mcpTools、またはリクエスト メタデータ)と 主体 (ユーザーまたはチームのIDと、 in および not_in 演算子を使用して照合します)。リクエストに一致するすべてのルールはまとめて評価され、それらのガードレールセットは フックごとに統合されます — 2つのルールが両方とも llm_input_guardrailsをターゲットとする場合、両方のガードレールが実行されます。チームは、グローバル設定を変更することなく、リクエストごとにガードレールをオーバーライドすることもできます。そのためには、 X-TFY-GUARDRAILS JSONヘッダーを渡して、4つのフックの任意の組み合わせに対してガードレールセレクターを指定します。

Akto Argusコネクタは、TrueFoundryのAIゲートウェイ層内に配置されます。一度設定されると、AIゲートウェイを通過するすべてのエージェントインタラクションとLLM呼び出しはArgusによって監視されます。エージェントコードレベルでの計測は不要です。これにより、チームは実用的な展開パスを得られます。 確信度が高い場合はブロックし、可視性が優先される場合は監視する。

本番環境のエージェントAIシステム向けに構築
この提携は、エージェントのトラフィックがすでにルーティングされ、管理されているのと同じ経路にセキュリティが存在すべきであるというシンプルな考えに基づいています。
TrueFoundry AI Gatewayをモデル、ツール、MCPトラフィックのコントロールプレーンとして、Akto Argusをその経路にアタッチされたランタイムセキュリティレイヤーとして活用することで、チームはエージェントごとのセキュリティロジックを追加したり、アプリケーションの構築方法を変更したりすることなく、エンタープライズAI向けの実用的な本番アーキテクチャを実現できます。
お客様にとって、それは次のことを意味します。
- AIトラフィックとランタイムポリシー適用の一元的な制御
- プロンプト、応答、ツール、MCPインタラクション全体にわたる一貫したセキュリティカバレッジ
- 監視からブロックまでの明確な経路により、ガードレールをより迅速に展開
- プラットフォーム、セキュリティ、エンジニアリングチーム向けの共有された可視性
より多くのチームがシンプルなLLM統合から真のエージェントシステムへと移行するにつれて、この種のアーキテクチャはオプションのアドオンではなく、基本的な要件となります。
準備はできましたか?次の資料をご覧ください。 TrueFoundry向けAktoコネクタドキュメント および TrueFoundryのAI Gatewayドキュメント を参照してAkto Guardrailsをセットアップしてください。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.














.webp)
.webp)


.png)

.png)














