Codex のセキュリティ境界実践: 権限、サンドボックス、秘密情報漏えい対策

プロジェクトのルートに .env ファイルがあり、そこにはデータベースのパスワードとサードパーティ API key が入っています。Codex を開き、テストコードのリファクタリングを頼もうとしています。ドロップダウンには read-only、workspace-write、danger-full-access の 3 つがあります。どれを選ぶべきでしょうか。

workspace-write を選んだあと、Codex が npm install の実行承認を求めてきました。そこで承認を押します。では、package.json にある見落としがちな postinstall スクリプトが、このタイミングで環境変数を読んだり、知らないサービスへリクエストを送ったりしないと言い切れるでしょうか。

Codex を GitHub Actions に入れて、PR review を自動化します。workflow には OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} と書きました。secrets だから安全だと思うかもしれません。しかし同じ job で動くテストスクリプト、サードパーティ action、依存関係の install hooks も、その key を読める可能性があります。

この 3 つの境界が、これらの問いに直接答えます。指示は権限ではありません。承認は隔離ではありません。sandbox は監査ではありません。ここから、ローカル、Cloud、CI の 3 つの場面で使える最小権限チェックリストを整理します。

権限は口頭ルールでは守れない: sandbox、approval、permission profile の 3 層境界

AGENTS.md に「.env ファイルを読まない」と 1 行書けば、Codex が機密情報へアクセスできなくなると思っている人は少なくありません。しかしこれは権限制御ではなく、プロジェクトルールによるガイドです。本当のセキュリティ境界は 3 層で作ります。spawned commands の範囲を縛る sandbox、いつ止まって確認するかを決める approval policy、そして強制アクセス制御である permission profile です。

Codex の安全性は 1 層だけでは足りません。sandbox は git、パッケージマネージャ、test runner などの spawned commands が何へアクセスできるかを決めます。approval policy は重要操作の前に Codex があなたへ承認を求めるかを決めます。permission profile は "**/*.env" = "deny" のようなルールを実際に書ける設定層です。この 3 層が重なって、はじめて実際の権限になります。

sandbox モード比較: read-only、workspace-write、danger-full-access

sandbox モード	定義	向いている場面	リスク
read-only	ファイルの読み取りのみ許可し、書き込みやコマンド実行は許可しない	コードレビュー、アーキテクチャ整理、ドキュメント生成、CI の読み取り専用チェック	runner 上のすべての secrets を守れるわけではない。処理自体は runner 上で動く
workspace-write	active workspace への書き込みを許可し、ネットワークはデフォルトで閉じる	ローカルの日常開発、コード変更、テスト実行	workspace 配下の全ファイルをデフォルトで読める可能性があり、.env も含まれる。deny glob が必要
danger-full-access	ファイルシステムとネットワークの境界を外す	isolated CI runner/container、完全に管理されたテスト環境	~/.ssh、/tmp、環境変数、ローカルサービスにアクセスできる。日常のデフォルトにしない

sandbox が縛るのは Codex の組み込みファイル操作だけではありません。spawned commands も対象です。git、パッケージマネージャ、test runner は同じ sandbox 境界を継承します。プラットフォーム前提も信頼性に影響します。Linux/WSL2 は bubblewrap または user namespace、macOS はシステム sandbox に依存し、Windows では sandbox の利用条件が変わります。

approval policy は、いつ止まって聞くかを決めます。

approval policy	定義	よくある組み合わせ	実際の権限
on-request	操作前に一時停止し、承認を求める	ローカル自動化の workspace-write + on-request	低リスク。ファイル書き込み、コマンド実行、ネットワーク要求を人が確認できる
never	対話的な承認を出さず、そのまま実行する	CI 読み取り専用チェックの read-only + never、管理環境の danger-full-access + never	高リスク。permission profile なしの workspace-write + never は特に危険

低リスクな組み合わせは read-only + never（CI 読み取り専用）と workspace-write + on-request（ローカル開発）です。高リスクな組み合わせは danger-full-access + never で、管理済み環境だけに限定します。

permission profile 設定: filesystem deny、network rules

permission profile は強制アクセス制御であり、口頭ルールではありません。filesystem 権限は read/write/deny をサポートします。より具体的なルールが広いルールを上書きし、deny が優先されます。

.env deny glob の設定例です。

{
  "filesystem": {
    "rules": {
      "**/*.env": "deny",
      "**/.env.local": "deny",
      "**/secrets/**": "deny",
      "workspace/**": "write"
    }
  }
}

