Codex 安全設定指南

如果員工應通過公司的 ChatGPT 工作區登入 Codex，並且受管理終端上禁止使用個人 ChatGPT 帳戶和 API key 身份驗證，請使用此方案。

預期結果

在公司管理的裝置上，Codex 僅接受通過 ChatGPT 登入公司的 ChatGPT 工作區。

前提條件

• 已核准的 ChatGPT Enterprise 工作區的 UUID。

• 向終端分發 Codex 託管設定的方式。

• 已決定在受管理終端上禁止 API key 身份驗證。

設定

1. 在內部設定儲存庫中記錄已核准的工作區 UUID。

2. 在本機 requirements.toml 中新增強制身份驗證要求：

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

第一個鍵僅允許 ChatGPT 身份驗證；第二個鍵將登入限制在已核准的工作區。請將範例 UUID 替換為你的工作區 UUID。參閱要求參考。

3. 按照設定應放在哪裡中的路徑，通過本機 requirements.toml 或 macOS MDM 要求部署。這些身份驗證要求在憑據載入和雲端策略取得之前生效；Codex 會忽略雲端託管要求中的這些設定。請保護檔案及其父目錄，防止使用者修改。舊版 managed_config.toml 預設值不會強制執行此限制。

4. 試點期間，讓使用者退出登入，或移除此前儲存的個人 Codex 會話。不要假定新策略會追溯性地使現有會話失效。

5. 將登入限制與工作區角色和群組存取權限結合使用。身份驗證控制以哪個身份登入；RBAC 控制該身份可以使用哪些 Codex 功能。參閱身份驗證。

驗證

• 退出 Codex 登入。

• 嘗試使用個人 ChatGPT 帳戶登入。預期：登入個人工作區被拒絕。

• 嘗試使用 Codex API key 登入。預期：API key 登入被拒絕。

• 使用公司帳戶登入已核准的工作區。預期：登入成功。

• 重啟桌面應用、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 執行時權限。它不會將擁有特權的作業系統帳戶變為非特權帳戶。

如果組織需要決定 Codex 可以使用哪些 MCP server，並強制執行核准列表，請使用此方案。

允許某臺伺服器與設定該伺服器是兩個獨立步驟。允許列表條目允許使用匹配的伺服器，但不會建立伺服器設定。請另行設定伺服器，使用匹配的名稱和身份資訊，並設定所需的身份驗證。

預期結果

Codex 僅啟用設定的名稱和身份資訊與企業核准列表匹配的 MCP server。

設定

1. 盤點每臺已核准伺服器的資訊：負責人、用途、傳輸方式、確切的執行檔或 URL、身份驗證、資料分類，以及具備寫入能力的工具。

2. 從全部拒絕開始。空的託管表會停用所有 MCP server：

   [mcp_servers]

