Codex セキュリティクックブック

従業員が会社の ChatGPT ワークスペースを通じて Codex にサインインする必要があり、管理対象のエンドポイントでは個人の ChatGPT アカウントと API キーによる認証を禁止する場合に使います。

期待する結果

会社の管理対象デバイスでは、Codex は会社の ChatGPT ワークスペースへの ChatGPT サインインのみを受け付けます。

前提条件

• 承認済みの ChatGPT Enterprise ワークスペースの UUID

• Codex の管理設定をエンドポイントに配布する手段

• 管理対象のエンドポイントで API キー認証を禁止する方針

設定

1. 承認済みのワークスペースの UUID を社内の設定リポジトリに記録します。

2. ローカルの requirements.toml に、強制する認証要件を追加します。

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

   1 つ目のキーで ChatGPT 認証のみを許可し、2 つ目のキーでサインイン先を承認済みのワークスペースに限定します。例の UUID は自社のワークスペースの UUID に置き換えてください。要件リファレンスを参照してください。

3. ローカルの requirements.toml または macOS の MDM を通じて要件を配布します。使用するパスは設定の配置先を参照してください。これらの認証要件は、認証情報の読み込みやクラウドポリシーの取得より前に適用されます。クラウド管理の要件に含めても Codex は無視します。ユーザーがファイルや親ディレクトリを変更できないように保護してください。従来の managed_config.toml のデフォルト設定では、この制限を強制できません。

4. 試験導入時にユーザーをサインアウトさせるか、保存済みの個人用 Codex セッションを削除します。新しいポリシーが既存のセッションまで無効にすると想定しないでください。

5. サインインの制限と併せて、ワークスペースのロールとグループのアクセス権を設定します。認証はどの ID でサインインできるかを制御し、RBAC はその ID で利用できる Codex の機能を制御します。認証を参照してください。

検証

• Codex からサインアウトします。

• 個人の ChatGPT アカウントでサインインを試します。個人のワークスペースへのサインインが拒否されることを確認します。

• API キーで Codex へのログインを試します。API キーによるログインが拒否されることを確認します。

• 会社のアカウントで承認済みのワークスペースにサインインします。サインインが成功することを確認します。

• デスクトップアプリ、CLI、IDE 拡張機能を再起動し、同じ検証を繰り返します。

ロールバック

以前のローカル認証要件に戻し、レビュー済みの設定一式を再配布します。

適用範囲と限界

この設定の対象は、管理対象のエンドポイントで動作する管理対象の Codex クライアントです。「会社の資産から Codex を個人利用できないようにする」という要件がある場合は、エンドポイントのアプリケーション制御とネットワークポリシーを併用してください。

開発者に読み取り専用またはワークスペース内に限定したアクセスを許可し、フルアクセスの選択や --yolo による承認とサンドボックスの回避を防ぐ場合に使います。

期待する結果

ユーザーが選択できるのは、承認済みの読み取り専用プロファイルまたはワークスペース内に限定したプロファイルのみです。danger-full-access、approval_policy = "never"、--yolo は選択できません。

設定

1. 承認済みのワークスペースプロファイルを定義します。

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. 許可するプロファイルと承認ポリシーを強制します。

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

   許可リストに記載のないプロファイルと false に設定したプロファイルはすべて拒否されます。将来のバージョンで追加されるプロファイルも対象です。設定リファレンスを参照してください。

3. 引き続き sandbox_mode を使う旧クライアントには、次の設定を使います。

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. ユーザーが編集できる設定ファイルではなく、管理者が強制する要件として配布します。

5. 後から承認リクエストの自動レビューを使用する場合は、テストしたうえで明示的に許可してください。自動レビューによって変わるのは、制限を越える操作を誰がレビューするかです。解除された制限が復元されることはありません。自動レビューを参照してください。

検証

• 権限の選択画面を開きます。フルアクセスを選択できないか、選択が拒否されることを確認します。

• --dangerously-bypass-approvals-and-sandbox を指定して起動します。Codex が起動を拒否するか、要件に適合するプロファイルを強制することを確認します。

• --sandbox danger-full-access --ask-for-approval never を指定して起動します。起動が拒否されることを確認します。

• ワークスペース内で通常のタスクを実行します。タスクが成功し、制限を越える操作には引き続き承認が必要であることを確認します。

ロールバック

以前の要件一式に戻します。別途承認された例外がない限り、無制限のアクセスは引き続きブロックしてください。

適用範囲と限界

この設定は Codex の実行時の権限を制御します。OS の特権アカウントから特権を取り除くものではありません。

組織が Codex で利用できる MCP サーバーを決め、承認済みのリストを強制する場合に使います。

サーバーの許可と設定は別々の手順です。許可リストにエントリを追加すると、一致するサーバーの利用が許可されますが、サーバー設定は作成されません。一致する名前と識別情報を使って、サーバーと必要な認証を別途設定してください。

期待する結果

Codex は、設定された名前と識別情報が組織の承認済みリストに一致する MCP サーバーのみを有効にします。

設定

1. 承認するサーバーごとに、所有者、用途、トランスポート、実行ファイルまたは URL の正確な値、認証方式、データ分類、書き込み可能なツールを洗い出します。

2. 最初はすべて拒否します。管理設定で空のテーブルを指定すると、すべての MCP サーバーが無効になります。

   [mcp_servers]

