AI Agent ガバナンス：書くのではなく構築する5つの柱

エージェントガバナンスが実際に統制するもの

サポートエンジニアの Jane は、サポート copilot に「チケット #4521 の返金サマリーを作成して」と1つの文を入力します。copilot はそれをプランナーエージェントに渡し、プランナーエージェントはリサーチエージェント（Zendesk チケット、リンクされた Jira バグ）とビリングエージェント（Stripe 決済記録）を呼び出します。1つの人間によるリクエストが、6つのマシン間コールに発展し、その大半は自律的に判断したソフトウェアによって別のソフトウェアが呼び出されたものです。

このチェーン — ユーザー → アプリケーション → エージェント → サブエージェント → MCP ツール — が Agentic 呼び出しパス であり、エージェントガバナンスが制御すべき対象です。企業におけるあらゆるアクセスモデルは、次の3つの前提に基づいています：ユーザーがリクエストの先頭にいること、呼び出しを行っている主体がそのユーザー自身であること、そしてスコープがユーザーの同意した範囲内であることです。しかし3ホップ目にはこれら3つすべてが偽となり、結果として次の3つの疑問に答えられなくなります：

• この呼び出しは誰のためのものか？ ユーザーは3ホップ前に認証されました。そのアイデンティティはリクエストにまだ残っているでしょうか、それともサービスアカウントに置き換わってしまったでしょうか？
• 呼び出しを行っているのは誰か？ ベアラートークンはクレデンシャルの所有を証明するだけで、200あるエージェントのどれがそれを保持しているかは証明しません。
• 何を行うことが許可されているか？ 最初の呼び出し先向けに発行されたトークンは、それ以降のすべての呼び出し先に対して過剰な権限（過剰特権）を持つことになります。

すべてのホップでこれら3つすべてに証拠をもって答えること、それが Agentic AI ガバナンス の意味するところです。これは責任ある使用に関するガイドラインではなく、5つのシステムによって実現されます。

エージェントは第3のプリンシパルである

多くのチームは、ユーザーのトークンをエージェントに転送させるか、共有のサービスアカウントを付与するという2つの近道のいずれかを選択しがちです。しかし、エージェントはそのどちらでもないため、どちらのアプローチも誤りです。

各エージェントに独自の検証可能なアイデンティティを付与する設計こそが、すべての基礎となる重要な決定です。これにより、受信側がどのエージェントが呼び出したかを認識できる帰属明確化（Attribution）、Jira を読み取る Jane の copilot とそこに書き込む設計エージェントが、ともに Jane の代理として動作していても別々のプリンシパルとして扱われるエージェントごとのポリシー、そして登録されたアイデンティティ経由でのみアクセス可能なツールによって登録自体を強制ポイントにする匿名エージェントの排除が実現します。

この取り組みの緊迫性は目立ちませんが実在します。多くの企業ではすでにマシンアイデンティティの数が人間のユーザー数を 40:1 以上上回っており、エージェントは過去のサービスアカウント以上のスピードで増殖しています。フレームワークと API キーさえあれば、誰もがエージェントを作成できるからです。

5つの柱

完全なガバナンスは、ループ状に機能する5つの能力で構成されます。最初の2つはエージェントが1回も呼び出しを行う前に実行され、真ん中の2つはすべての呼び出しごとに実行され、最後の1つは継続的に実行されて2番目の柱へとフィードバックされます。

第4の柱は、ガバナンスがネットワーク通信に直接関与する部分です。各ホップにおいて、ゲートウェイは呼び出し元を解決し、このエージェントが対象を呼び出し、かつ対象ユーザーの代理として動作できるかを確認し、次の呼び出し先だけに精密にスコープを絞った新しいトークンを発行し、ガードレールを実行した上で転送と記録を行います。これにより、3つのプロパティが自動的に得られます：ホップごとの帰属明確化、最小権限のトークン（漏洩しても1つの呼び出し先と1つのスコープでしか使えない）、および中央集権的なアクセス取り消し（Revocation）です。

なぜ IdP ではなくゲートウェイなのか

各柱はそれぞれ異なるツールで運用することも可能です。しかし、このモデル全体を統合しているのは、呼び出しパス上のゲートウェイにおけるセキュリティ制御です。ゲートウェイは、フレームワークやクラウドに関わらずすべてのホップを監視し、アイデンティティを伝播させ、各ステップで権限を絞り込み、プラットフォームに依存しない唯一のコンポーネントだからです。Entra は Entra エージェントを統制し、Okta は Okta アプリを統制し、Bedrock は Bedrock エージェントを統制しますが、ゲートウェイはそれらすべてをまたぐ呼び出しパス全体を統制します。リスクが存在するのはまさにこのクロスプラットフォームの部分です。この点については マルチプラットフォームにわたる AI Agent のガバナンス で詳しく解説しています。ゲートウェイを持たない ID プロバイダーは無秩序に転送されるだけの完璧なクレデンシャルを発行するに過ぎず、ゲートウェイを持たないレジストリは単なるドキュメントに過ぎません。