3. 按確切 URL 新增已核准的 HTTP 伺服器：

   [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. 在 plugins.<plugin>.mcp_servers.<server> 下單獨新增外掛捆綁的 MCP 身份資訊。

6. 將核准列表儲存在經過稽核的設定儲存庫中，並通過管理員強制執行的要求部署。

客戶端僅在伺服器的名稱和身份資訊均與已核准條目匹配時才會啟用該伺服器。參閱託管設定。

驗證

• 嚴格按要求設定已核准的伺服器。預期：伺服器啟動。

• 更改 URL 中的一個字元。預期：伺服器被停用。

• 更改 stdio 參數數量或順序，或提供不符合已設定參數規則的參數。預期：伺服器被停用。仍滿足允許字首的值依然被允許。

• 在可隨時丟棄的可信專案中，保持執行檔和參數匹配，同時嘗試無害的 cwd、env 和 env_vars 覆蓋設定。僅靠身份匹配不會拒絕這些覆蓋設定。請驗證獨立的啟動上下文控制措施會拒絕不安全的覆蓋設定，或確保該 stdio 伺服器仍未獲核准；不要使用真實的注入載荷。

• 新增未經核准的名稱。預期：伺服器被停用。

• 測試外掛捆綁的伺服器。預期：伺服器僅在身份資訊獲核准時才能工作。

回滾

移除新增條目。若要立即停止所有 MCP 使用，請部署空的 mcp_servers 表。

適用邊界

身份允許列表並不能證明伺服器的工具、上游資料、憑據或啟動環境是安全的。本機 stdio MCP 程序在本機命令沙箱之外執行；執行檔和參數匹配並不會限制伺服器的存取權限，也不會阻止通過環境載入程式碼。請獨立稽核完整啟動上下文和伺服器權限。參閱 MCP 身份要求。

如果安全團隊需要了解 Codex 在終端和網路中執行的操作，請使用此方案。它彙集執行和工具事件、審批決策、工作區審計記錄以及網路日誌，以供調查。

預期結果

安全團隊可以關聯 Codex 執行、工具決策、審批、工作區審計記錄和實際網路出站流量，而無需依賴模型自身的描述。

使用四類證據來源

1. Codex OpenTelemetry：執行、API、模型、沙箱、審批和工具事件。

2. 託管生命週期鉤子：終端側有關工具使用和權限請求的記錄。

3. 網路代理或閘道器日誌：實際 DNS/HTTP 目標和連線結果。

4. Compliance API：工作區級別的審計和調查記錄。

任何單一來源都無法提供完整的網路監控。

設定

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 server、瀏覽器活動和 Codex Cloud 單獨設定遙測。本機命令代理規則不會自動覆蓋這些活動。

7. 將受支援的 Compliance API 記錄流式傳輸至 SIEM，並應用你自己的保留和法律保全控制措施。參閱 Compliance API 和審計事件。

8. 關聯使用者或服務帳戶、主機或執行器、對話 ID、模型、客戶端版本、權限設定檔、審批決策、目標和工具名稱。

驗證

執行一個受控會話，執行以下操作：

• 讀取一個允許的檔案。

• 嘗試讀取一個被阻止的檔案。

• 執行一條允許的命令。

• 嘗試發起一個被阻止的出站請求。

• 請求審批並收到拒絕。

• 結束會話。

各證據來源的預期結果：

• OTel 顯示執行和工具事件。

• 鉤子顯示會話生命週期。

• 代理日誌顯示允許和阻止的目標。

• Compliance 資料接入流程收到受支援的記錄。

• SIEM 將這些記錄與使用者或工作負載關聯。

回滾

恢復此前的設定，以停用匯出器和鉤子。遙測回滾時，不要移除獨立的代理日誌記錄。

適用邊界

不要承諾 Codex 遙測會捕獲每個命令參數、每個輸出位元組或每個網路資料包。請記錄各層的覆蓋範圍。

如果 Codex 應無法存取網際網路，或只能存取已核准的目標，請使用此方案。根據要設定的環境，選擇本機或雲端操作流程，並注意各自獨立的策略範圍。

預期結果

根據所選設定，Codex 無法存取網際網路，或只能存取已核准的域名。Codex Cloud (Legacy) 環境還可以限制 HTTP 方法。

設定當前 Codex Cloud

1. 為不同信任級別建立獨立環境，例如 no-internet-review、approved-dependencies-build 和 cyber-lab。

2. 在環境設定中，除非工作流程需要網際網路存取，否則保持 Allow Codex to access internet 關閉。

3. 需要存取時，開啟 Allow Codex to access internet。在 Allow domains 下選擇 Custom domains only，然後在 Additional allowed domains 下新增所需的確切主機名。

4. 在設定期間儲存並測試服務。發布或重新發布環境，然後在新任務中測試對已核准和未核准目標的存取。單獨稽核設定指令碼：固定依賴項版本，優先使用已核准的映像，避免下載未經稽核的執行檔。

參閱連線服務。當前 Codex Cloud 設定不提供 Legacy 版本中的 HTTP 方法選擇器。

設定 Codex Cloud (Legacy)

1. 無需存取時，將智能體網際網路存取保持為 Off。Legacy Cloud 預設在智能體階段阻止網際網路存取；設定指令碼仍可存取網際網路，以安裝依賴項。

2. 智能體需要存取時，將其設為 On，並使用嚴格的允許列表。從 None 開始，新增確切域名。

3. 對於僅下載的工作流程，只允許 GET、HEAD 和 OPTIONS。這會阻止 POST、PUT、PATCH、DELETE 及其他方法。請單獨稽核設定指令碼，因為智能體階段的限制不約束這些指令碼的網際網路存取。

參閱 Legacy 智能體網際網路存取。這些預設和 HTTP 方法控制僅適用於 Legacy Cloud。

設定本機 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] 為實驗性功能，可能會發生變化。在擴大部署前，請在每個受支援的本機客戶端版本和作業系統上進行驗證。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 server、瀏覽器活動和 Codex Cloud。本機沙箱規則不控制這些活動。