3. 承認済みの HTTP サーバーを、完全に一致する URL で追加します。

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. 承認済みの stdio サーバーを、実行ファイルと位置引数で追加します。

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

   この構造化された照合ルールは、実行ファイル、引数の数、引数の順序を検査します。cwd、env、env_vars は制限しません。stdio サーバーの承認には、起動時の条件をすべて制御できることが前提です。実行ファイルと依存関係を保護し、信頼できないユーザー設定やプロジェクト設定から、動作を変える可能性のある作業ディレクトリや環境を指定できないようにしてください。この制限を別の仕組みで強制できない場合は、stdio サーバーを承認せず、レビュー済みの HTTP サーバーを使ってください。

5. プラグインに同梱される MCP サーバーの識別情報は、plugins.<plugin>.mcp_servers.<server> に個別に追加します。

6. 承認済みのリストをレビュー対象の設定リポジトリに保管し、管理者が強制する要件として配布します。

クライアントは、名前と識別情報の両方が承認済みのエントリに一致する場合にのみサーバーを有効にします。管理設定を参照してください。

検証

• 承認済みのエントリと完全に一致するようにサーバーを設定します。サーバーが起動することを確認します。

• URL を 1 文字変更します。サーバーが無効になることを確認します。

• stdio の引数の数や順序を変えるか、設定したルールに一致しない引数を渡します。サーバーが無効になることを確認します。許可されたプレフィックスに引き続き一致する値は許可されます。

• 使い捨ての信頼済みプロジェクトで、一致する実行ファイルと引数を維持したまま、cwd、env、env_vars を無害な値で上書きします。識別情報の照合だけでは、こうした上書きは拒否されません。起動時の条件を制御する独立した仕組みが危険な上書きを拒否するか、stdio サーバーが未承認のままであることを確認してください。実際のインジェクション攻撃に使うペイロードは使用しないでください。

• 未承認の名前を追加します。サーバーが無効になることを確認します。

• プラグインに同梱されたサーバーをテストします。承認済みの識別情報を使った場合にのみ動作することを確認します。

ロールバック

新しく追加したエントリを削除します。MCP の利用をすべて直ちに停止するには、空の mcp_servers テーブルを配布します。

適用範囲と限界

識別情報を許可リストに登録しても、サーバーのツール、上流のデータ、認証情報、起動環境の安全性が確認できたことにはなりません。ローカルの stdio MCP プロセスは、ローカルコマンドのサンドボックス外で動作します。実行ファイルと引数の照合では、サーバーのアクセスを制限したり、環境設定を利用したコードの読み込みを防いだりすることはできません。起動時の条件全体とサーバーの権限は別途レビューしてください。MCP の識別情報に関する要件を参照してください。

セキュリティチームがエンドポイントやネットワーク上での Codex の動作を把握する必要がある場合に使います。実行イベント、ツールイベント、承認の判断、ワークスペースの監査記録、ネットワークログを突き合わせて調査できます。

期待する結果

セキュリティチームが、モデル自身の説明に頼らず、Codex の実行、ツール使用の判断、承認、ワークスペースの監査記録、実際の外向き通信を関連付けられます。

検証に使う 4 つの情報源

1. Codex OpenTelemetry：実行、API、モデル、サンドボックス、承認、ツールに関するイベント

2. 管理対象のライフサイクルフック：ツールの使用や権限リクエストに関するエンドポイント側の記録

3. ネットワークプロキシまたはゲートウェイのログ：実際の DNS/HTTP の接続先と接続結果

4. Compliance API：ワークスペース単位の監査・調査記録

いずれか 1 つの情報源だけでネットワーク全体を監視することはできません。

設定

1. プロンプトの原文を記録しないようにして、Codex OpenTelemetry のログをコレクターに送信します。

   [otel]
   environment = "enterprise"
   log_user_prompt = false
   
   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

   クライアントを起動する前に、承認済みのシークレットマネージャーまたはプロセスの環境を通じて、Codex プロセスに OTLP_TOKEN を渡します。配布する TOML ファイルやソース管理にはトークンを含めないでください。

   Codex は会話の開始、API リクエスト、ストリーミングイベント、プロンプトのメタデータ、ツール使用の判断、ツールの実行結果を出力できます。詳細設定を参照してください。

2. OTel はプロジェクトローカルの設定とは別に構成します。プロジェクトの .codex/config.toml ファイルではテレメトリの送信先を上書きできません。

3. SessionStart、PreToolUse、PermissionRequest、PostToolUse、Stop、SessionEnd に管理対象のライフサイクルフックを追加します。

4. フックスクリプトを管理者が管理するディレクトリにインストールします。ユーザー、プロジェクト、プラグインのフックを無視する場合は、allow_managed_hooks_only = true を設定します。

5. サンドボックス内のコマンドの通信を、独立してログを記録するプロキシ経由にします。OTel はツールが実行されたことを記録し、プロキシはサブプロセスが接続を試みた宛先を記録します。

6. ウェブ検索、アプリ、コネクタ、MCP サーバー、ブラウザのアクティビティ、Codex Cloud には、それぞれ別途テレメトリを設定します。ローカルコマンドのプロキシルールは、これらには自動的に適用されません。

7. Compliance API がサポートする記録を SIEM にストリーミングし、組織の保存期間とリーガルホールドの管理方針を適用します。Compliance API と監査イベントを参照してください。

8. ユーザーまたはサービスアカウント、ホストまたはランナー、会話 ID、モデル、クライアントのバージョン、権限プロファイル、承認の判断、接続先、ツール名を関連付けます。

検証

管理されたテストセッションで、次の操作を実行します。

• 読み取りを許可したファイルを 1 つ読み取ります。

• 読み取りをブロックしたファイルを 1 つ読み取ろうとします。

• 許可したコマンドを 1 つ実行します。

• ブロック対象の外向きリクエストを 1 回試します。

