AI API ゲートウェイを介したエージェント ツール ガバナンス: スコープ、承認、予算、監査証跡

エージェントのリスクはモデル プロンプトに限定されなくなりました。運用エージェントは、内部ファイルの検索、顧客レコードのクエリ、MCP サーバーの呼び出し、コードの実行、ブラウザの起動、電子メールの送信、CRM の更新、または請求ワークフローのトリガーを行うことができます。ガバナンスの問題は次のようになります。どのユーザー、キー、モデル、エージェント、ツールが、どのような予算、監査証跡、ロールバック パスでどのアクションを実行できるようになったのか?

すべてのチームが独自の SDK コード内でツール アクセスを処理すると、ポリシーが環境変数、プロバイダー ダッシュボード、アプリケーション ミドルウェア、および文書化されていない MCP サーバーに分散されてしまいます。より安全なパターンは、エージェント ツールの実行をコントロール プレーンの問題として扱い、AI API ゲートウェイまたはすべてのエージェントが使用する必要がある標準のツール実行ラッパーを通じて強制することです。

この記事は事実、推奨事項、予測に分けて説明します。事実は現在の公開ガイダンスから導き出されています。OWASP の LLM アプリケーション トップ 10 には、機密情報の開示、サプライ チェーンの脆弱性、過剰な代理店などのリスクが含まれています。 AI リスク管理フレームワークに関する NIST の生成 AI プロファイルは、生成 AI リスクのマッピング、測定、管理に重点を置いています。 OpenAI のエージェント ガイダンスでは、読み取り/書き込みアクセス、可逆性、権限、財務上の影響によってツールのリスクを評価することを推奨しています。 MCP 認可ガイダンスでは、機密性の高いリソースと操作に対して範囲指定された認可コンセプトが使用されます。以下の推奨事項は実装パターンであり、普遍的な要件ではありません。

リーダーの問題: モデルへのアクセスとツールへのアクセスが混同されています

多くの初期の LLM アプリケーションでは、API キーが 1 つの基本的な質問に答えていました。「このサービスはモデルを呼び出すことができますか?」エージェントはそれを大雑把にしすぎます。チャット完了を送信できるキーは、顧客データのエクスポート、シェル コマンドの実行、Slack への投稿、チケットの変更、任意の Web サイトの閲覧、支払い変更の送信を自動的に実行できてはなりません。

ガバナンス層は、より具体的な質問に答える必要があります:

• 実行を開始したのはどのテナント、ワークスペース、ユーザー、サービス アカウント、または販売代理店の顧客ですか?
• どのモデル、プロンプト テンプレート、エージェント バージョン、ツール スキーマが使用されましたか?
• 要求されたツールは読み取り専用、可逆的、不可逆的、外部向け、財務的、または特権的でしたか?
• リクエスタは必要なスコープを持っていましたか?
• 承認は必要でしたか、承認されましたか、拒否されましたか、期限切れになりましたか、または緊急ポリシーによって回避されましたか?
• ツールの費用はいくらで、何回呼び出され、残りの累積予算はいくらですか?
• デバッグ、コンプライアンス レビュー、ロールバックにはどのような証拠がありますか?

以下のアーキテクチャは、ゲートウェイがすでにモデル呼び出しを受信していることを前提としています。ツールの実行は、同じゲートウェイ、サイドカー サービス、またはツール呼び出しの前後にゲートウェイにレポートする標準ライブラリを通じてルーティングできます。

リファレンス アーキテクチャ: ゲートウェイ レベルのツール ガバナンス層

実際のエージェント ガバナンス システムには 7 つのコンポーネントがあります:

1. ツール レジストリ: 承認されたツール、MCP サーバー、ホストされた機能、ローカル実行ツール、および内部 API の信頼できるリスト。
2. ID とキー レイヤ: ゲートウェイ キー、ユーザー、テナント、サービス アカウント、チーム、および再販業者の顧客。
3. スコープ エンジン: キーまたはユーザーが特定のツール機能を呼び出せるかどうかを決定するポリシー チェック。
4. リスク分類子: 爆発範囲、データの機密性、可逆性、外部への影響、および費用負担を説明するメタデータ。
5. 承認ワークフロー: リスクの高いアクションについては、実行前に人間またはシステムが承認します。
6. 予算およびレート制限台帳: モデルごとのトークン制限だけでなく、ツールごとおよびエージェントごとの制限。
7. 監査およびトレース ストア: モデル呼び出し、ツール呼び出し、承認、エラー、結果の結合レコード。

設計上の重要な決定は、実際のツールが他の場所で実行されている場合でも、ゲートウェイをポリシー決定ポイントにすることです。たとえば、ブラウザ ツールはサンドボックス ワーカーで実行でき、CRM 書き込みは内部サービス内で実行できます。ゲートウェイは引き続き、呼び出しが許可されるかどうかを評価し、決定を記録し、コストを追跡し、署名された承認決定または拒否を返します。

ステップ 1: 中央ツール レジストリを構築する

ツール レジストリは、「不明なエージェント機能」がデフォルトになることを防ぐインベントリです。各ツールには、所有者、リスク層、運用メタデータが必要です。最小限のレジストリ レコードは次のようになります:

{
  "tool_id": "crm.create_ticket",
  "display_name": "Create CRM support ticket",
  "owner_team": "support-automation",
  "execution_type": "internal_api",
  "server_url": "https://tools.internal.example/crm",
  "allowed_tenants": ["enterprise", "support"],
  "allowed_models": ["general-large", "general-fast"],
  "risk_tier": "reversible_write",
  "data_classification": "customer_metadata",
  "required_scopes": ["tool:crm.create_ticket"],
  "approval_policy": "not_required_under_100_tickets_per_day",
  "default_timeout_ms": 8000,
  "max_cost_per_call_usd": 0.05,
  "max_calls_per_run": 3,
  "rollback_owner": "support-ops-oncall",
  "retention_policy": "redacted_30_days"
}

MCP サーバーの場合、レジストリには、サーバー URL、アドバタイズされたツール、スキーマ バージョン、認証方法、最終レビュー日、および新しいツールがデフォルトで無効になっているかどうかも含める必要があります。 MCP は相互運用性を向上させますが、プロトコルの互換性は実稼働認証と同じではありません。機密性の高いリソースと操作には、依然として明示的なスコープ、ルート チェック、テナントの分離が必要です。

推奨されるレジストリ フィールド

• ツール名、正規 ID、所有者、およびオンコール連絡先。
• 実行場所: ホストされたプロバイダー ツール、MCP サーバー、内部 API、ブラウザー ワーカー、コード ランナー、キュー ジョブ、またはローカル SDK ツール。
• 許可されたテナント、チーム、ユーザー、エージェントのバージョン、およびモデル プロファイル。
• データ分類: 公開データ、内部データ、顧客メタデータ、顧客コンテンツ、機密情報、支払いデータ、認証情報、規制データ。
• リスク階層と可逆性。
• 必要なスコープと承認ポリシー。
• タイムアウト、レート制限、実行あたりの最大コール数、累積実行バジェット、およびコールあたりの最大コスト。
• ロギング モード: 完全なペイロードは禁止、編集、ハッシュ化、サンプリング、または明示的に保持されます。
• ロールバック手順とエスカレーション パス。

ステップ 2: モデル スコープをツール スコープから分離する

運用ゲートウェイ キーは、呼び出し元が実行できる内容を表現する必要があります。モデルへのアクセスとツールへのアクセスは独立している必要があります。例:

model:chat
model:embeddings
tool:docs.search_readonly
tool:crm.create_ticket
tool:email.send_requires_approval
tool:billing.refund_blocked
tool:code.execute_blocked

これにより、リスクの低いチャットボットが誤って自動化エージェントになるのを防ぎます。ロール テンプレートもサポートしています:

• 開発者アシスタント: モデル チャット、ドキュメント検索、コードの説明、本番用の書き込みツールはありません。
• サポート ボット: 顧客の検索、チケットの作成、返信の下書き、外部送信には承認が必要です。
• アナリスト エージェント: 行制限のある読み取り専用データ ウェアハウス クエリ。デフォルトでは顧客によるエクスポートはありません。
• 管理エージェント: 限定的な特権操作、強力な承認、有効期間の短いキー、完全な監査。
• 再販業者テナント エージェント: テナント スコープのモデル アクセス、テナント スコープのツール、顧客ごとの予算上限。

フェールクローズすることをお勧めします。不明なツールは拒否され、スコープが欠落している場合は実行が拒否され、新しくアドバタイズされた MCP ツールは承認されるまで非アクティブになり、ローカル ツールはホストされているツールと同じポリシー ラッパーを使用する必要があります。

ステップ 3: 爆発範囲によってツールを分類する

すべてのツール呼び出しに人間の承認が必要なわけではありません。ガバナンスはリスクに比例する必要があります。有用な分類モデルは次のとおりです:

この分類はコードレビューと管理 UI に表示される必要があります。エージェントは説明を指示として扱う場合があるため、ツールの説明だけでは十分ではありません。ポリシー エンジンは、自然言語ツール名だけでなく、レジストリ メタデータとスコープに依存する必要があります。

ステップ 4: 高リスクのアクションに対する承認ゲートを追加する

承認をターゲットにする必要があります。すべてのツール呼び出しに人が必要な場合、エージェントは使用できなくなります。承認が必要なツール呼び出しがない場合、システムは過剰な権限を与える可能性があります。

一般的な承認フロー:

1. エージェントは構造化引数を使用してツール呼び出しを要求します。
2. ゲートウェイは、アイデンティティ、範囲、リスク層、予算、ポリシーを評価します。
3. 承認が必要な場合、ゲートウェイはツールを実行する代わりに保留中の承認イベントを返します。
4. アプリケーションはユーザーにプレビューを表示するか、承認チャネルに運用通知を送信します。
5. 承認者は、ポリシーで許可されている場合は承認、拒否、引数の編集、または説明の要求を行うことができます。
6. ゲートウェイは決定を記録し、承認されたバージョンのみを実行します。

承認ペイロードは、単なる生のアクションではなく、人間の言葉でアクションを示す必要があります JSON:

{
  "approval_id": "appr_123",
  "agent_run_id": "run_456",
  "requested_by_user": "user_789",
  "tool_id": "email.send",
  "risk_tier": "external_communication",
  "summary": "Send a reply to customer@example.com about ticket #4812",
  "redacted_arguments": {
    "to": "customer@example.com",
    "subject": "Update on ticket #4812",
    "body_hash": "sha256:..."
  },
  "expires_at": "2026-08-09T12:30:00Z"
}

承認は、外部通信、財務上のアクション、不可逆的な書き込み、特権管理、広範なデータのエクスポートに最も役立ちます。通常、少量の公開ドキュメントの検索には必要ありません。

ステップ 5: ツールごとの予算とレート制限を追跡する

トークンの予算が十分ではありません。安価なモデルでは、高価な検索、ブラウザ セッション、コード実行、サードパーティの API 呼び出し、または長いツール ループがトリガーされる可能性があります。ゲートウェイは少なくとも 4 つのカウンタを追跡する必要があります:

• ツールごとの呼び出し数: 実行、ユーザー、テナント、および時間枠ごとの最大呼び出し数。
• ツールごとのコスト: サードパーティへの直接料金、ブラウザ/ランタイム コスト、検索コスト、または内部チャージバックの見積もり。
• エージェント実行の累積コスト: モデル トークンとツールのコスト。
• ループの深さ: モデル、ツール、モデルの反復の最大数。