驗證

• 向已核准的域名傳送請求，並確認請求成功。

• 向未核准的域名傳送請求，並確認請求被阻止。

• 向 localhost、私有 IP 和雲後設資料端點傳送請求。確認每個請求都被阻止，除非已明確核准。

• 在 Codex Cloud (Legacy) 中，嘗試向允許的域名傳送 POST 請求。確認在僅允許 GET、HEAD 和 OPTIONS 時，該請求被阻止。

• 確認代理或閘道器日誌中同時包含允許和拒絕請求的記錄。

回滾

將環境恢復為 Off，或恢復此前的域名策略。避免回滾到不受限制的網際網路存取。

適用邊界

經核准的完全沙箱提權可以繞過本機命令代理。在依賴此限制前，請分別測試普通沙箱命令和經核准的提權命令。

允許的域名仍可能託管提示詞注入內容、已被入侵的軟體包或不安全的文件。

如果 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"

這是使用者可設定的預設值，而非強制要求。它會減少繼承的變數，但不會阻止存取憑據檔案、輔助程式、Shell 啟動內容或其他身份。參閱高階設定。

4. 在管理員管理的 requirements.toml 中，選擇受限設定檔，並僅允許使用該設定檔。內建設定檔不會繼承其中針對機密檔案的拒絕存取規則：

   default_permissions = "corp-workspace"

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

5. 為你的 Cloud 環境選擇憑據流程：

   • 在當前 Codex Cloud 中，對於傳送至允許的 HTTPS 服務的憑據，請使用 Network secrets。程式接收到的是佔位值，代理會在設定和任務期間，為發往埠 443 上已核准目標的請求替換為真實值。原始憑據不會放入本機程序或檔案中。直接設定的環境變數可供程式存取。參閱環境變數和網路機密。
   • 在 Codex Cloud (Legacy) 中，機密用於設定階段的身份驗證，並在智能體階段開始前移除；環境變數則在整個聊天期間保留。參閱 Legacy 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. 對於高風險設定檔，如果 Shell 包裝器可能掩蓋敏感命令，請向同一個 prefix_rules 陣列新增 Shell 包裝器條目：

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

Shell 包裝器條目會觸發較多提示，請有選擇地使用。

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。預期：命令被禁止。

• 拒絕一個審批請求。預期：命令不執行，拒絕操作被記錄到日誌中。

• 重啟客戶端並重複檢查。預期：規則仍被強制執行。

回滾

恢復此前的要求設定包。對於範圍過大的詞元匹配模式，應縮小其範圍，而不是移除整個敏感命令類別。

適用邊界

字首規則並非完整的作業系統策略引擎。請結合沙箱、最小權限作業系統帳戶、網路限制、雲 IAM、分支保護、部署審批和資料庫授權。

使用以下單項設定方案： 限制權限設定檔和完全存取權限；保護機密資訊和無關儲存庫；要求敏感命令經過審批。

開發者擁有正當的生產環境存取權限，但你希望 Codex 協助開發，同時避免未經稽核的生產環境更改。

• 定義已核准的工作區設定檔，並強制執行允許的設定檔和審批策略。將這些設定作為管理員強制執行的要求下發，防止使用者覆蓋。

• 使用獨立的低權限身份執行 Codex，或在無法存取或取得生產環境寫入憑據的環境中執行。開發者可以通過獨立的授權工作流程保留生產環境存取權限。

• 儘量減少傳遞給所啟動命令的環境變數。如果智能體需要身份驗證，請使用獨立的憑據代理提供短期憑據，並將其權限限定到確切目標和操作。

• 確定哪些命令需要審批提示，哪些應被禁止。要求由人審批選定的高影響命令，例如 git push、terraform apply、Kubernetes 更改和資料庫遷移；禁止絕不能執行的命令。

• 獨立於 Codex，持續強制執行生產環境 IAM、分支保護和部署審批。

限制權限設定檔並要求人工稽核

