自律レベル

自律性は、名前付きリスクプロファイルに含まれるエージェントごとの設定です: [risk_profiles.<alias>].level。各エージェントは agents.<alias>.risk_profile = "<profile-alias>" を介して1つのリスクプロファイルを参照します。設定は3種類あり、supervised がデフォルトです。

readonly / supervised / full のみが有効な値です。read_only（アンダースコア付き）は設定読み込み時に拒否されます。プロファイルが完全な設定にどのように組み込まれるかについては、正規の最小動作例を参照してください。

3つのレベル

readonly

エージェントは観察できますが、何も変更できません。許可されているツールは副作用のないものです：

• file_read, file_list
• memory_search
• http（GETのみ；POSTはブロックされます）
• web_search
• time

用途：公開向けのQ&Aエージェント、分析専用のデプロイメント、または新しいツール設定を承認する前に、それを検証する方法として。

supervised (デフォルト)

低リスクのツールは自動的に実行されます。中リスクのツールはオペレーターの承認プロンプトをトリガーします。高リスクのツールはブロックされます。

リスク分類:

承認チャネル: 承認プロンプトは、会話を開始したチャネルを通じて配信されます。Telegram はインラインキーボードボタンを使用し、Slack Socket Mode は Block Kit ボタンを使用します。Discord、Signal、Matrix、WhatsApp はプロンプトに短いトークンを埋め込み、<token> approve|deny|always の返信を待ちます。CLI ではインラインプロンプトとなります。ACP では、エージェントが session/request_permission JSON-RPC request をエージェントからクライアントへ発行します（session/update 通知ではありません）。クライアントは、承認、常に承認、または拒否のために {"outcome": {"outcome": "selected", "optionId": "allow-once|allow-always|reject-once"}} または {"outcome": {"outcome": "cancelled"}} で応答します。ACP → session/request_permission を参照してください。

タイムアウト: 応答のない承認リクエストは、チャネルの approval_timeout_secs（ほとんどのチャネルでデフォルトは120。各チャネルの設定ブロックを参照）が経過すると失効します。タイムアウトは拒否として扱われます。

full

承認ゲートはありません。low/medium/high のいずれにフラグ付けされたツール呼び出しもすべて、確認なしで実行されます。workspace_only は暗黙的に無効化されます（エージェントはワークスペース外のパスにアクセスできます）。forbidden_paths は引き続きブロックします。OS レベルのサンドボックス（sandbox_enabled + sandbox_backend）も引き続き適用されます。

これは、信頼できるローカル開発環境、CI、または人間を介さずにエンドツーエンドで実行する必要がある標準手順書（SOP）に適しています。full モード、ワークスペースの制約なし、サンドボックス化なしが必要な場合は、YOLO モード を参照してください。

ツールごとのオーバーライド

auto_approve、always_ask、excluded_tools は、リスクプロファイル上でツール名のフラットなリストとして存在します（ネストされたテーブルではありません）。excluded_tools はチャネルごと（channels.<type>.<alias>.excluded_tools）にも利用でき、プロファイルを変更せずに特定のサーフェスからツールを非表示にできます。

クロスチャネル承認ルーティング

デフォルトでは、承認プロンプトは会話を開始したチャネル経由で配信されます。プロファイルのツール承認を別の承認者チャネルに送信するには（たとえば、パブリックチャネルから駆動されるエージェントで、そのリスクのあるアクションを別のopsチャネル、または別のプリンシパルが承認する必要がある場合）、リスクプロファイルに approval_route を設定します：

[risk_profiles.frontline.approval_route]
approver_channel = "matrix.ops"     # チャネルレジストリのキー。発信元ではない
on_no_approver   = "deny"           # デフォルト。または "inherit-originator"
timeout_secs     = 120              # デフォルト。承認者の応答受付時間を制限する

• approver_channel は承認リクエストを受け取るチャンネルレジストリのキーです。キーはプラットフォーム修飾された <channel>.<alias> 形式です（例: matrix.ops や telegram.default）。プラットフォーム名のみ（例: matrix）の場合は、そのプラットフォームに単一のチャンネルしか存在しないときのみ解決されます。エイリアス単独ではレジストリキーとならず、フェイルクローズします。ルートが設定されている場合、承認ゲートは発信元のチャンネルではなく、そのチャンネルのみ に問い合わせます。
• on_no_approver は、承認者が明確な返答をしない場合、連絡が取れない場合、登録されたチャネルでない場合、またはタイムアウトした場合の動作を決定します:
  • deny（デフォルト）はフェイルクローズで動作し、ツール呼び出しを拒否します。
  • inherit-originator は発信元チャネルのプロンプトにフォールバックします（現在の動作）。