この設定により、workspace-write でも .env ファイルは読めません。workspace がデフォルトで書き込み可能でも同じです。deny が優先され、具体的なルールが広いルールを上書きします。

network profile では enabled = true と domain allow/deny を設定できます。ここでも deny が優先されます。local/private network にはデフォルトで保護があり、localhost や Docker socket を許可する場合は明示的な例外になります。Docker socket はローカルの escape hatch です。ローカルサービス、コンテナ、ネットワークへ到達できるため、慎重に開けるべきです。

network proxy は、すでに起動したコマンドのネットワークアクセスを制約するもので、単体でネットワーク権限を与えるわけではありません。全体 * allow は広いネットワークアクセスなので慎重に扱います。

ローカル場面の最小権限チェックリスト: 読み取りレビューから full access までの判断基準

ローカル開発では、権限を大きくすれば楽になるとは限りません。承認は一部の操作を止められますが、本当の隔離は sandbox と permission profile が担います。まず最も狭い権限から始め、タスクに応じて段階的に広げます。

権限選択の判断表: read-only を使うとき、workspace-write を使うとき

場面	sandbox モード	approval policy	permission profile	リスク
コードレビュー/アーキテクチャ整理	read-only	never	設定不要	低
日常開発/コード変更	workspace-write	on-request	.env deny を設定	中低
テスト実行/依存関係インストール	workspace-write	on-request	.env deny とスクリプト監査	中
CI 読み取り専用チェック	read-only	never	設定不要	低
CI でファイル書き込みが必要	workspace-write	never	deny を設定し、isolated runner を使う	中高
full access が必要	danger-full-access	never	管理済み環境のみ	高

.env と秘密ファイルを守る設定手順です。

1. 使う permission profile 設定ファイルの場所を確認します（Codex Permissions ドキュメントを参照）。
2. filesystem 権限設定に "**/*.env" = "deny" を追加します。
3. より具体的なルールが広いルールを上書きし、deny が優先されることを確認します。
4. テストします。workspace-write モードで .env を読もうとして、deny されるべきです。
5. 必要に応じて "**/.env.local" = "deny"、"**/secrets/**" = "deny" などを追加します。

口頭制約に頼らないでください。AGENTS.md はガイドであり、強制アクセス制御ではありません。Codex はガイドに従うこともありますが、別の理由で読み取りが起きる可能性もあります。強制できるのは permission profile の deny です。

依存関係インストールのリスク: npm postinstall、pip hooks、Docker socket

依存関係のインストールは、単にファイルをダウンロードするだけではありません。npm/pnpm の postinstall や prepare、pip install の hooks はインストール時に自動実行されます。これらのスクリプトは環境変数を読んだり、ネットワーク要求を送ったり、システムファイルを書き換えたりできます。

リスクのチェックリストです。

• 未知の postinstall が環境変数を読む可能性があります。.env deny を設定していても、postinstall は spawned commands の環境で実行されるため、環境変数に触れる可能性があります。
• ネットワーク要求を送る可能性があります。追加バイナリのダウンロード、統計送信、プライベートリポジトリへの接続などです。
• システムファイルを変更する可能性があります。グローバル設定の書き込みや PATH の変更などです。

監査のすすめです。

1. 先にスクリプトと出所を確認します。package.json の scripts フィールドや pip パッケージの setup.py を見ます。
2. 信頼できるソースを使います。依存関係のバージョンを固定し、未知のバージョンへ自動アップグレードしないようにします。
3. 管理された環境で承認します。ローカル開発では workspace-write + on-request を使い、承認前に Codex が何をインストールしようとしているかを確認します。

Docker socket はローカルの escape hatch です。Docker socket を許可すると、ローカルサービス、コンテナ、ネットワークにアクセスできます。明確に必要なときだけ設定し、デフォルトで開けないでください。

Cloud 場面の境界: setup vs agent phase、secrets のライフサイクル

Cloud task はローカルではなく、OpenAI がホストする隔離コンテナで動きます。sandbox は spawned commands を制約できますが、秘密情報を守る要点は Cloud secrets のライフサイクル設計です。setup phase で利用でき、agent phase の前に削除されます。sandbox は監査ではありません。安全性は層を分けることで作ります。

Cloud container のライフサイクルです。

1. container を作成する
2. repo を checkout する
3. setup script を実行する
4. network 設定を適用する
5. agent がコマンドループを実行する
6. answer/diff を出力する