• 承認をリクエストし、拒否の応答を受け取ります。

• セッションを終了します。

情報源ごとに次の結果を確認します。

• OTel に実行イベントとツールイベントが記録されています。

• フックの記録からセッションのライフサイクルを確認できます。

• プロキシログに、許可された接続先とブロックされた接続先が記録されています。

• コンプライアンス記録の取り込み処理が、サポート対象の記録を受信しています。

• SIEM がこれらの記録をユーザーまたはワークロードと関連付けています。

ロールバック

以前の設定に戻してエクスポーターとフックを無効にします。テレメトリをロールバックする際も、独立したプロキシのログ記録は維持してください。

適用範囲と限界

Codex のテレメトリが、すべてのコマンド引数、出力の全バイト、すべてのネットワークパケットを記録すると保証しないでください。各層で記録できる範囲を明文化してください。

Codex のインターネットアクセスを禁止するか、承認済みの接続先だけに制限する場合に使います。設定する環境に合わせてローカルまたはクラウドの手順を選んでください。それぞれのポリシーが適用される範囲は異なります。

期待する結果

選択した設定に応じて、Codex はインターネットにアクセスできなくなるか、承認済みのドメインにのみ接続できます。Codex Cloud（レガシー）環境では、HTTP メソッドも制限できます。

現行の Codex Cloud の設定

1. no-internet-review、approved-dependencies-build、cyber-lab など、信頼レベルごとに環境を分けて作成します。

2. 環境設定で、パブリックインターネットへのすべてのアクセスを有効化 と パッケージマネージャーのドメインを有効化 をオフにします。

3. パブリックインターネットへのアクセスが必要な場合は、追加で許可するドメイン に承認済みのホスト名を正確に指定します。未承認の公開接続先を許可する HTTP シークレット は削除します。VPN 外のパブリックインターネットへのアクセスをブロックするには、このリストを空にし、公開接続先を許可する HTTP シークレット を削除します。

4. 設定を保存し、セットアップ中にサービスをテストします。環境を公開または再公開し、新しいタスクで承認済みと未承認の接続先へのアクセスをテストします。セットアップスクリプトは別途レビューしてください。依存関係のバージョンを固定し、承認済みのミラーを優先し、未レビューの実行ファイルのダウンロードは避けます。

サービスへの接続を参照してください。現行の Codex Cloud の設定には、レガシー版にある HTTP メソッドの選択機能はありません。

Codex Cloud（レガシー）の設定

1. エージェントのインターネットアクセスが不要な場合は オフ のままにします。レガシー版ではデフォルトでエージェントの実行フェーズのインターネットアクセスをブロックしますが、セットアップスクリプトは依存関係をインストールするためにインターネットにアクセスできます。

2. エージェントにインターネットアクセスが必要な場合は オン にし、許可リストを必要最小限に絞ります。なし を選んでから、ドメインを正確に指定して追加します。

3. ダウンロードのみのワークフローでは、GET、HEAD、OPTIONS のみを許可します。これにより POST、PUT、PATCH、DELETE などの他のメソッドがブロックされます。エージェントの実行フェーズの制限はセットアップスクリプトのインターネットアクセスには適用されないため、スクリプトは別途レビューしてください。

レガシー版のエージェントのインターネットアクセスを参照してください。これらのプリセットと HTTP メソッドの制御はレガシー版のクラウドにのみ適用されます。

ローカルの Codex の設定

1. 管理者が管理する requirements.toml で承認済みのネットワークプロファイルを定義して選択し、ユーザーが使えるプロファイルをそれだけに制限します。

   default_permissions = "corp-build"
   
   [allowed_permission_profiles]
   "corp-build" = true
   
   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"
   
   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false
   
   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. 管理設定に従って、レビュー済みの要件一式を配布します。名前付きプロファイルを定義しただけでは有効になりません。default_permissions でそのプロファイルを選択し、許可リストで他のプロファイルの選択を防ぎます。

3. 同じ要件一式で管理対象のプロキシを有効にし、ドメインの制限を強制してユーザーが許可範囲を広げられないようにします。プロキシとネットワークを有効にしたプロファイルは一緒に配布してください。プロキシが有効でない状態でネットワークを有効にしたプロファイルを使うと、ドメインルールが強制されず、ネットワークへの直接アクセスが許可されます。

   注意： [experimental_network] は試験的な機能で、変更される可能性があります。広く展開する前に、サポート対象のローカルクライアントの各バージョンと OS で検証してください。Windows のサポートには制限があります。自社環境で制限が強制されることをテストするまでは、Windows ユーザーにこのポリシーを適用しないでください。

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true
   
   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. ワークフローに必要な場合を除き、ローカルポートへのバインドは無効のままにします。プライベートネットワークの接続先へのアクセスは別途設定してください。ドメインを許可しただけでは、そのドメインのプライベートアドレスまで承認したことにはなりません。ネットワークアクセス要件を参照してください。

5. ウェブ検索、アプリ、MCP サーバー、ブラウザのアクティビティ、Codex Cloud は別途設定します。ローカルのサンドボックスルールでは制御できません。

検証

• 承認済みのドメインにリクエストを送信し、成功することを確認します。

• 未承認のドメインにリクエストを送信し、ブロックされることを確認します。

• localhost、プライベート IP、クラウドのメタデータエンドポイントにリクエストを送信します。明示的に承認されていない限り、それぞれのリクエストがブロックされることを確認します。

• Codex Cloud（レガシー）で、許可済みのドメインに POST リクエストを試します。GET、HEAD、OPTIONS のみを許可した場合にリクエストがブロックされることを確認します。

