メインコンテンツへスキップ
権限システムでは、エージェントがあなたの承認なしに実行できる操作を制御します。安全な操作は事前に承認し、危険なものはブロックし、機密性の高い操作では常に確認を求めるようにできます。

デフォルトの権限の動作

Devin CLI は、機能性と安全性のバランスを取るために、ティア制の権限システムを利用します。デフォルトの動作は、現在のモードによって異なります。 各セルには、そのモードでそのツールが自動的に実行されるか (Auto、確認なし) 、承認を待つか (Prompt) が示されています: Normal モード (デフォルト) では、読み取り専用の操作は自動承認されますが、書き込み操作とシェルコマンドの実行には明示的な承認が必要です。アクションを承認するたびに、1 回だけ許可するか、セッション中は許可するか、またはプロジェクトに対して永続的に許可するかを選択できます。 Accept Edits モードでは、ワークスペース内のファイル編集は自動承認されますが、シェルコマンドとワークスペース外への書き込みでは引き続き確認が表示されます。 Bypass モードでは、すべてのツール呼び出しが確認なしで自動承認されます。 Autonomous モードでは、OS レベルのサンドボックスによってアクセス可能な範囲が制限されるため、シェルコマンドとネットワークリクエストは自動承認されます。一方、edit/write ツールによる直接のファイル編集は、それらのツールがサンドボックスの外で動作するため、引き続き確認が表示されます。Autonomous は、OS レベルのサンドボックスがアクティブな場合にのみ利用できます。
Bypass モードと Autonomous モードは、組織レベルの権限を上書きしませんチーム設定 で構成された管理者適用の deny ルールおよび ask ルールは、ユーザーの権限モードに関係なく有効なままです。詳しくは Precedence を参照してください。

Autonomous モード

Autonomous は、--sandbox フラグと組み合わせて使う権限モードです。概念的には、これはおおむね「現在のワークスペースで編集を受け入れる」に、任意のシェルコマンドを実行する機能を加えたもので、どちらの動作も OS レベルのサンドボックス内に制限されます。サンドボックスがアクティブな場合:
  • 利用できる権限モードはこれだけです。 サンドボックスのセッションでは、Normal、Accept Edits、Bypass は表示されません。Plan モードは引き続き利用できます。
  • シェルコマンドとFetchは、確認なしで自動承認されます。 サンドボックスによって、それらが読み取り・書き込みできる範囲や、ネットワーク経由で到達できる範囲が制限されるためです。
  • edit および write ツールによるファイルの直接編集では、引き続き確認が求められます。 これらのツールはサンドボックス内ではなく CLI プロセス内で実行されるため、サンドボックスで制限できません。プロンプトで Write(...) スコープを付与すると、以後のシェルコマンドがその場所に書き込めるよう、サンドボックスが動的に拡張されます。
  • セッションの途中で付与されたスコープによって、以後のコマンドに対するサンドボックスの範囲が動的に拡張されます。
OS レベルの分離なしで制限なく実行したい場合は Bypass を利用し、ファイルシステムとネットワークアクセスに OS による制限が適用された無人実行を行いたい場合は --sandbox (Autonomous が選択されます) を利用してください。書き込み可能/読み取り可能なルートやドメインフィルタリングの詳細については サンドボックス設定リファレンス を、Enterprise 向けの制御については チーム設定 → サンドボックス強制 を参照してください。

権限 の仕組み

エージェントがツールを呼び出すと、権限システムは優先順位に従ってルールを確認します。
  1. Deny rules — 最初に確認されます。一致した場合、その操作はただちにブロックされます。
  2. Ask rules — 次に確認されます。一致した場合は、常に確認を求められます (allow ルールより優先されます) 。
  3. Allow rules — 最後に確認されます。一致した場合、その操作は確認なしで実行されます。
  4. Default — 一致するルールがない場合は、承認を求められます。
deny は ask より先に確認され、ask は allow より先に確認されるため、deny ルールが常に優先されます。同じスコープが deny ルールと ask ルールの両方に一致する場合は、deny が適用されます。

設定

設定ファイルの permissions セクションに権限を追加します。
Windows では、ユーザー設定ファイルのパスは ~/.config/devin/config.json ではなく、%APPDATA%\devin\config.json (通常は C:\Users\<you>\AppData\Roaming\devin\config.json) です。詳しくは Configuration File を参照してください。

権限の構文

権限マッチャーには、スコープベース (アクセス可能なパス、コマンド、URL を制御) と、ツールベース (利用可能なツールを制御) の 2 種類があります。

スコープベースの権限

Read(glob)

ファイルの読み取り権限を制御します。glob パターンはファイルパスにマッチします。
ディレクトリパスは、その配下のすべてのファイルに自動的にマッチします。
ファイルの書き込み/編集権限を制御します。
シェルコマンドの実行権限を制御します。指定したプレフィックスで始まるコマンドにマッチします。
Exec(git) は “git”、“git status”、“git commit -m ‘msg’” にはマッチしますが、“gitk” や “github-cli” にはマッチしません。プレフィックスは完全な単語として一致する必要があります。
URL パターンを使って HTTP fetch 権限を制御します。
URL パターンは WHATWG URL Pattern 標準に従います。domain: の省略記法は、完全一致するドメイン上の任意のパスにマッチします。

ツールベースの権限

ツール名で一致させることで、ツール全体を制御できます:
使用可能なツール名: read, edit, grep, glob, exec

MCP ツールの権限

MCP サーバー上のツールへのアクセスを制御します:

パスパターン

Read()Write() では、以下の glob パターンをサポートしています。 使用例:
システム上のすべてのファイルを対象にしたい場合は、絶対パスのプレフィックス (例: Read(/**)) を使用してください。先頭に / のない Read(**) は現在の作業ディレクトリからの相対パスとして解決されるため、そのディレクトリ配下のファイルにしか一致せず、他の場所にある絶対パス経由のファイルには一致しません。

永続化オプション

セッション中にエージェントが許可を求めた場合、その選択をどのように保存するかを選べます。

MCPサーバーレベルの権限付与

特定のMCPツール (例: Figmaサーバー上のlist_issues) の許可を求められた場合、権限プロンプトには、より広いサーバーレベルの選択肢も表示されます。 これにより、信頼できるMCPサーバーに対して、各ツールを個別に承認しなくても、まとめてすばやくアクセスを許可できます。

優先順位

複数の権限ソースでルールが定義されている場合、以下の優先順位 (高い順) でマージされます。
  1. 組織/チームの設定 (Enterprise の場合)
  2. セッションレベルの付与 (対話的な承認)
  3. プロジェクトのローカル設定 (.devin/config.local.json)
  4. プロジェクト設定 (.devin/config.json)
  5. ユーザー設定 (~/.config/devin/config.json、Windows では %APPDATA%\devin\config.json)
組織レベルでの拒否設定は、プロジェクト設定やユーザー設定で上書きできません。これにより、Enterprise のポリシーが確実に適用されます。

使用例

最小限の開発構成

一般的な読み取り専用の操作は許可し、それ以外はすべて確認を求めます:

プロジェクトを全面的に信頼する

プロジェクト内のほとんどの操作を自動承認します:

厳格に制限された Enterprise

安全な特定の操作のみに限定し、書き込み時は常に確認を求める:
この例では、.env* への書き込みは無条件で拒否され、それ以外の書き込みはすべて常にユーザーに確認を求めます。また、自動承認されるのは一部の読み取り専用コマンドのみです。deny は ask より先にチェックされるため、.env* の拒否は Write(**) の ask ルールよりも優先されます。