setup vs agent phase の境界: secrets は setup だけで使う

phase	ネットワークアクセス	secrets の利用	environment variables	依存関係インストール
setup scripts	利用可能	利用可能	全期間存在	インストール可能
agent phase	デフォルトでオフライン	削除済み	全期間存在	デフォルトでオフライン

setup phase ではネットワークを使えて、依存関係をインストールでき、secrets も利用できます。agent phase はデフォルトでオフラインで、secrets は削除済み、残るのは environment variables です。

setup scripts は別の Bash session で実行されるため、export は自動的に agent phase へ引き継がれません。setup 内で export MY_KEY=xxx としても、agent phase はその変数を継承しません。phase 間で渡るのは Cloud secrets と environment variables です。

secrets vs environment variables: 重要な違い

種類	暗号化	利用できる phase	用途	ライフサイクル
environment variables	追加暗号化なし	setup + agent 全期間	非機密設定、パス、スイッチ	container ライフサイクル中ずっと存在
secrets	追加暗号化あり	setup scripts のみ	プライベートリポジトリアクセス、依存関係インストール認証	agent phase 前に削除

secrets は setup scripts だけで使えます。依存関係のインストールやプライベートリポジトリ接続に向いています。agent phase に本番秘密情報を残すべきではありません。environment variables は全期間存在するため、非機密設定に使います。

依存関係インストールの境界です。

• setup phase ではネットワークを使って依存関係をインストールできます。
• agent phase はデフォルトでオフラインです。
• setup scripts は secrets にアクセスできるため、未知のスクリプトが漏えいさせる可能性があります。
• すすめ: 先にスクリプトと出所を確認し、信頼できるソースを使い、setup で未知のスクリプトを実行しないようにします。

container cache は最長 12 時間です。setup、maintenance、env、secrets を変更すると cache invalidation が発生します。

CI 場面と GitHub Action: codex exec、API key の禁忌、official Action の安全策

codex exec のデフォルト sandbox は read-only ですが、多くの人は workflow で OPENAI_API_KEY を job-level environment variable に置いてしまいます。同じ job で実行されるテストスクリプト、サードパーティ action、依存関係の lifecycle scripts は、その key を読める可能性があります。sandbox は監査ではありません。安全性は最小権限と key 保護で作ります。

API key の禁忌: job-level env に置かない

checkout やリポジトリコードを実行する workflow では、OPENAI_API_KEY や CODEX_API_KEY を job-level environment variable にしないでください。リポジトリコード、テスト、依存関係の lifecycle scripts、サードパーティ action は、同じ job では環境変数に触れる可能性があります。

避けるべきことです。

• OPENAI_API_KEY を job-level env に置かない。
• checkout やリポジトリコード実行を行う workflow で job-level key を設定しない。
• auth.json や ChatGPT-managed auth は public/open-source repo workflow に向きません。
• 信頼できないコードを同じ process environment で実行しない。

正しい方法です。

1. 単一 invocation inline: 単一の codex exec invocation だけで CODEX_API_KEY を設定します。

- name: Run Codex
  run: CODEX_API_KEY=${{ secrets.CODEX_API_KEY }} codex exec "review PR #${{ github.event.number }}"

2. official Action proxy: openai/codex-action@v1 の proxy を使います。

- uses: openai/codex-action@v1
  with:
    prompt: "review PR #${{ github.event.number }}"
    sandbox: read-only
    safety-strategy: drop-sudo

CI での danger-full-access は isolated CI runner/container に限ります。デフォルトにしないでください。runner 上のすべてのリソースへアクセスできるためです。

GitHub Action セキュリティチェックリスト: トリガー制限、key 保護、key ローテーション

official Action のパラメータです。

パラメータ	デフォルト値	説明
safety-strategy	drop-sudo	sudo 権限を外す
sandbox	-	read-only、workspace-write、danger-full-access を選ぶ
allow-users	write access ユーザー	特定ユーザーだけが起動できる
allow-bots	-	bot による起動を許可するか

read-only は runner 上のすべての secrets を守れるという意味ではありません。Action は runner 上で動き、ファイルシステムを読み取り専用に制約しているだけです。drop-sudo は sudo 権限を外します。sandbox はタスク完了に必要な最小モードを選びます。

GitHub Action のセキュリティチェックリストです。

