Managed Agentsでbashやチケット作成ツールを毎回always_askで止めるとオペレーターが確認疲れを起こし、逆にalways_allowにすると不可逆な操作を見逃す——この二択の間を埋める第三の権限ポリシーが2026年9月10日に追加されました。
Managed Agentsのエージェントガバナンス設計において、権限ポリシーはツール実行の可否を左右する中核機構です。本記事では新設されたautoポリシーの評価ロジックと、導入時に見落としやすい境界を整理します。
Managed Agentsのautoポリシーとは何か
autoはサーバーが呼び出しごとにリスクを評価し、実行・拒否・承認待ちの3通りに振り分ける権限ポリシーです。
Managed Agentsの権限ポリシーには従来always_allow（無条件実行）とalways_ask（毎回承認待ち）の2種類しかありませんでした。2026年9月10日、これにautoが加わりました。エージェントツールセットはalways_allow、MCPツールセットはalways_askがそれぞれ既定値のままで、autoはどちらのツールセットにも明示的に設定できるオプションです。
autoでは、ツールの種類・呼び出し入力・セッション内のそれまでの文脈を踏まえてサーバーが呼び出しごとに判定します。同じbashツールへの呼び出しでも、内容によって「安全だから実行」「高リスクだから拒否」「判断がつかないから承認待ち」に分かれる点が、固定ポリシーとの違いです。
autoの3つの評価結果はどう記録されるか
agent.tool_useイベントのevaluated_permissionとreason_codeで、allow・ask・denyの判定根拠を監査できます。
各agent.tool_use・agent.mcp_tool_useイベントにはevaluated_permission（allow/ask/deny）と、判定を行ったポリシー種別を示すevaluationオブジェクトが付与されます。auto配下で拒否された場合はreason_code: "high_risk"、承認待ちに回った場合はreason_code: "indeterminate"が記録されます。
拒否された呼び出しにクライアント側からuser.tool_confirmationを送っても、evaluated_permissionがaskでない限りAPIは400エラーで拒否します。サーバーがdenyと判定した呼び出しは、クライアント側で覆せません。監査ログにはこのreason_codeをそのまま記録し、後から人間が読む表示テキストではなく分岐条件として扱う設計にします。
autoは承認プロセスの代替になるか
autoは人間のチェックポイントではなく、安全と判定された呼び出しは誰にも見られず実行されるため代替にはなりません。
公式ドキュメントは明確に警告しています。autoはサーバーが安全と判定した瞬間に呼び出しを実行し、その効果は取り消せない可能性があります。人間による事前レビューが必須な操作には、そのツールだけconfigsでalways_askを個別設定する必要があります。
さらに注意すべきは「意図」の扱いです。サーバーはuser.messageイベントの内容をあなたの意図として読み取り、それによって本来拒否される呼び出しが許可されることがあります。一方でツール結果・取得したWebページ・MCPサーバーの応答・他セッションからのメッセージは評価対象にはなっても意図としては扱われません。エンドユーザーの未検証入力をuser.messageとして中継している場合、その入力もサーバーには「あなたの意図」として読まれるため、その経路で実行させたくないツールは個別にalways_askへ固定してください。
本番導入ではどう設計すべきか
エンタープライズでのMulti-agent構成では、エージェントツールセットとMCPツールセットの双方にautoを既定として設定しつつ、破壊力の大きい個別ツール（例: bashでのファイル削除系コマンド、本番環境への書き込みを伴うMCPツール）だけをconfigsでalways_askに上書きするのが基本形です。これにより「大半の呼び出しは自動処理し、不可逆なものだけ人間が見る」運用に近づきます。
evaluationフィールドが存在しないイベント（ツールセットに存在しないツール名を呼んだ場合や、機能導入前の古いイベント）も想定し、クライアントは未知のevaluation.typeやreason_codeを許容する実装にしておく必要があります。監査要件の厳しい組織では、reason_codeの分布を定期集計し、indeterminateが多いツールほど承認フローの負荷が高いという指標として運用改善に使えます。Kuuの大規模AI基盤支援（RDE）では、こうした権限ポリシーの監査ログ設計とマルチチーム展開を支援しています。
参考
まとめ
autoポリシーは、固定ポリシーの二択では埋められなかった「大半は自動処理しつつ高リスクだけ人間が見る」運用を可能にしますが、人間のチェックポイントの代替ではなく、意図の読み取り経路にも注意が必要な機構です。reason_codeを含む評価結果を監査ログに組み込み、不可逆な操作だけを個別にalways_askへ固定する設計から始めることをお勧めします。Managed Agentsの権限設計にお悩みの場合は、Kuuのサービスページからご相談ください。