Skip to main content
セキュリティプロファイルを使うと、セキュリティ制限の再利用可能なセット (ネットワークアクセス、MCPアクセス、gitアクセス、GitHub CLI 認証情報) を定義し、組織全体の Devin セッションに適用できます。セッションごとに制限を設定する代わりに、管理者は名前付きプロファイルを一度作成し、適切なレベルでアタッチできます。たとえば、組織全体のデフォルト、特定の自動化、または個別のセッションです。さらに、Enterprise では、すべての組織間でプロファイルを共有し、下位レベルでは緩和できない厳格な下限として適用できます。

​
プロファイル内の制限

プロファイルは、名前付きの制限の集合です。各制限は任意であり、プロファイルで設定した項目にのみ制約が適用されます。

​
ネットワークポリシー

ネットワークポリシーは、セッションのマシンがアクセスを許可された宛先の許可リストです。それ以外のすべての外向き接続はブロックされます。許可リストのエントリには、次のものを指定できます。
  • ホスト名。* ワイルドカードを使用できます (例: *.github.com, registry.npmjs.org) 。* は、ドットを含む任意の文字列に一致します。
  • IPv4 / IPv6 CIDR 範囲 (例: 10.0.0.0/8) 。
この制限は、セッションからのすべてのネットワークアクセスに適用されます。つまり、Shell コマンド、ブラウジング、パッケージのインストール、スクリプトのいずれも対象です。Devin は、制限付きネットワークポリシーの下で実行されていることを認識しており、現在の許可リストを確認できます。また、必要な宛先が許可リストにないためにブロックされた場合は、アクセスを要求します。リクエストを承認すると、そのセッションの許可リストにその宛先が追加されます (必須の制約がある場合はその範囲内です。詳しくは 適用 を参照してください) 。 Devin が機能するために必要な宛先 (接続済みリポジトリにアクセスするための git プロキシなど) は、自動的に許可されます。

​
MCP アクセス

デフォルトでは、セッションは組織にインストールされている任意のMCPサーバーを利用できます。プロファイルでは、MCPサーバーの許可リストを使ってこれを制限できます。つまり、そのプロファイルが適用されるセッションは、リストに含まれるサーバーしか利用できません。
MCP アクセスはネットワークポリシーとは独立して管理されます。MCPサーバーのアドレスをネットワークの許可リストに追加する必要はありません。プロファイルで許可されたサーバーには自動的にアクセスでき、プロファイルで除外されたサーバーは、ネットワークポリシーに関係なく利用できません。

​
Devin MCP access

セッションは、組み込みの Devin MCP を通じて、Devin 独自の管理ツールにもアクセスできます。これには、子セッションの作成やメッセージの送信、Knowledge やプレイブックの編集、スケジュールの管理などが含まれます。プロファイルでは、Devin MCP 読み取り専用 によってこのアクセス範囲を制限できます。プロファイルの適用を受けるセッションは、引き続き Devin のリソースを読み取ることはできますが (セッションの一覧表示、Knowledge の参照、プレイブックの確認など) 、セッションの作成や Knowledge の編集といった書き込み操作は実行できません。

​
Git アクセスレベル

接続したリポジトリに対して、セッションで実行できる操作を制御します。

​
GitHub CLI トークン

git アクセスレベルで定められた基本的な git 操作に加え、Devin’s machine には GitHub CLI (gh) トークンを設定でき、Devin は GitHub API を介して GitHub の機能を直接利用できます。プロファイルでは、マシンから GitHub CLI トークンを削除できます。プロファイルの適用対象となるセッションでは、Devin の git 統合を通じて引き続きリポジトリを操作できますが、GitHub APIコールを直接実行することはできません。 プロファイルでトークンを保持できるのは、フル git アクセスも付与し、ネットワークポリシーを設定する場合は api.github.com を許可している場合に限られます。どちらの条件も、プロファイルの保存時に検証されます。

​
プロファイルの保存場所

プロファイルは 2 つのスコープで管理されます。
  • 組織プロファイル は Settings → カスタマイズ → セキュリティプロファイル で作成され、その組織内でのみ使用できます。
  • Enterprise プロファイル (Enterprise アカウントのみ) は Enterprise settings → Devin → セキュリティプロファイル で作成され、Enterprise 内のすべての組織で使用できます。組織は、セッション、自動化、または組織のデフォルトに Enterprise プロファイルを選択できますが、プロファイル自体を編集できるのは Enterprise 管理者のみです。