在管理員管理的 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 身份與生產環境憑據分離

在裝置管理或開發環境設定系統中，建立專用的 Codex 使用者、容器或開發主機，僅授予其存取所需源程式碼和開發服務的權限。不要將開發者的生產環境憑據檔案、令牌輔助程式或鑰匙串掛載到該環境中，並防止該身份取得生產環境寫入角色。

如果智能體需要存取服務，請設定組織的憑據代理，簽發僅限指定開發資源和操作的短期憑據。開發者可以通過獨立的授權生產工作流程使用其常規身份。

例如，在 AWS IAM 中，開啟 Roles，選擇 Codex 開發角色，然後在 Permissions 下新增經過稽核的內聯策略，如下所示，並將帳戶和角色替換為你自己的值：

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

此範例會拒絕代入指定角色的嘗試，但不會拒絕代入其他角色的嘗試。還應移除直接生產環境權限，限制其他生產環境角色和憑據來源，並稽核信任策略和組織級控制措施。

在不更改生產環境的情況下，使用有代表性的開發和生產權限測試開發角色。請參閱 AWS IAM 角色策略範例。

最小化 shell 環境

在用於系統級初始設定的 /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"

這是可設定的預設設定，並非強制執行的憑據邊界。使用者設定、shell 啟動指令碼或快照、憑據助手以及其他憑據來源仍可能暴露憑據。

在 requirements.toml 中，如果以下可選限制與你的工作流程相容，可用它們停用登入 shell 和 shell 快照：

allow_login_shell = false

[features]
shell_snapshot = false

請先試用這些設定，因為某些工作流程依賴登入 shell 的初始化。

使用匹配篩選條件的無害合成變數啟動 Codex，並檢查所啟動命令的環境；如果停用了登入 shell，還應驗證登入 shell 請求會被拒絕。另行驗證執行身份無法存取真實的生產憑據。請參閱 Shell 環境策略。

對選定的高影響命令請求審批

為組織使用的命令新增強制要求規則。例如：