間違いやすいポイント

レジストリを単なるスプレッドシートとして扱う。 エージェントがバイパスできるレジストリは、既に把握しているエージェントの目録を作成するだけです。レジストリが真の強制力を持つのは、それがボトルネックとして機能するときです。つまり「登録されたアイデンティティがなければ、呼び出しもできない」という状態です。

強力な1つのトークンをあらゆる場所に転送する。 これは呼び出しを短時間で正常動作させる最も手軽な方法ですが、セキュリティ侵害への最も早い近道でもあります。エージェントはプロンプトインジェクションによって保持しているクレデンシャルを悪用するよう誘導される可能性があるため、トークンの権限は次の呼び出しで必要な最小限にとどめる必要があります。

チェーン全体ではなくアカウント単体をレビューする。 調達フローに存在する3つのエージェント（1つはベンダー記録を作成、1つは仕入先の口座データを読み取り、1つは支払を実行）は、個別に見れば問題ないように見えます。しかし、これらがチェーン状に連結されると、いかなるレビュー担当者も承認しなかったような支払いパスが形成されてしまいます。ソフトウェアによって分離されていたはずの職務分掌が崩壊してしまうのです。

エージェントのスコープは固定であると前提する。 新しい ERP モジュールへのアクセスを許可された財務エージェントは、不具合からではなく、環境に適応しようとするエージェント本来の性質によって、本来のスコープに含まれていなかったデータに対してアクションを開始する可能性があります。エージェントの振る舞いは、四半期ごとのレビューではなく、定義された権限と常時比較・検証されなければなりません。

図のままで終わらせず、稼働するシステムとして構築しませんか？

エージェントを登録し、アイデンティティを付与して、1つの MCP サーバーへのアクセスを許可してみましょう。

無料で試してみる

難所：「これを行ったのは誰か？」という問いに対する2つの答え

リサーチエージェントが Jane の Jira イシューを読み取るとき、誰がこれを行ったのかという問いに対する正確な答えは、Jane と リサーチエージェント の両方です。どちらか一方でも落としてしまうと、決定的な情報が失われます。トークンにこの両方の情報を保持する方法は2つあり、どちらを選択するかによって監査トレイルの有効性が決まります。

エージェントの場合、ほぼ常に委任（Delegation）のアプローチが必要になります。委任トークンはユーザーを sub に保持しつつ、実際に動作している主体を act に記録します。呼び出しが連鎖する場合、クレームはネストされ、最も外側が最新のアクティブな主体となります：

役割を分割するために2つの対となるクレームが用意されています。may_act は事前チェックのためのゲートであり（この主体は該当のサブジェクトの代理として動作できるか）、トークンが発行される前に検証されます。act は実際に誰が実行したかを記録します。認可（Authorization）は、現在のアクター、サブジェクト、およびポリシーに基づいて行い、ネストされたチェーン全体はフォレンジック調査のために保持されます。

これを支える基礎メカニズムが トークン交換（Token Exchange） です。RFC 8693 では次のように定義されています：サブジェクトトークンと、オプションでアサートされたアクタートークンを提示し、対象となるオーディエンスにスコープを限定した新しいトークンを受け取ります。ベンダーによってはこれを「On-Behalf-Of（OBO）」と呼びます。覚えておくべき重要な特性は、「トークン交換によって権限が拡大されることは決してない」ということです。発行されるトークンは、「ユーザーができること」「エージェントができること」「対象が許可すること」の積集合（共通部分）の権限しか付与しないため、ホップを重ねるごとに制限は厳しくなります。信頼ドメインをまたぐ場合は、IETF の ID-JAG トラストグラント（Okta の Cross App Access）が引き継ぎ、IdP で短命なグラントを発行して対象の認可サーバーがそれを検証・引き換えます。

TrueFoundry での仕組み

TrueFoundry は、これら5つの柱を実際の製品機能へとマッピングしています。機能の対応関係を正確に提示するため、各機能の提供状況を明確に示しています。

レジストリ（Registry）

動作環境（Bedrock、Vertex、LangGraph、カスタム HTTP サービス、A2A エージェント、サードパーティ SaaS 内の copilot など）に関わらず、すべてのエージェントがエントリを持ちます。既存の環境を変更したり書き直したりする必要はありません。