制限に達した場合、ゲートウェイは可能な限りサイレント ハード障害を回避する必要があります。より安全な機能低下パターンには、進行状況の概要を返す、続行するための承認を求める、取得深度を下げる、バックグラウンド ジョブをキューに入れる、または読み取り専用モードに切り替えるなどが含まれます。ブロックされたツール、スコープの欠落、不明な MCP 機能、危険なアクションには、引き続き強制拒否が適切です。

ステップ 6: モデルとツールのテレメトリを 1 つの監査レコードに結合する

モデルのログが 1 つの場所に存在し、ツールのログが別の場所に存在する場合、エージェントのデバッグは失敗します。監査レコードは完全なチェーンに接続する必要があります:

• テナント、ワークスペース、ユーザー、サービス アカウント、およびゲートウェイ キー。
• エージェント ID、エージェント バージョン、プロンプト テンプレート バージョン、およびモデル ID。
• ツール名、レジストリ バージョン、サーバー URL または実行環境、およびスキーマ ハッシュ。
• ツール入力ハッシュまたは編集された入力。デフォルトでは生の機密ペイロードは決して使用されません。
• 承認ステータス、承認者の ID、承認タイムスタンプ、承認された引数のハッシュ。
• レイテンシ、再試行、プロバイダー エラー、ツール エラー、トークン コスト、ツール コスト、および最終結果。
• アクションの状態が変化した場合のロールバック参照。

OpenAI のエージェント SDK トレース ドキュメントには、LLM 生成、ツール呼び出し、ハンドオフ、ガードレール、カスタム イベントのトレースが含まれており、より広範な可観測性の原則をサポートしています。エージェント トレースには、トークンの使用状況や遅延だけでなく、ツールのアクティビティも含める必要があります。ただし、単一の SDK パイプラインがすべてのホストされたツール、ローカル実行パス、または内部 API をカバーできるわけではありません。ゲートウェイ レベルの監査は、プロバイダーやフレームワーク全体での記録の正規化に役立ちます。

プライバシーは重要です。詳細なログによりデバッグとコンプライアンスのレビューが向上しますが、生のプロンプトとツールのペイロードが保持されると、新たなセキュリティ上の責任が生じる可能性があります。機密情報、資格情報、支払いデータ、個人データ、または専有文書を含む入力を編集またはハッシュします。未加工のペイロードは、明示的な保持ポリシー、アクセス制御、および削除ルールに従ってのみ保存してください。

ステップ 7: MCP 台のサーバーとサードパーティ ツールをサプライ チェーンの依存関係として扱う

MCP サーバーとサードパーティ ツールは、ライブラリ、Webhook、インフラストラクチャの依存関係と同じレビュー プロセスを通過する必要があります。推奨されるコントロールは次のとおりです:

• 承認された MCP 台のサーバーとツールの発信元の許可リストを維持します。
• 可能な場合はバージョンを固定し、スキーマ ハッシュを記録します。
• すべてのサーバーとリスクの高いツールには所有者が必要です。
• ツールを有効にする前に、ツール名、説明、スキーマ、権限の要求を確認してください。
• レビューされるまで、新しく追加されたツールを無効にします。
• ルートまたは機能ごとに必要なスコープを確認します。
• テナントの認証情報を分離し、顧客間でのトークンの共有を避けます。
• ネットワークとファイル システムに制限があるサンドボックスでは、信頼できないツールやリスクの高いツールを実行します。

ツールが標準プロトコルを通じて公開されているからといって、ツールが安全であるとは限りません。ガバナンス層には、依然として最小限の特権、明示的な承認、バージョン管理、監査機能が必要です。

実装チェックリスト

ポリシーの設計

• 共通エージェント ユーザーとサービス アカウントのロール テンプレートを定義します。
• モデル呼び出しとツール呼び出しに個別のスコープを作成します。
• データの機密性、可逆性、外部への影響、財務への影響、特権レベルによってツールを分類します。
• 不明なツールやスコープが見つからない場合のデフォルトの拒否動作を設定します。
• リスクの高いアクションに対してのみ承認ルールを定義します。

ゲートウェイの強制