[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 身份無法獲得生產環境的寫入權限。

• 重啟客戶端並重複測試。

邊界

字首規則並不是完整的作業系統策略引擎。請將其與沙箱、最小權限作業系統帳戶、網路限制、雲 IAM、分支保護、部署審批和資料庫授權結合使用。

使用以下設定方案： 保護金鑰和無關儲存庫；限制網路目標；僅允許獲批的 MCP server；要求敏感命令獲得審批。

開發者使用 Codex 處理內部儲存庫，而你希望降低程式碼被傳送到公共儲存庫、公開程式碼片段或其他未經核准的目標的風險。

• 為已知憑據目錄和無關儲存庫新增精確的拒絕存取路徑，並儘量減少傳遞給所啟動命令的環境變數。

• 需要為智能體提供網際網路存取時，使用範圍嚴格的獲批域名允許列表。僅允許獲批的 MCP server名稱和身份，並要求對選定的發布命令進行審查，或拒絕這些命令，例如 git push。

• 使用適合你所在組織的源程式碼管理鉤子和權限、公共儲存庫與程式碼片段策略，以及資料丟失防護控制措施。

拒絕存取無關儲存庫和憑據檔案

在管理員管理的 requirements.toml 中，新增本機智能體不得讀取的精確路徑：

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

將範例替換為受管裝置上實際存在的路徑。這項受管拒絕規則適用於所有允許的權限設定檔；僅在某個自定義設定檔中設定的拒絕規則，無法保護選擇其他設定檔的使用者。優先使用精確的已知路徑，並在所需的目錄深度測試所有 glob 模式。

在原生 Windows 上，受管 deny_read 涵蓋直接檔案工具，但其本身無法阻止 shell 子程序讀取；還應使用作業系統身份和檔案存取控制列表。

在被拒絕存取的位置建立無害的探測檔案。在每個允許的設定檔下，驗證直接讀取和通過 shell 讀取這些檔案的操作均被拒絕，並驗證可以讀取獲批的原始檔。請參閱受管拒絕讀取要求。

儘量減少包含憑據的 shell 變數

在 /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"

此設定會減少繼承的變數，但使用者可以自行設定，且它無法阻止存取憑據檔案、憑據助手、shell 啟動內容或其他身份。

在適當情況下，管理員還可以將以下限制新增到 requirements.toml 中，並先行試用，以評估它們對開發者工作流程的影響：

allow_login_shell = false

[features]
shell_snapshot = false

使用合成的探測變數和單獨的最小權限執行身份進行測試。不要使用真實憑據。請參閱 Shell 環境策略。

僅允許本機命令存取獲批的網路目標

如果本機沙箱命令需要網路存取，將以下設定檔設定和受管代理設定一並合併到 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 設定混用；請遷移並測試現有策略。

重啟客戶端，驗證獲批端點可以存取，且未經核准的端點會被阻止。

這些設定屬於實驗性功能；請驗證作業系統和客戶端支援情況，如果獲批主機解析為私有地址，還需單獨設定私有網路存取。獲批的完整沙箱提權可以繞過命令代理。

這項針對本機命令的網路控制本身不涵蓋網頁搜尋、應用、MCP server、瀏覽器活動或雲環境，這些都需要單獨的策略。獲批的託管域名也可能包含公共儲存庫或公開程式碼片段，因此僅靠目標允許列表無法保護內容。請參閱網路存取要求。

單獨設定雲環境網路

在當前的 Codex Cloud 介面中，開啟環境設定。保持關閉允許 Codex 存取網際網路。如果需要網際網路存取，開啟該選項並選擇僅自定義域名，在額外允許的域名 下新增所需的精確主機名，然後儲存設定，發布或重新發布環境，並測試一個新任務。

單獨審查服務的身份驗證和功能。

舊版 Codex Cloud 使用單獨的、按環境設定的智能體網際網路設定，可控制允許的域名和 HTTP 方法；設定指令碼有自己的存取行為。

請測試你實際使用的環境版本。請參閱連線到服務和舊版網際網路設定。

限制 MCP server並在 Git 推送前請求審批

在 requirements.toml 中僅允許獲批的本機 MCP server身份。例如：

[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 server、瀏覽器活動和 Codex Cloud；本機沙箱規則無法控制它們。

使用以下設定方案： 限制權限設定檔和 Full Access；僅允許獲批的 MCP server；限制網路目標；保護金鑰和無關儲存庫；要求敏感命令獲得審批。

你希望在 Codex 處理儲存庫或使用者更改本機設定時，約束 Codex 的限制仍然有效。

• 將受支援的權限、審批、MCP、網路和命令限制設為管理員強制執行的要求並下發。

• 將鉤子指令碼安裝到管理員管理的目錄中，如果需要忽略使用者、專案和外掛鉤子，則僅使用受管鉤子。

• 使用作業系統和裝置管理控制措施保護策略檔案及設定分發路徑。執行 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." },
]

此範例允許兩個設定檔，要求在需要審批時由人工審查，允許匹配的 MCP 身份，並對特定命令字首請求審批。

單獨設定 MCP server本身，並新增組織的其他敏感命令模式。根據需要新增全域檔案限制和網路限制；強制要求可以約束受支援的設定，但無法取代 Codex 外部的身份、服務和目標控制措施。

受管設定檔允許列表要求 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 無法涵蓋 shell 子程序讀取。

本機命令的網路設定無法管控其他客戶端、應用、連接器或雲端執行。

安裝並強制執行管理員管理的鉤子

請管理員將經過審查的鉤子程式安裝到由 root 管理的目錄中，例如 /etc/codex/hooks/pre_tool_use_policy.py，並阻止 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，並根據需要調整直譯器路徑：

import 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 使用不同的受支援鉤子處理程序。請保留獨立的作業系統和服務保護措施。請參閱受管鉤子和鉤子行為。

保護策略及其分發流程

在 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，並驗證強制執行的行為仍然有效。

測試範圍內的每個客戶端和環境，不要假定所有客戶端都載入相同的策略。

驗證

使用非管理員測試身份：

• 嘗試編輯受管策略。預期結果：無法更改受管檔案。

• 嘗試通過使用者或專案設定放寬限制。預期結果：更寬鬆的設定被拒絕或仍受到約束。

• 重啟客戶端，驗證限制仍然有效。

邊界

擁有足夠主機管理員權限的使用者或智能體可能能夠更改外圍保護措施。僅靠使用者可編輯的設定無法替代管理員管理的強制要求。