• プロキシまたはゲートウェイのログに、許可されたリクエストと拒否されたリクエストの両方が記録されていることを確認します。

ロールバック

環境のインターネットアクセスをオフに戻すか、以前のドメインポリシーを復元します。無制限のインターネットアクセスに戻すことは避けてください。

適用範囲と限界

サンドボックスの制限を全面的に解除する権限昇格が承認されると、ローカルコマンドのプロキシを回避できる場合があります。この制限を前提に運用する前に、通常のサンドボックス内のコマンドと、承認を受けて権限を昇格したコマンドを別々にテストしてください。

許可されたドメインにも、プロンプトインジェクション、侵害されたパッケージ、安全でないドキュメントが存在する可能性があります。

Codex に承認済みのソースディレクトリへのアクセスを許可しつつ、シークレット、.env ファイル、SSH キー、無関係なリポジトリへのアクセスを防ぐ場合に使います。ファイルアクセスを制限し、起動したコマンドに渡す認証情報入りの環境変数を減らす方法を説明します。

期待する結果

Codex は承認済みのソースディレクトリで作業できますが、シークレットを含む代表的なファイルは読み取れず、認証情報入りの環境変数を広範に継承することもありません。

設定

1. ワークスペースプロファイルに、読み取りを拒否するパターンを定義します。

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"
   
   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6
   
   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. 既知の認証情報ディレクトリ、署名鍵、本番設定、隣接するリポジトリの正確なパスを拒否対象に追加します。

3. システムの /etc/codex/config.toml またはユーザーの ~/.codex/config.toml で、起動したコマンドに渡す環境変数を減らします。

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false
   
   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

   これはユーザーが変更できるデフォルト設定であり、強制要件ではありません。継承する変数は減りますが、認証情報ファイル、認証情報ヘルパー、シェルの起動時に読み込む内容、他の ID へのアクセスは防げません。詳細設定を参照してください。

4. 管理者が管理する requirements.toml で制限付きのプロファイルを選択し、そのプロファイルのみを許可します。組み込みプロファイルは、このプロファイルのシークレットファイルへのアクセス拒否設定を継承しません。

   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. クラウド環境に応じて認証情報の受け渡し方法を選びます。

   • 現行の Codex Cloud では、許可された HTTPS サービスに送信する認証情報に HTTP シークレット を使います。プログラムにはプレースホルダーが渡され、セットアップ中やタスク実行中に承認済みの接続先のポート 443 にアクセスすると、プロキシが実際の値に置き換えます。認証情報の実値はローカルプロセスやファイルには配置されません。環境変数に直接設定した値はプログラムから参照できます。環境変数とネットワークシークレットを参照してください。
   • Codex Cloud（レガシー）では、セットアップ時の認証にシークレットを使用でき、エージェントの実行フェーズの前に削除されます。環境変数はチャットの終了まで保持されます。レガシー版のクラウド環境を参照してください。

6. エージェントに認証が必要な場合は、独立したブローカーを使い、対象と操作を厳密に限定した短期認証情報を発行します。推奨設定を参照してください。

検証

無害な検証用ファイルを作成します。

.env.test
test-key.pem
.aws/credentials
.kube/config

次に、Codex に以下の操作を依頼します。

• 通常のファイルの読み取り

• 各検証用ファイルの読み取り

• シークレットの再帰検索

• コマンド実行環境の環境変数の出力

• 隣接するリポジトリの読み取り

通常のファイルは読み取れ、拒否対象のファイルや隣接するリポジトリにはアクセスできず、除外した変数がコマンド実行環境に含まれないことを確認します。

ロールバック

以前のプロファイルに戻します。ワークフローの失敗を調査している間も、シークレットを含むことが確かなファイルへのアクセス拒否は維持してください。

適用範囲と限界

ファイルシステムでアクセスを拒否しても、プロンプトに貼り付けたシークレット、読み取り可能なソースにコミットしたシークレット、コネクタが返したシークレット、モデルがアクセスできるログに書き込んだシークレットは削除されません。

git push、デプロイ、データベースのマイグレーション、クラウド CLI コマンドなどの操作に実行前の承認が必要な場合に使います。どのコマンドでレビューを求め、どのコマンドを禁止するかを決め、それぞれのルールを設定します。

期待する結果

慎重な扱いが必要なコマンドは、モデルが妥当と判断した場合でも、必ず承認待ちになるか、実行が禁止されます。

設定

1. 承認を求めるコマンドと、禁止するコマンドを決めます。

2. 管理者が強制するコマンドルールを追加します。

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

   要件のルールでは、コマンドの承認を求めるか、コマンドを禁止できます。コマンドを許可することはできません。管理設定を参照してください。

3. リスクの高いプロファイルでは、シェルラッパーによって慎重な扱いが必要なコマンドが見えにくくなる場合に、同じ prefix_rules 配列にシェルラッパーのエントリを追加します。

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

   シェルラッパーを対象にすると承認要求が頻繁に発生するため、必要な場合に限って使ってください。

4. 人によるコマンドの承認が必要な場合は、次の設定を強制します。

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

   自動レビューは承認リクエストのレビュー担当を変える仕組みです。危険な操作を必ず防げるという保証はありません。自動レビューを参照してください。

5. PermissionRequest、ツール使用の判断、ツールの実行結果のイベントをセキュリティパイプラインに送信します。

検証

• git status を実行します。承認プロンプトが表示されないことを確認します。

• git push を実行します。承認プロンプトが表示されることを確認します。

• terraform apply を実行します。承認プロンプトが表示されることを確認します。