プロファイル名は、各スコープ内で一意である必要があります。各プロファイルには 適用レベル もあり、下位レベルで上書きできるかどうかが決まります。

​
プロファイルをバインドできる対象

プロファイルは、リソースにバインドすることで有効になります。バインドには、最も広いものから最も具体的なものへと続く階層があります。
  1. Enterprise default — Enterprise 内のすべての組織で、新しく作成されるセッションに適用されます。
  2. 組織のデフォルト — その組織で新しく作成されるセッションに適用されます。
  3. 自動化のデフォルト — その組織の自動化によって開始されたセッションに適用され、それらのセッションでは組織のデフォルトより優先されます。同じ security-profiles 設定ページから設定します。
  4. 自動化 — その特定の自動化によって開始されたセッションに適用され、自動化のデフォルトより優先されます。自動化の Editor から設定します。
  5. セッション — 個々のセッションの作成時に選択するか (セッション開始ボックスのオプションメニューから) 、後でセッションの設定から変更できます。
各レベルでは、次の 3 つから選択できます。
  • 継承 (デフォルト) — 特に指定せず、1 つ上のレベルの設定を引き継ぎます。
  • プロファイルを固定 — このレベルのセッションでは、選択したプロファイルを利用します。
  • プロファイルなし — 明示的に適用しないようにすることで、上位レベルで推奨デフォルトが設定されていても、このレベルのセッションは制限なしで実行されます。
セッションが開始されると、Devin はこの階層を上位から順にたどります。最も具体的なバインドが優先されますが、上位で必須プロファイルによって制限されている場合はその限りではありません (以下を参照) 。他のセッションから生成されたセッション (子セッション) にも、親と同じ設定の連鎖が適用されるため、作業を委任して制限を回避することはできません。

​
変更が反映されるタイミング

セッションは起動時、つまり最初に作成されたときと、スリープから復帰するたび、または再起動するたびに、自身を管理するプロファイルを確定します。プロファイルの内容や、いずれかのバインド (デフォルト、自動化の固定、またはセッションの選択) を編集しても、すでに実行中のセッションに自動的に反映されることはありません。実行中のセッションでは、最後に復帰した時点で確定した制限がそのまま維持されます。変更は新しいセッションにはすぐに反映され、既存のセッションでは次回再開時に反映されます。 すべてのプロファイルには適用レベルがあります： 推奨プロファイルは既定値であり、必須ではありません。下位レベルでは、適切な権限があれば、別のプロファイルを固定したり、完全にオプトアウトしたりできます。推奨プロファイルを利用することで、柔軟性を保ちながら、チームにとって適切な出発点を提供できます。

​
必須

必須プロファイルは、下位レベルでは回避できない下限です。
  • オプトアウトしても効果はありません。 必須プロファイルより下位で「プロファイルなし」を選択しても無視されます。
  • 下位レベルの選択でできるのは制限を強めることだけで、緩めることはできません。 下位レベルで別のプロファイルを固定すると、2 つのプロファイルは積集合として扱われます。
    • ネットワーク許可リストは、両方のプロファイルで許可されている宛先に絞り込まれます。
    • MCP 許可リストは、両方で許可されているサーバーに絞り込まれます。
    • Git アクセスはより制限の厳しい方が適用されます (フルアクセスより読み取り専用が優先されます) 。
    • Devin の MCP アクセスは、いずれかのプロファイルが読み取り専用に設定されている場合、読み取り専用になります。
    • GitHub CLI トークンは、いずれかのプロファイルがこれを削除している場合に削除されます。
  • セッション途中の変更にも制限がかかります。 セッション中に付与されたネットワークアクセス (例: 新しいドメインに対する Devin のリクエストを承認した場合) は、必須プロファイルのポリシーと積集合で扱われるため、必須プロファイルで許可されている範囲を超えるアクセスがセッションに付与されることはありません。
たとえば、enterprise では、*.internal.example.com を許可するネットワークポリシーを持つ必須プロファイルを Enterprise default としてバインドできます。その後、各組織はその上に独自のプロファイルを重ねて、特定のチームやワークフローをさらに制限できます。ただし、どの組織、自動化、セッションでも、enterprise のポリシーを超えてアクセスを広げることはできません。

