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

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

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

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

読者の問題: モデルへのアクセスとツールへのアクセスが混同されている

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

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

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

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

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

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

<オル>

ツール レジストリ: 承認されたツール、MCP サーバー、ホストされた機能、ローカル実行ツール、内部 API の信頼できるリスト

ID とキー層: ゲートウェイ キー、ユーザー、テナント、サービス アカウント、チーム、再販業者の顧客。

スコープ エンジン: キーまたはユーザーが特定のツール機能を呼び出せるかどうかを決定するポリシー チェック。

リスク分類子: 爆発範囲、データの機密性、可逆性、外部への影響、コスト負担を説明するメタデータ。

承認ワークフロー: リスクの高いアクションについては、実行前に人間またはシステムが承認します。

予算およびレート制限台帳: モデルごとのトークン制限だけでなく、ツールごとおよびエージェントごとの制限

監査およびトレース ストア: モデル呼び出し、ツール呼び出し、承認、エラー、結果の結合レコード

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

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

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

{
  "tool_id": "crm.create_ticket",
  "display_name": "CRM サポート チケットの作成",
  "owner_team": "サポートオートメーション",
  "実行タイプ": "内部 API",
  "server_url": "https://tools.internal.example/crm",
  "allowed_tenants": ["エンタープライズ", "サポート"],"allowed_models": ["一般-大", "一般-高速"],
  "risk_tier": "reversible_write",
  "データ分類": "顧客メタデータ",
  "required_scopes": ["tool:crm.create_ticket"],
  "approval_policy": "1 日あたりのチケット数が 100 枚未満では不要",
  「default_timeout_ms」: 8000、
  「通話あたりの最大コスト」: 0.05、
  「実行ごとの最大呼び出し数」: 3、
  "rollback_owner": "サポート-ops-oncall",
  "retention_policy": "redacted_30_days"
}

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

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

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

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

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

モデル:チャット
モデル:埋め込み
ツール:docs.search_readonly
ツール:crm.create_ticket
ツール:email.send_requires_approval
ツール:billing.refund_blocked
ツール:code.execute_blocked

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

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

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

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

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

<テーブル> <頭> リスク層例デフォルト コントロール <本体> 読み取り専用パブリックパブリック ドキュメントの検索、パブリック Web サイトの取得レート制限付きで許可 読み取り専用の内部内部 wiki、製品ドキュメント限定されたチームに許可。ログを秘匿化する 読み取り専用の顧客データアカウント検索、サポート履歴テナントとユーザー範囲のチェック。厳格な監査 書き込みを元に戻すチケットを作成し、メモの下書きを追加します制限付きで許可し、所有者をロールバックします 外部コミュニケーションメールの送信、メッセージの投稿、コンテンツの公開ほとんどのユースケースの承認またはプレビュー 不可逆書き込み記録を削除、法的フォームを提出デフォルトで拒否するか、高信頼性の承認が必要 財務上の措置返金、購入、請求変更強力な承認、低い限度額、完全な監査 コードの実行シェルの実行、Python の実行、スクリプトのデプロイサンドボックス、ネットワーク制限、タイムアウト、必要に応じて承認 特権管理者ユーザーの作成、ロールの変更、認証情報のローテーションデフォルトでは拒否。ブレークグラス プロセスのみ

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

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

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

一般的な承認フロー:

<オル>

エージェントは構造化引数を使用してツール呼び出しをリクエストします。

ゲートウェイは、アイデンティティ、範囲、リスク層、予算、ポリシーを評価します。

承認が必要な場合、ゲートウェイはツールを実行する代わりに保留中の承認イベントを返します。

アプリケーションはユーザーにプレビューを表示するか、承認チャネルに運用通知を送信します。

承認者は、ポリシーで許可されている場合は承認、拒否、議論の編集、または説明のリクエストを行うことができます。

ゲートウェイは決定を記録し、承認されたバージョンのみを実行します。

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

{
  "approval_id": "appr_123",
  "agent_run_id": "run_456",
  "requested_by_user": "user_789",
  "tool_id": "email.send",
  "リスク層": "外部通信",
  "summary": "チケット #4812 について [email protected] に返信を送信します",
  "redacted_arguments": {
    "宛先": "[email protected]",
    "件名": "チケット #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 キーの分離とローテーションの実践
• 結合トレース、トークン台帳、および安全なプロンプト ロギング
• 構造化出力とツール呼び出し検証パターン