• kubectl delete pod test を実行します。承認プロンプトが表示されることを確認します。

• rm -rf test-directory を実行します。コマンドが禁止されることを確認します。

• 承認リクエストを 1 件拒否します。コマンドが実行されず、拒否がログに記録されることを確認します。

• クライアントを再起動し、検証を繰り返します。ルールが引き続き強制されることを確認します。

ロールバック

以前の要件一式に戻します。トークンのパターンが広すぎる場合は、その種類のコマンドを丸ごと制限対象から外さず、パターンを絞り込んでください。

適用範囲と限界

プレフィックスルールだけでは、OS のポリシーを網羅的に適用できません。サンドボックス、最小権限の OS アカウント、ネットワーク制限、クラウド IAM、ブランチ保護、デプロイの承認、データベースの認可と組み合わせてください。

使用する設定レシピ： 権限プロファイルとフルアクセスの制限、シークレットと無関係なリポジトリの保護、慎重な扱いが必要なコマンドの承認

開発者には正当な本番アクセス権があり、Codex を開発に活用しながら、レビューを経ない本番変更を防ぎたい場合に使います。

• 承認済みのワークスペースプロファイルを定義し、許可するプロファイルと承認ポリシーを強制します。ユーザーが上書きできないよう、これらの設定を管理者が強制する要件として配布します。

• 権限を抑えた別の ID で Codex を実行するか、本番の書き込み用認証情報へのアクセスも取得もできない環境で実行します。開発者は、別途認可されたワークフローで引き続き本番環境にアクセスできます。

• 起動したコマンドに渡す環境変数を最小限にします。エージェントに認証が必要な場合は、独立したブローカーを使い、対象と操作を厳密に限定した短期認証情報を発行します。

• 承認プロンプトが必要なコマンドと、禁止するコマンドを決めます。git push、terraform apply、Kubernetes の変更、データベースのマイグレーションなど、影響が大きいと判断したコマンドには人による承認を必須とし、決して実行してはならないコマンドは禁止します。

• 本番環境の IAM、ブランチ保護、デプロイの承認は、Codex から独立して強制します。

権限プロファイルの制限と人によるレビューの必須化

管理者が管理する requirements.toml で、組み込みのワークスペースプロファイルと読み取り専用プロファイルを許可し、承認が必要な操作にはユーザーによるレビューを必須とします。

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

ワークスペースプロファイルでは、サンドボックス内でワークスペースの作業を行えます。より限定的な作業には読み取り専用プロファイルを使えます。フルアクセスのプロファイルは許可リストに含まれていません。

クライアントで要件に適合する設定を明示する必要がある場合は、クライアント設定に approval_policy = "on-request" を指定します。on-request では必要に応じて承認プロンプトを表示できますが、すべてのコマンドで承認を求めるわけではありません。レビューが必要な操作には明示的なルールを追加し、本番環境の認可は独立して維持してください。

管理対象のプロファイル許可リストには Codex 0.138.0 以降が必要です。旧クライアントでは、ドキュメントに記載された従来のサンドボックスモードの要件を使い、テストしてください。

試験導入した各クライアントを再起動し、承認済みのプロファイルが機能し、許可されていないフルアクセスのプロファイルが拒否されることを確認します。

Codex の実行 ID と本番認証情報の分離

デバイス管理システムまたは開発環境のプロビジョニングシステムで、Codex 専用のユーザー、コンテナ、または開発ホストを作成し、必要なソースと開発用サービスにのみアクセスを許可します。開発者の本番用認証情報ファイル、トークンヘルパー、キーチェーンをその環境にマウントせず、実行 ID が本番の書き込みロールを取得できないようにします。

エージェントにサービスへのアクセスが必要な場合は、組織の認証情報ブローカーが、開発用リソースと操作を限定した短期認証情報を発行するよう設定します。開発者は、別途認可された本番用ワークフローで通常の ID を使えます。

たとえば AWS IAM では、ロール を開いて Codex の開発用ロールを選び、許可 で次のようなレビュー済みのインラインポリシーを追加します。アカウントとロールは自社のものに置き換えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

この例では指定したロールの引き受けを拒否しますが、他のロールの引き受けは拒否しません。本番環境への直接の権限も削除し、他の本番用ロールと認証情報の取得元を制限したうえで、信頼ポリシーと組織レベルの制御をレビューしてください。

実際に本番環境を変更せず、代表的な開発権限と本番権限について開発用ロールをテストしてください。AWS IAM ロールポリシーの例を参照してください。

シェル環境の最小化

システム全体の初期設定には /etc/codex/config.toml、個別ユーザーの設定には ~/.codex/config.toml を使い、起動したコマンドが継承する環境変数を設定します。

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

これは変更可能なデフォルト設定であり、認証情報へのアクセス制限を強制するものではありません。ユーザー設定、シェルの起動処理やスナップショット、認証情報ヘルパー、その他の取得元から認証情報にアクセスできる可能性があります。

ワークフローに支障がない場合は、requirements.toml に次の任意の制限を設定して、ログインシェルとシェルのスナップショットを無効にします。

allow_login_shell = false

[features]
shell_snapshot = false

ログインシェルの初期化に依存するワークフローもあるため、これらの設定は試験導入してください。

フィルターに一致する無害なテスト用変数を設定して Codex を起動し、起動したコマンドの環境を調べます。ログインシェルを無効にした場合は、その起動要求が拒否されることも確認します。実行 ID が実際の本番認証情報にアクセスできないことは、別途検証してください。シェル環境ポリシーを参照してください。

影響が大きいコマンドの承認要求

