# Managed Agentsのauto権限を安全に設計する

> Managed Agentsの権限ポリシーautoは、2026年9月10日にサーバー側評価を追加し、ツール呼び出しを許可・拒否・承認待ちの3種に振り分けます。設計と限界を解説します。

- Canonical: https://kuucorp.com/blog/managed-agents-auto-permission-policy-risk-evaluation/
- Date: 2026-09-26
- Last modified: 2026-09-26
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
Managed Agentsでbashやチケット作成ツールを毎回`always_ask`で止めるとオペレーターが確認疲れを起こし、逆に`always_allow`にすると不可逆な操作を見逃す——この二択の間を埋める第三の権限ポリシーが2026年9月10日に追加されました。

[Managed Agents](/glossary/managed-agents/)の[エージェントガバナンス](/glossary/agent-governance/)設計において、権限ポリシーはツール実行の可否を左右する中核機構です。本記事では新設された`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）](https://kuucorp.com/services/rde/)では、こうした権限ポリシーの監査ログ設計とマルチチーム展開を支援しています。

## 参考

- [Permission policies - Claude Platform Docs](https://platform.claude.com/docs/en/managed-agents/permission-policies)
- [Claude Platform release notes](https://platform.claude.com/docs/en/release-notes/overview)

## まとめ

`auto`ポリシーは、固定ポリシーの二択では埋められなかった「大半は自動処理しつつ高リスクだけ人間が見る」運用を可能にしますが、人間のチェックポイントの代替ではなく、意図の読み取り経路にも注意が必要な機構です。`reason_code`を含む評価結果を監査ログに組み込み、不可逆な操作だけを個別に`always_ask`へ固定する設計から始めることをお勧めします。Managed Agentsの権限設計にお悩みの場合は、[Kuuのサービスページ](https://kuucorp.com/services/rde/)からご相談ください。