登録は 4 ステップのウィザードで完了します：メタデータ、Agent Identity、設定、アクセス制御。

アイデンティティ（Identity）

ステップ 2 では、エージェントが自身を証明する方法を選択します。TrueFoundry-backed は TrueFoundry がトークンを発行・署名する方式で、自社で運用するエージェントのデフォルトに適しています。Identity provider-backed は、Okta、Entra、各種 OIDC プロバイダー、または SPIFFE/SPIRE エンドポイントから発行されたトークンをエージェントが提示し、クレーム値をエージェントにマッピングする方式です。

設定ステップでは、Agent Gateway を前面に配置するかどうかを決定します。Proxy via Gateway を選択すると、呼び出し元は TrueFoundry の URL にアクセスし、ゲートウェイが認証・制御・転送を行います。Embedded はガバナンス専用の設定で、インバウンドのプロキシ処理を行わずにアイデンティティと権限管理のみを適用します。これはサードパーティ製品内の copilot を管理するためのアプローチです。フロントドア自体を制御することはできなくても、そのエージェントからのアウトバウンド呼び出しは自社のゲートウェイを通過させることができます。

エージェントのアクセス制御（Access Control）

アクセス制御は許可リスト（Allow-list）に基づいています。明示的な拒否（Deny）設定は存在せず、設定の欠落自体が拒否を意味します。コラボレーターにはユーザー、チーム、または 別のエージェント を指定でき、役割として Agent Manager（閲覧および編集）または Agent Access（実行、およびその代理としての動作許可）を割り当てます。所有者（Owner）は別途設定可能なオプション項目で、責任追及のアンカーとなるチームを指定する必要があります。

この1つのリストが果たす役割に注目してください。誰がエージェントを呼び出せるかと同時に、エージェントが誰の代理として動作できるかの両方を定義しています。組み込みの everyone チームに権限を付与すると、エージェントにテナント全体に及ぶ代理権限を与えることになります。これは大半のエージェントが必要とする以上の過剰な権限です。

逆方向の設定も同様に行えます。各 MCP サーバーやモデルのコラボレーターとして、ユーザーやチームと同じ選択画面から subject agent:<name> の形式でエージェントを追加します。

エージェントによるツール利用をサーバー内の一部に制限したい場合は、そのサブセットを Virtual MCP Server として整理し、そちらへのアクセス権を付与します。なお、グラント単位でのエージェントごとツールスコープ制限機能は近日公開予定です。

あらゆるホップでのガードレール

アクセス制御は呼び出しの実行可否を判断します。ガードレールは呼び出しに何が含まれるかを判断し、呼び出し元のアイデンティティには依存しません。エージェントにおいてガードレールの重要性が増すのは、不適切な回答を返すチャットボットは企業の評判を傷つけるにとどまりますが、不適切な回答を出力したエージェントはそれを基に実際のアクションを実行してしまうためです。ツールの実行結果はすべてモデルのコンテキストに再度投入されるため、インジェクションが含まれる可能性があります。そのため、信頼できるユーザーからの入力であってもチェックが必要です。

推奨されるベースライン構成：LLM 入力に対する PII（個人識別情報）のマスキングとプロンプトインジェクション検知、出力に対するシークレット検知、ツール実行前の SQL サニタイザーとコード安全性のリンター、ツール実行後のマスキング。最初はすべてのルールを Audit（監査） モードで運用開始し、安全性を確認してからブロックモードへ昇格させてください。1つのホップでブロックが発生すると、チェーン全体が失敗する可能性があるためです。

監査（Audit）

セキュリティ強制とログ観測が同じ場所で行われるため、監査トレイルは構造上、漏れなく記録されます。各トレースには、呼び出しを行ったエージェントと、それが代理したユーザーの両方が記録されます。「誰がやったのか」という二重の回答構造を持つ課題への解決策となります。

実行されたすべてのガードレールは、個別のスパンとして表示されます：チェック内容、合格したか否か、検知またはマスキングされたデータ。拒否されたリクエストも同様に記録されます。アクセス拒否されたホップは追跡データの欠損ではなく、拒否を示す証拠ログとして残ります。

個別のトレースの上位として、1つのダッシュボードが動作場所を問わず登録されたすべてのエージェントを網羅します：リクエスト数、レイテンシーのパーセンタイル、エラー率、時間経過に伴う使用状況。これらをベースにしたドリフト検知や異常アラート機能は近日公開予定です。

具体的な構築例

冒頭で紹介した「返金サマリー作成 copilot」を対象に、ガバナンスを設定する手順を解説します。