組織で使うコマンドに合わせて要件にルールを追加します。次に例を示します。

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

決して実行してはならないコマンドには forbidden を使います。実際のデプロイツールやマイグレーションツールに合わせて、パターンを置き換えるか追加してください。

これらのルールはコマンドのプレフィックスを照合するため、同等の操作をすべて網羅するわけではありません。絶対パス、ラッパー、異なる引数の順序、他のクライアントやツールは別々にテストしてください。

使い捨てのテスト対象で通常のコマンドを実行した後、リストにある操作を要求します。承認リクエストを拒否し、操作が実行されなかったことを確認してください。コマンドルールの強制を参照してください。

Codex 外でのリポジトリとデプロイの承認の強制

ソース管理プラットフォームで、main などの本番ブランチを保護します。変更のレビューと必要な承認、ステータスチェックを必須とし、それらの要件を回避できるロールを確認してください。デプロイの承認は該当するデプロイシステムで、データベース権限はデータベース自体で設定します。

使い捨てのリポジトリで、レビュー済みの変更は反映でき、認可されていない直接プッシュは拒否されることを確認します。これらの制御は、Codex を通じて操作を要求したかどうかにかかわらず適用されます。

検証

使い捨てのテスト対象で、次の項目を確認します。

• ワークスペース内で通常のタスクを実行し、成功することを確認します。

• 慎重な扱いが必要な代表的なコマンドを試し、承認リクエストを拒否します。拒否したコマンドが実行されないことを確認します。

• Codex の実行 ID が本番の書き込み権限を取得できないことを確認します。

• クライアントを再起動し、検証を繰り返します。

適用範囲と限界

プレフィックスルールだけでは、OS のポリシーを網羅的に適用できません。サンドボックス、最小権限の OS アカウント、ネットワーク制限、クラウド IAM、ブランチ保護、デプロイの承認、データベースの認可と組み合わせてください。

使用する設定レシピ： シークレットと無関係なリポジトリの保護、ネットワーク接続先の制限、承認済みの MCP サーバーのみ許可、慎重な扱いが必要なコマンドの承認

開発者が社内リポジトリで Codex を使う際に、公開リポジトリや公開コードスニペットなど、未承認の宛先にコードを送信してしまうリスクを抑えたい場合に使います。

• 既知の認証情報ディレクトリと無関係なリポジトリの正確なパスを拒否対象に追加し、起動したコマンドに渡す環境変数を最小限にします。

• エージェントにインターネットアクセスが必要な場合は、承認済みのドメインに絞った許可リストを使います。承認済みの名前と識別情報を持つ MCP サーバーのみを許可し、git push など、公開に使う特定のコマンドはレビューを必須にするか、実行を拒否します。

• ソース管理のフックと権限、公開リポジトリやコードスニペットのポリシー、組織に適したデータ損失防止策を使います。

無関係なリポジトリと認証情報ファイルへのアクセス拒否

管理者が管理する requirements.toml に、ローカルのエージェントが読み取ってはならないパスを正確に指定します。

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

例のパスは、管理対象のデバイスに実在するパスに置き換えてください。この管理設定による読み取り拒否は、許可されたすべての権限プロファイルに適用されます。特定のカスタムプロファイル内にだけ設定した読み取り拒否は、別のプロファイルを選んだユーザーには適用されません。既知の正確なパスを優先し、glob パターンを使う場合は、対象となるディレクトリの深さでテストしてください。

ネイティブの Windows 環境では、管理対象の deny_read はファイルを直接扱うツールに適用されますが、それだけではシェルのサブプロセスによる読み取りを防げません。OS の実行 ID とファイルのアクセス制御リストも使用してください。

拒否対象の場所に無害な検証用ファイルを作成します。許可されたすべてのプロファイルで、これらのファイルの直接読み取りとシェル経由の読み取りがともに拒否され、承認済みのソースファイルは読み取れることを確認してください。管理設定による読み取り拒否要件を参照してください。

認証情報を含むシェル変数の最小化

/etc/codex/config.toml または ~/.codex/config.toml で、継承する環境変数を限定します。

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

この設定で継承する変数は減りますが、ユーザーが設定を変更できます。認証情報ファイル、認証情報ヘルパー、シェルの起動時に読み込む内容、他の ID へのアクセスは防げません。

必要に応じて、管理者は requirements.toml に次の制限も追加し、試験導入して開発者のワークフローへの影響を評価できます。

allow_login_shell = false

[features]
shell_snapshot = false

検証用のダミー変数と、最小権限を持つ別の実行 ID を使ってテストします。実際の認証情報は使わないでください。シェル環境ポリシーを参照してください。

ローカルコマンドのネットワーク接続先を承認済みの宛先に限定

サンドボックス内のローカルコマンドにネットワークアクセスが必要な場合は、以下のプロファイルと管理対象プロキシの両方の設定を requirements.toml に統合します。ドメインは承認済みのエンドポイントに置き換えてください。

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

ネットワークを有効にしたプロファイルはサンドボックス内のコマンドに通信経路を提供し、管理対象のプロキシは接続先を制限します。両方を一緒に配布してください。ネットワークを有効にしたプロファイルだけでは、想定した管理対象プロキシによる接続先の制限は適用されません。インターネットアクセスが不要な場合は、ネットワークアクセスを無効のままにしてください。

現行の domains テーブルと従来の allowed_domains または denied_domains の設定を併用しないでください。既存のポリシーを移行してテストしてください。

クライアントを再起動し、承認済みのエンドポイントに接続でき、未承認のエンドポイントはブロックされることを確認します。