• timeout_secs（デフォルト120）は、ゲートが on_no_approver を適用する前に承認者を待機する時間を制限します。これにより、承認者チャネルがハングしてもターンが停止することはありません。

approval_route が指定されていない場合（デフォルト）、承認は上記で説明したとおりに動作します。つまり、会話を開始したチャネルを通じて配信されます。フェイルクローズのデフォルトは、承認者の設定が誤っているか到達不能な場合に、暗黙的に自己承認するのではなく拒否することを意味します。

スコープ。 approval_route は両方のターンパスで尊重されます: インタラクティブなチャネル駆動パス（ライブチャネルハンドルを持つターン、例: ストリーミングエージェントチャット）と、発信元チャネルなしで実行される非インタラクティブパス（gateway chat/webhook ディスパッチおよびエージェント間ピアメッセージ）。非インタラクティブパスでは、承認者は実行中のデーモン内の ライブで登録済みのチャネル でなければなりません（デーモンのチャネルレジストリを通じて解決されます）; そのレジストリが利用できない場合（例: チャネルが起動されていないワンショット CLI 実行）、または指定された承認者がライブでない場合、ゲートはプロファイルの非インタラクティブデフォルトにフォールバックし、デフォルトの on_no_approver = "deny" の下ではフェイルクローズ（拒否）します。

コマンド許可リスト

shell ツールに関して特に注意すべき点: allowed_commands が空でない場合は厳格に扱われます。リストにないコマンドはすべてブロックされます。shell-policy バリデーターは、許可リストに加えて破壊的パターンの検出も処理します。

パスルール

workspace_only = true は、読み取りと書き込みを <workspace>/** および要求されたアクセスモード用に構成された allowed_roots に制限します。絶対パスのワークスペース、allow-root、および forbidden_paths のエントリでは、パスコンポーネントのプレフィックスが使用されます。複数のエントリが一致する場合は、最も具体的なプレフィックスが優先され、同じ深さで同点の場合は禁止エントリが優先されます。そのため、禁止サブツリーによってワークスペースまたは許可されたルートの一部をブロックできる一方、限定的なオペレーター許可は、/home や /tmp のような広範なデフォルトの禁止ルートの下でも引き続き使用できます。

解決済みファイルのチェックでは、ファイルシステムのエイリアスを解決した後に一致するすべてのエントリを比較するため、シンボリックリンクを介して禁止されたサブツリーを指定しても拒否を回避できません。これらは絶対プレフィックスのルールであり、glob マッチングやワークスペース相対の ignore パターンのセマンティクスは提供しません。

サンドボックス

OSレベルのサンドボックス化フィールドは、同じリスクプロファイル上に存在します。OSごとのバックエンド選択については、サンドボックス化を参照してください。

環境のパススルー

shell ツールはデフォルトで最小限の環境で実行されます。特定の環境変数は risk profile を介して公開してください。シークレット（API_KEY、_TOKEN、_SECRET、_PASSWORD のパターン）は 決して 自動的に渡されることはありません。明示的にリストするか、コマンド内でシークレットストアから取得してください。

チャンネルごとの厳格な自律性

自律性はエージェントごとに設定され、チャネルごとではありません。一般公開向けのチャネルをメインエージェントよりも厳格なレベルで運用するには、より厳格なリスクプロファイルにバインドされた2つ目のエージェントを定義し、そのチャネルをそこにルーティングします。チャネルごとの excluded_tools（channels.<type>.<alias>.excluded_tools）は、個々のツールを非表示にするだけでよい場合の、より手軽な手段であり、2つ目のエージェントは不要です。

観測性

承認リクエスト、承認、拒否、タイムアウトはすべて、infra クラスターを通じて構造化イベントを出力します：

INFO autonomy:approval_requested ツール=file_write パス=/tmp/foo.txt チャンネル=discord ユーザー=alice
INFO autonomy:approval_granted   ツール=file_write パス=/tmp/foo.txt チャンネル=discord ユーザー=alice
WARN autonomy:approval_timeout   ツール=shell コマンド="git push" チャンネル=telegram ユーザー=bob
WARN autonomy:blocked            ツール=shell コマンド="rm -rf /tmp" 理由="forbidden pattern"

ブロックされた呼び出し、拒否、およびタイムアウトは監査に値しますが、ツールレシートではありません。これらはオブザーバビリティイベントを発行します。レシートが有効な場合、ツールレシート は成功したツール結果に添付されます。

なぜ単純なバイナリの「セーフモード」ではないのでしょうか？

有用な中間領域が広いからです。エージェントにスクリプトを自動実行させたいが master へのプッシュはさせたくないユーザーには、「すべて許可」と「すべて禁止」の間に位置する何かが必要です。3 段階の自律性 + ツールごとのオーバーライド + コマンドの許可リストにより、設定を断片化させることなく、その調整つまみを提供できます。