Traefik Labsは、Traefik Hub内に検証可能な証跡をAIエージェントガバナンスにもたらす一連の機能「Sovereign Trust Plane(STP)」を発表しました。一般提供開始は2026年9月30日を予定しています。STPは、モデル・ツール・APIトラフィック全体にわたって、委任アクセス、ポリシー適用、そしてゲートウェイが何を許可し何を拒否したかの保護された記録を連携させます。
エージェントが返金処理を行ったり、顧客データにアクセスしたり、business recordを変更したりするようになると、説明責任の範囲はプラットフォームを運用するチームだけにとどまらなくなります。セキュリティ責任者はエージェントがどの権限を託されていたのかを説明しなければならず、リスク・コンプライアンスチームは統制が機能していたことを示さなければならず、プロダクトチームは状況が変化した後になってから下された判断を調査しなければなりません。
STPはこれら3つの責務を軸に設計されています。
CISOにとっては、独立したレビューに耐え得る説明責任です。エージェントが資金を動かした際、CISOはプラットフォームチームに履歴の断片をつなぎ合わせてもらうことなく、誰がそれを承認し、どのポリシーが適用されたのかを突き止める必要があります。STPは委任・実施・記録の完全性を単一のアーキテクチャに統合します。個別に管理される「witness(証人)」機能により、そのチーム以外の第三者が、これまで証跡として記録されてきた履歴が書き換えられたり短縮されたりしていないことを検証できます。
リスク・コンプライアンスチームにとっては、統制が何を防いだかという証拠です。統制が機能していたかどうかを評価する上では、拒否されたアクションも完了したアクションと同じくらい重要です。STPは記録された承認・拒否を、検知されない改ざんから保護します。この記録には、判断内容、その判断を導いたポリシー、そして行動した人物とエージェントの双方が含まれます。証跡の取得経路はインシデントのテレメトリとは別系統になっているため、監査記録がサンプリングされることはありません。
プロダクトチームおよびエージェントチームにとっては、何が起きたかを理解するための基盤です。不適切な行動を調査するには、その時点で記録されたリクエストと関連コンテキストが必要です。今日の設定情報だけでは、昨日下された判断を説明することはできません。STPはゲートウェイの記録をトレースに連携させ、エージェントによるツール呼び出しだけでなく、資金移動やデータ変更が実際に発生するバックエンドAPIへのツールの呼び出しにも実施範囲を広げます。アプリケーション側の記録が、完全な調査に必要なビジネス上の結果を提供します。
「監査担当者は、私たちの言葉を鵜呑みにすることなく記録を検証できるべきです」と、Traefik Labsの創業者兼CTOであるEmile Vauge氏は述べています。「独立したwitnessがあれば、たとえ運用者がログとその署名鍵を管理していたとしても、書き換えられた履歴に異議を唱える手段が得られます」
委任する。承認する。証明する。
STPは、これら3つの機能を通じてこれらの責務を統合します。
- Delegate(委任)：組織のIDプロバイダーを通じて認証情報をやり取りし、目的のリソースへのアクセス権を取得します。これはOktaのCross App Accessの基盤となる草案仕様である、IETFのIdentity Assertion JWT Authorization Grant(ID-JAG)を実装したものです。IDプロバイダーが発行する権限を管理するため、組織は業務がシステムをまたぐ際に委任される権限を制限できます。このアサーションには人物とエージェントの両方が明示されるため、エージェントに与えられる権限は、それが代理する人物の権限よりも厳密に狭い範囲に限定できます。
- Authorize(承認)：特定のAPIリクエストやModel Context Protocol(MCP)のツール呼び出しが許可されているかどうかを組織のポリシーエンジンに問い合わせ、転送する前にその回答を適用します。OpenIDのAuthZENインターフェースにより、各チームは独自のポリシーと判断ロジックを維持したまま、互換性のあるポリシーエンジンを接続できます。
- Prove(証明)：ゲートウェイログとアクセスログの暗号学的フィンガープリントを透明性ログにコミットします。検証者は、保持されている記録をこれらのコミットメントおよび署名付きチェックポイントと突き合わせて確認するため、元のログ内容が顧客管理下のストレージに留まったまま、改ざんを検知可能にします。
Traefik Labsは、RFC 8693に続きRFC 7523という流れで、OktaのCross App Accessおよび自己ホスト可能なJanssen Auth Serverを用いて、このやり取りをエンドツーエンドで検証済みです。これにより、クラウドのIDサービスを経由することなく連鎖を完結させることができます。また、ゲートウェイに組み込まれたAuthZENミドルウェアを通じて、OpenFGAおよびCerbosによる実施の検証も行っています。
Traefik Hubは、API・AI・MCPの各ゲートウェイ機能を単一のランタイムに統合しており、実施が必要な場所であればどこにでも展開可能です。そして、MCPサーバーからそのバックエンドへの接続という見落とされがちな部分も含め、モデル・ツール・APIパスの全体にわたってビジネス上の制約を適用します。バックエンドは引き続き、トランザクションの正確性に対して責任を負います。
1回の記録取得が複数の用途に活用されます。同じログ行が、セキュリティチームのSIEMと証跡記録の両方に供給される一方、トレースとメトリクスはインシデント対応を支援します。
顧客の管理下での検証
署名付きログだけでは、次のような難しい疑問が残ります。運用者は最近のエントリを破棄し、別の履歴に署名し直すことができてしまうのではないか、という疑問です。独立したwitnessは、チェックポイントを保持し、それ以降のすべてのチェックポイントが、自身がすでに受け入れた履歴を延長するものであることを確認することで、この疑問に答えます。レビュー担当者は、記録を検証する際にwitnessの署名を要求し、鮮度を確認することができます。
witnessは、基となるリクエストやログの内容自体を伴わない、暗号学的なチェックポイントと証明のみを受け取ります。組織は、プライベートネットワークやエアギャップ環境内も含め、別個の管理体制と鍵管理の下で、これを別のリスクチームや監査担当者の管理下に置くことができます。
ゲートウェイ、証跡ストレージ、検証者は、顧客が選択したIDサービスおよびポリシーサービスとともに、顧客が管理するインフラ上で稼働します。オフライン展開オプションは、リクエスト経路上にSaaS型のコントロールプレーンを置かずにガバナンスを運用しなければならない環境をサポートします。
「エンタープライズAIの真の試金石は、重要な業務をAIに任せられるかどうかです」と、Traefik LabsのCEOであるSudeep Goswami氏は述べています。「そのためには、明確な制限、何か問題が起きた際の説明責任、そして人々が検証できる証跡が必要です。私たちは、企業がこうした基盤を最初から整えた上で、エージェントを業務に活用できるようにしたいと考えています」
翻訳元: https://www.helpnetsecurity.com/2026/09/15/traefik-labs-sovereign-trust-plane/