これらの設定は試験的なものです。OS とクライアントでサポートされていることを検証し、承認済みのホストがプライベートアドレスに名前解決される場合は、プライベートネットワークへのアクセスを別途設定してください。サンドボックスの制限を全面的に解除する権限昇格が承認されると、コマンドのプロキシを回避できる場合があります。

ローカルコマンド用のネットワーク制御は、ウェブ検索、アプリ、MCP サーバー、ブラウザのアクティビティ、クラウド環境には適用されないため、それぞれ別のポリシーが必要です。また、承認済みのホスティングドメインにも公開リポジトリや公開コードスニペットが存在する場合があるため、接続先の許可リストだけではコンテンツを保護できません。ネットワークアクセス要件を参照してください。

クラウド環境のネットワークの個別設定

現行の Codex Cloud の画面で環境設定を開きます。パブリックインターネットへのすべてのアクセスを有効化 と パッケージマネージャーのドメインを有効化 をオフにします。パブリックインターネットへのアクセスが必要な場合は、追加で許可するドメイン に承認済みのホスト名を正確に指定します。未承認の公開接続先を許可する HTTP シークレット は削除します。VPN 外のパブリックインターネットへのアクセスをブロックするには、このリストを空にし、公開接続先を許可する HTTP シークレット を削除します。設定を保存し、環境を公開または再公開して、新しいタスクでテストします。

サービスの認証と機能は別途レビューしてください。

レガシー版の Codex Cloud では、環境ごとにエージェント専用のインターネット設定があり、許可するドメインと HTTP メソッドを制御できます。セットアップスクリプトのインターネットアクセスには別のルールが適用されます。

実際に使用する環境のバージョンでテストしてください。サービスへの接続とレガシー版のインターネット設定を参照してください。

MCP サーバーの制限と Git プッシュ前の承認要求

requirements.toml では、承認済みの識別情報を持つローカルの MCP サーバーのみを許可します。次に例を示します。

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

実際のサーバーは、ユーザー設定または管理対象のデフォルト設定の config.toml に別途設定します。要件に一致する名前と URL、およびサーバーが必要とする認証を使ってください。

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

要件は一致するサーバーを許可するだけで、サーバーを作成するものではありません。そのサーバー自身のアクセス権とツールをレビューしてください。

承認済みのサーバーが接続でき、名前または URL が異なるサーバーは許可されないことを確認します。

代表的な公開コマンドの実行前にレビューを求める管理対象のコマンドルールを追加します。

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

人によるレビューが必要な場合は、トップレベルの要件として allowed_approval_policies = ["on-request"] と allowed_approvals_reviewers = ["user"] を併用します。

テスト用のプッシュを拒否し、実行されないことを確認します。

プレフィックス照合では、すべてのラッパー、API クライアント、アプリ、その他の公開経路を網羅できません。

ソース管理と DLP による外部公開の制限

ソース管理プラットフォームが対応している場合は、公開リポジトリの作成を制限し、リポジトリの公開範囲を変更できるユーザーを限定します。特権ユーザーが制限を回避できる権限を確認してください。組織の設定がすべての宛先に適用されるわけではないため、個人アカウント、コードスニペット、外部組織、トークンによるアクセスは別途確認します。

対象のリポジトリでは、変更のレビューを必須とし、ブランチ保護とそれを回避できる権限を確認します。

組織の DLP コンソールで、機密性の高いソースコードを対象とする試験導入用ポリシーを設定します。DLP 製品が実際に対応するアップロード経路やリポジトリへの送信経路を対象とし、アクションをブロックに設定して、動作に影響しないダミーのマーカーでテストします。

ソース管理プラットフォームがサーバー側の制御に対応している場合は、プッシュを受け付けるリポジトリでレビュー済みのフックを設定し、強制します。

認可されたテスト用の宛先を使い、公開される前にブロックされることを確認してください。

検証

• 無害な検証用ファイルを作成し、拒否対象のファイルを読み取ろうとすると失敗することを確認します。

• ネットワークアクセスが有効な場合は、承認済みの接続先へのアクセスは成功し、未承認の接続先はブロックされることを確認します。無効な場合は、ネットワークリクエストがブロックされることを確認します。

• 無害なマーカーと使い捨てのテスト用アカウントまたは宛先を使い、代表的な外部公開の操作を試して、公開前にブロックされることを確認します。

適用範囲と限界

許可されたドメインにも公開コンテンツが存在する可能性があります。ウェブ検索、アプリ、MCP サーバー、ブラウザのアクティビティ、Codex Cloud はローカルのサンドボックスルールでは制御できないため、別途設定してください。

使用する設定レシピ： 権限プロファイルとフルアクセスの制限、承認済みの MCP サーバーのみ許可、ネットワーク接続先の制限、シークレットと無関係なリポジトリの保護、慎重な扱いが必要なコマンドの承認

Codex がリポジトリで作業しているときや、ユーザーがローカル設定を変更したときにも、Codex に対する制限を維持したい場合に使います。

• サポートされている権限、承認、MCP、ネットワーク、コマンドの制限を、管理者が強制する要件として配布します。

• フックスクリプトを管理者が管理するディレクトリにインストールします。ユーザー、プロジェクト、プラグインのフックを無視する場合は、管理対象のフックのみを使用する設定にします。

• OS とデバイス管理の仕組みでポリシーファイルと設定の配布経路を保護します。これらの保護措置を変更できる権限を持たない状態で Codex を実行してください。

• 対象のクライアントと環境ごとに、実際に適用されている設定をレビューします。

プロファイル、承認、サーバーの識別情報、コマンドに関する要件の強制