エージェントを登録する。 プランナー、リサーチ、ビリングの各エージェントにエントリを作成し、説明と Owner チームを設定します。サードパーティ製 copilot は Embedded として登録します。URL のプロキシ制御は行いませんが、そこからのアウトバウンド呼び出しはガバナンスの統制下に入ります。

それぞれにアイデンティティを付与する。 自社で運用する3つのエージェントには TrueFoundry-backed を設定し、Embedded copilot には IdP を指定してクレーム値をマッピングします。

双方向に最小権限を付与する。 リサーチエージェントに対し、サポートチームに Agent Access 権限（呼び出し権限および代理動作の許可）を付与します。次に、Zendesk および Jira MCP サーバーのコラボレーターとして agent:research-agent のみを追加します。ビリングエージェントには Stripe MCP サーバーへの権限を付与します。権限が明示的に付与されていない場合アクセスは 403 拒否となるため、どちらのエージェントも互いのツールにアクセスすることはできません。

すべての呼び出しでアイデンティティを伝播させる。 委任された呼び出しには2つのベアラートークンが含まれます：Authorization ヘッダーのユーザー情報と、x-tfy-agent-authorization のエージェント情報です。各エージェントは自身のエージェントヘッダーを付与しつつ、ユーザーのトークンを通過させます。これにより、ゲートウェイは実際に呼び出しを行っているエージェントに対してすべてのホップで検査を実施できます。

ガードレールを有効化し、モニタリングを開始する。 モデルにプロンプトインジェクション検知を、サーバーにツール実行後のマスキング処理を設定します。その後、Request Traces でリサーチエージェントの呼び出しを確認し、呼び出し元が research-agent、代理されたユーザーが Jane として正確に記録されていることを検証します。

現在の技術的な制限事項：現時点では、ユーザーのトークンはホップごとに新たなオーディエンススコープ付きトークンへと交換されるのではなく、エージェントヘッダーとともにそのまま通過する仕様になっています。完全なホップごとのトークン交換機能は近日公開予定です。

実効性のあるアクセス制御ポイントへエージェントを導入する準備はできましたか？

エージェントを登録し、1つの MCP サーバーにスコープを絞り、トレースログを確認してみましょう。

TrueFoundry を無料で試す

知っておくべきハマりどころ

エージェントは OAuth2 authorization-code フローを完了できません。 同意画面を承認する人間が存在せず、発行されるトークンも本来その個人のものになってしまうためです。そのようなサーバーは、エージェントがコラボレーターとして登録されていても、エージェントトークンに対して MCP server authentication required を返します。代わりに Client Credentials フローを使用してください。

ストリーミング出力では出力ガードレールがスキップされます。 ガードレールの評価には応答全体の完了が必要となるためです。後続のツール呼び出しに入力されるエージェントステップの出力については、stream: false の使用を推奨します。

エージェントのトークンはエージェントそのものです。 ソースコード管理システムや、モデルが読み取れるコンテキスト内には絶対に含めないでください。自身のトークンを露出するように誘導されたエージェントは、悪意のある第三者によってなりすまされるリスクが生じます。

関連記事

• マルチプラットフォームにわたる AI Agent のガバナンス — プラットフォームの境界でガバナンスが中断する場合の対処法
• AI Agent のためのグラフエンジニアリング — ノードの評価とエッジの統制の違い
• MCP ゲートウェイによる MCP アクセス制御 — ツールおよびサーバーレベルでのパーミッション設定
• AI Agent における RBAC と ABAC の比較 — グラント管理の裏にあるアクセスモデル
• AI ガバナンスフレームワークの構築 — より広い視点からのポリシー策定

結論

エンタープライズ AI agent 管理 に関する多くの解説文は、ガバナンスを単なるルール策定作業として扱っています。許容される利用ポリシーを定義し、委員会を設置し、標準ガイドラインを公開するといった具合です。しかし、そのようなアプローチは呼び出しパスの3ホップ目には役に立たなくなります。そこでは、実行されたアクションが適切だったかどうかではなく、「インフラストラクチャが実行主体のアイデンティティを証明できるかどうか」が問われるためです。

本稿で提示した5つの柱が有用である理由は、それぞれが理念ではなく具体のシステムを指し示しているからです。「発見」はスキャナーであり、「登録」はゲートウェイによるバイパスを許さないデータベースです。「認証」はリクエストに含まれる2つのクレデンシャルであり、「認可」は非存在時に 403 を返すアクセス許可です。「監査」はエージェントとユーザーの両方を記録したトレースログです。これらを構築することで初めて、「誰が、誰の代理としてこれを行ったのか？」という重要な問いに対し、システムとして明確な答えを示すことが可能になります。

TrueFoundry で最初のエージェントのガバナンスを開始する

無料で始める