• トリガーできる人を制限する。allow-users は特定ユーザーだけにし、allow-bots は慎重に有効化します。
• PR/issue/prompt 入力をサニタイズする。prompt injection を避け、不信な入力をそのまま Codex に渡さないでください。
• API key を守る。job-level env に置かず、単一 invocation inline または proxy を使います。
• Codex を最後のステップで実行する。key の露出時間を減らします。
• 漏えいが疑われる場合は key をローテーションする。先に調査せず、まず止血します。

PR/issue/prompt 入力は信頼できないものとして扱います。PR comment や issue body をそのまま Codex prompt に入れないでください。

秘密情報漏えい対応: 疑わしい漏えいを見つけたあとの最初の一手

漏えいが疑われる場合、最初にすることは原因調査ではなく key ローテーションです。先に止血し、そのあと監査します。sandbox は spawned commands を制約できますが、Codex が key をログ、PR comment、answer に出力することまでは止められません。

秘密情報漏えい対応手順: key ローテーション、監査、失効

第一歩は key ローテーションです。原因を調べる前に、古い key を無効化します。

次の手順です。

1. ログを監査する。key の使用記録を確認し、異常な呼び出しがないか見ます。
2. token を失効させる。古い key が完全に無効になり、有効な session が残っていないことを確認します。
3. 発生源を調べる。Codex log、GitHub Action 出力、依存関係インストールスクリプト、サードパーティ action を確認します。

予防策です。

• API key をフロントエンドコードやリポジトリに入れない。
• API key を job-level env にしない（CI）。
• permission profile で .env deny を使う。
• 定期的に key をローテーションする（OWASP Secrets Management Cheat Sheet が推奨）。

Codex Security の境界: SAST の代わりではなく、patch を自動適用しない

Codex Security は LLM-driven security analysis toolkit で、ephemeral isolated container で動き、構造化された finding と patch 提案を出力します。脆弱性の発見や検証を補助できますが、SAST や人手のセキュリティレビューを置き換えるものではありません。

限界のチェックリストです。

• SAST を置き換えない。
• manual security review を置き換えない。
• proposed patch はユーザーの review が必要で、自動適用されない。
• 用途は発見、検証、提案の補助であり、自動修復ではない。

Codex Security を万能のセキュリティスキャナーとして扱わないでください。AI-driven analysis は一部の問題を見つけられますが、本当の安全性は層で作ります。読み取り範囲、書き込み範囲、ネットワーク、秘密情報、承認、review、失効です。

結論

Codex のセキュリティ境界は 3 層です。sandbox は spawned commands の範囲を制約し、approval policy はいつ止まって聞くかを決め、permission profile は強制アクセス制御を担います。この 3 層が重なって、実際の権限になります。

覚えておきたい 3 つの境界です。

• 指示は権限ではありません。AGENTS.md はガイドであり、強制アクセス制御ではありません。.env や API key を口頭制約で守らないでください。
• 承認は隔離ではありません。approval policy は一部の操作を止められますが、本当の隔離は sandbox と permission profile が担います。
• sandbox は監査ではありません。sandbox は spawned commands を制約できますが、Codex が key をログ、PR comment、answer に出力することは止められません。安全性は層で作ります。

簡易セルフチェックです。

• .env deny glob を設定していますか？
• CI で job-level API key を避けていますか？
• GitHub Action のトリガーできる人を制限していますか？
• 依存関係インストールスクリプトを監査していますか？
• key ローテーション計画がありますか？

セキュリティ境界は論理バグまでは防げません。Codex がすべての権限ルールに従っても、生成コードに bug があることも、テストが失敗することも、rollback が必要になることもあります。diff を確認し、テストを実行し、rollback 案を用意することが、セキュリティ境界の外側にある第二の防線です。

次のステップです。

• 失敗の振り返りと確認フロー: Codex が失敗したときの対応、diff 確認、rollback 方針を理解します。
• codex exec 自動化と CI: CI における非対話モード、workflow 設計、エラー処理を深掘りします。
• AGENTS.md プロジェクトルール: プロジェクトルールの書き方を学びます。ただし、それはガイドであって権限システムではないことを忘れないでください。

関連記事です。

• AI coding ツール全景 2026: AI coding ツールの全体像を理解します。
• GitHub Actions CI 基礎: CI workflow の基本概念を復習します。
• GitHub Actions デプロイ戦略: デプロイにおける secrets の利用境界を理解します。
• フロントエンド API key 漏えいリスク: key をフロントエンドやリポジトリに入れてはいけない背景を確認します。