ユーザーやリポジトリ側で編集できる設定に依存せず、レビュー済みの設定を管理者が管理する requirements.toml に統合します。次に例を示します。

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

この例では 2 つのプロファイルを許可し、承認が必要な場合は人によるレビューを必須とします。また、識別情報が一致する MCP サーバーを許可し、特定のプレフィックスに一致するコマンドには承認を求めます。

MCP サーバー自体は別途設定し、組織で慎重な扱いが必要な他のコマンドのパターンも追加してください。必要に応じて、全体に適用するファイル制限とネットワーク制限を追加します。要件で制約できるのはサポート対象の設定であり、Codex 外の ID、サービス、接続先の制御に代わるものではありません。

管理対象のプロファイル許可リストには Codex 0.138.0 以降が必要です。

試験導入したクライアントで、許可されていないプロファイルの選択、制限対象のユーザー設定またはプロジェクト設定の変更、許可リストにない識別情報での MCP サーバーの利用を試します。各操作が拒否されるか、再起動後も制限が維持されることを確認してください。テスト用コマンドの承認を拒否し、コマンドが実行されないことも確認します。

管理対象のファイルシステム制限とネットワーク制限の追加

許可されたすべてのプロファイルで機密性の高いローカルファイルの読み取りを拒否するには、次のテーブルを requirements.toml に追加し、例のパスを組織のパスに置き換えます。

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

サンドボックス内のローカルコマンドにネットワークアクセスが必要な場合は、ネットワークを有効にした許可対象のプロファイルと、管理対象の接続先を一緒に定義します。

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

先ほどのデフォルトの :workspace に代えてこのプロファイルポリシーを選択するか、両方のプロファイルを使う場合は両方の名前を許可リストにまとめてください。キーやテーブルを重複して貼り付けないでください。コマンドにネットワークアクセスが不要な場合は無効のままにします。

無害なファイルを使い、正確に指定したパスで読み取りが拒否されることを確認します。承認済みと未承認の接続先も検証してください。

ネイティブの Windows 環境では、管理対象の deny_read だけではシェルのサブプロセスによる読み取りを制限できないため、ファイルのアクセス制御リストも使ってください。

ローカルコマンドのネットワーク設定は、他のクライアント、アプリ、コネクタ、クラウドでの実行には適用されません。

管理対象フックのインストールと強制適用

管理者がレビュー済みのフックプログラムを /etc/codex/hooks/pre_tool_use_policy.py など root が管理するディレクトリ内のパスにインストールし、Codex を実行するユーザーがファイルやディレクトリを変更できないようにします。requirements.toml でフックを有効にし、ユーザー、プロジェクト、セッション、プラグインのフックは無視するように設定します。

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

この要件はフックを登録しますが、インストールは行いません。ローカルの macOS で統合テストを行うには、次の内容を pre_tool_use_policy.py として保存し、管理者が後述のコマンドでインストールします。

このプログラムがブロックするのはテスト用のマーカーを含むコマンドのみです。実際の保護に使う前に、レビュー済みの組織固有のポリシーに置き換えてください。対象環境に /usr/bin/python3 が存在することを確認し、必要に応じてインタープリターのパスを調整します。

1
2
3
4
5
6
7
8import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

ローカルクライアントを再起動し、次の項目を確認します。

• 無害な Bash コマンドが実行されることを確認します。

• CODEX_HOOK_TEST_DENY を含むコマンドがブロックされることを確認します。

• Codex を実行するユーザーがポリシーとその依存関係を変更できないことを確認します。

allow_managed_hooks_only は、管理対象外のユーザー、プロジェクト、セッション、プラグインのフックをすべてスキップするため、他のワークフローに影響する可能性があります。

Bash の照合ルールはすべてのツールを対象とするわけではなく、起動済みのプロセスに後から渡す入力も対象外です。エラー、タイムアウト、形式が不正なフック応答が発生した場合、ツール呼び出しがそのまま実行されることがあります。

クラウドで実行を制御する Work モードでは、サポートされるフックハンドラーが異なります。OS とサービスの独立した保護措置を維持してください。管理対象のフックとフックの動作を参照してください。

ポリシーと配布経路の保護

macOS では、管理者がレビューと統合を済ませた要件ファイルを root 所有の親ディレクトリに配置し、Codex を実行するユーザーがファイルに書き込めないようにできます。

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

Linux では適切な管理者グループを使います。Windows では管理者が管理するアクセス制御リストで ProgramData ディレクトリとファイルを保護します。MDM またはクラウドのポリシーを変更できるユーザーを限定し、変更をレビューして、ロールバック用のコピーを保管してください。

管理者権限のない試験導入用アカウントで、ポリシー、親ディレクトリ、管理対象のフックプログラムを変更できないことを確認します。ユーザー設定またはプロジェクト設定で制限を緩める設定を試し、Codex を再起動して、強制された動作が維持されることを確認してください。

すべてのクライアントが同じポリシーを読み込むと想定せず、対象のクライアントと環境ごとにテストしてください。

検証

管理者権限のないテスト用 ID で、次の項目を確認します。

• 管理対象のポリシーの編集を試します。管理対象のファイルを変更できないことを確認します。

• ユーザー設定またはプロジェクト設定で制限を緩めようとします。制限を緩める設定が拒否されるか、元の制約が引き続き適用されることを確認します。

• クライアントを再起動し、制限が引き続き適用されることを確認します。

適用範囲と限界

ホスト上で十分な管理者権限を持つユーザーやエージェントは、周辺の保護措置を変更できる可能性があります。ユーザーが編集できる設定だけでは、管理者が管理する要件の代わりにはなりません。