​
権限とガバナンス

プロファイルの管理には、一般的な設定管理とは別に、専用のセキュリティプロファイルの管理権限が必要です。この権限は 2 つのレベルで存在し、それぞれ個別に付与されます。 この権限は、どちらのレベルでもカスタム ロールに付与できるため、完全な管理者権限を与えなくても、セキュリティポリシーの管理を委任できます (たとえば、セキュリティチームに) 。 この権限を持たないメンバーは、プロファイルを一覧表示したり、選択したり、変更したりできません。セッションは、適用対象として決定されたデフォルトに従うだけです。ただし、自分のセッションがプロファイルの適用対象かどうか、およびどのネットワークアクセスを持っているかは、誰でも確認できます。

​
セキュリティプロファイルの設定

  1. プロファイルを作成します。 Settings → カスタマイズ → セキュリティプロファイル (Enterprise 全体のプロファイルの場合は Enterprise settings → Devin → セキュリティプロファイル) に移動し、プロファイルを作成して、セキュリティ設定と適用レベルを設定します。
  2. デフォルトを設定します。 プロファイルを組織のデフォルト (または Enterprise default) としてバインドし、新しいセッションに自動的に適用されるようにします。
  3. 必要な箇所で固定します。 特定の自動化ではデフォルトをオーバーライドします。たとえば、機密性の高いシステムに触れる自動化には、より厳格なプロファイルを設定したり、個別のセッションに作成時点で設定したりできます。
  4. 段階的に厳格化します。 まずは推奨プロファイルで影響を確認し、その後、チームの正当なニーズを許可リストでカバーできるようになったら、必須に切り替えます。

​
自動化とプロファイル

自動化には、独自のネットワークポリシーとMCPサーバーの選択を設定できます。これらは、適用されるプロファイルに対する制限のみのレイヤーです。自動化によって開始されたセッションで使用できるのは、自動化とプロファイルの両方で許可されたネットワーク宛先とMCPサーバーのみです。そのため、自動化によってプロファイルのアクセス範囲が拡大されることはありません。 自動化レイヤーは、各セッションの起動時と復帰時に都度解決されるため、自動化のネットワークポリシーを編集すると、セッションを再作成しなくても変更が反映されます。

​
Outposts とプロファイル

Devin Outposts で実行されるセッションは、クラウドセッションと同じバインドチェーンを通じて適用対象のプロファイルを決定します。また、Devin がクラウド側で適用する制限 (MCP 許可リスト、Devin MCP の読み取り専用、Git アクセスレベル、GitHub CLI トークンの削除) は、クラウドセッションとまったく同様にアウトポストセッションにも適用されます。 ネットワークポリシーは異なります。Devin は、Devin 管理の VM ではマシンレベルでセッションのネットワークの許可リストを適用しますが、アウトポストワーカーはお客様が運用するインフラストラクチャ上で実行されるため、Devin がお客様のマシンにファイアウォールルールを設定することはありません。代わりに、キューに登録された各セッションの有効なネットワークポリシーは、Outposts API を通じて spec.network_policy (ポリシーが有効かどうか、許可されるホスト名と CIDR) としてオーケストレーターに公開されます。セッションごとの送信プロキシ、Kubernetes の NetworkPolicy、VM のファイアウォールルールなどを使用してこれを適用する責任は、アウトポスト運用者にあります。Devin は引き続き許可リストを確認し、通常どおりリストにない宛先へのアクセスをリクエストしますが、リクエストを承認しても Devin 内のセッションポリシーが更新されるだけで、お客様のネットワーク自体は変更されません。spec.network_policy はセッションがアウトポスト用にキューへ登録された時点で取得され、再キューイング時 (たとえばセッションがスリープから復帰した後) に更新されるため、静的なものとみなさず API から再取得してください。
必須プロファイルのネットワークポリシーを厳格な境界として利用する場合は、アウトポストインフラストラクチャが処理するすべてのセッションに対して spec.network_policy を適用していることを確認してください。そうでない場合、アウトポスト上のセッションはお客様のマシンが持つネットワークアクセスをそのまま利用できます。