• すべてのエージェントに、ゲートウェイまたは署名されたポリシー ラッパーを介してツールを呼び出すよう要求します。
• 実行前にテナント、ユーザー、キー、エージェント、モデル、ツール、スコープ、予算、承認ステータスを確認します。
• 最大のツール呼び出しの深さと累積実行コストを適用します。
• 呼び出しごとにツール レジストリのバージョンとスキーマ ハッシュを記録します。
• ポリシー エンジンが決定に到達できない場合はフェール クローズします。

監査と運用

• モデル呼び出しとツール呼び出しを 1 つのトレースまたはエージェント実行 ID で結合します。
• デフォルトで機密性の高いツール入力を秘匿化またはハッシュ化します。
• 承認の証拠は最終的な実行記録とともに保管してください。
• ツールごとのコストとレート制限の分析を管理者に公開します。
• 状態を変更するツールのロールバック所有者を文書化します。

予想されるトレードオフ

一貫性と統合作業。 ゲートウェイ レベルのガバナンスにより、モデル、SDK、チーム全体で一貫した適用が可能になります。導入にはコストがかかります。開発者は、アプリケーション コードからツールを直接呼び出すのではなく、承認されたパスを通じてツールの実行をルーティングする必要があります。

最小限の権限とポリシーの複雑さ。 きめ細かいスコープは影響範囲を縮小しますが、テンプレート、命名規則、および定期的なクリーンアップが必要です。テンプレートがないと、チームは迅速に行動するために権限を過剰に付与する可能性があります。

承認と自律性。 人間による承認は取り消し不能なアクションのリスクを軽減しますが、待ち時間が長くなります。すべてのルックアップや検索ではなく、高リスクのツールに対して承認を使用します。

監査可能性とデータ漏洩。 豊富なログはインシデント対応とデバッグに役立ちます。生のペイロードのログ記録により、機密情報や個人データが漏洩する可能性があります。編集、ハッシュ、構成可能な保持、アクセス レビューはオプションの詳細ではありません。

ハードリミットとタスクの完了。 ツールごとのコスト制限により、エージェントの暴走を防ぎます。また、長時間実行される正当な作業が中断される可能性もあります。承認から継続、バックグラウンドキュー、要約された部分結果などの継続パスを提供します。

予測: このパターンの方向性

予測: エージェントのガバナンスはよりアイデンティティ中心になるでしょう。チームが「これはどのモデルを使用しましたか?」と尋ねることが少なくなります。さらに多くの場合、「このツールのアクションを許可した認証済みの個人またはサービスはどれですか?」

予測: ツール レジストリはモデル レジストリと同じように通常のものになるでしょう。 MCP 台のサーバー、内部 API、ホストされるツールが増加するにつれて、運用チームは許可された機能、所有者、スキーマ、リスク層の一覧表を作成する必要があります。

予測: コスト ガバナンスはトークンのみのレポートからアクション レベルのレポートに移行します。エージェントの実行で最もコストがかかる部分は、モデル呼び出し自体ではなく、取得、ブラウザー自動化、コード実行、またはサードパーティ API である可能性があります。

実用的な結論

まず 1 つのルールから始めます。モデル キーはツール キーではありません。次に外側に向かって構築します。承認されたツールのレジストリを作成し、所有者とリスク層を割り当て、明示的な範囲を要求し、アクションが意味のある影響範囲を持つ場合にのみ承認を追加し、ツールごとの予算を強制し、モデルとツールのイベントを 1 つの監査証跡に結合します。

目標は、エージェントを無力にすることではありません。目標は、彼らの権力を読みやすく、範囲を定め、可能な限り元に戻すことができ、責任を負えるようにすることです。これは、エージェントが質問への回答からアクションの実行に移行する際のチーム API ガバナンスの実質的な基盤です。

関連資料

• チーム API の鍵の分離とローテーションの実践
• 結合されたトレース、トークン台帳、および安全なプロンプトロギング
• 構造化出力とツール呼び出し検証パターン