---
title: "做企業管理員初始化"
description: "為 Enterprise workspace 推出 Codex 前，先確定 owner、入口範圍、RBAC、managed configuration 和治理邊界。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

企業管理員初始化 Codex，不是簡單開啟一個開關。你需要先確定誰擁有配置權、哪些入口開放、哪些使用者可以使用、哪些策略必須強制、以及如何審計和回復。

> [!IMPORTANT]
> 企業 rollout 的順序應是 owner 和策略先行，然後再開放 Cloud、local、MCP、internet access、automations 和 code review 等能力。

<Cards>
  <Card title="Enterprise admin setup" href="https://developers.openai.com/codex/enterprise/admin-setup">
    檢視企業初始化 Codex 的官方 rollout guide。
  </Card>
  <Card title="Managed configuration" href="/zh-Hant/docs/codex/official/06-team-integration/55-managed-config">
    統一下發 sandbox、approval、MCP、feature flags 和 requirements。
  </Card>
  <Card title="Governance" href="/zh-Hant/docs/codex/official/06-team-integration/56-governance-observability">
    做 analytics、audit logging、compliance 和可觀測。
  </Card>
</Cards>

## Rollout 先分責任

企業環境至少需要三類 owner：

- Workspace owner：負責 ChatGPT workspace 中的 Codex 開關和訪問控制。
- Security owner：負責許可權、網路、secrets、sandbox、approval 和風險策略。
- Platform / analytics owner：負責 managed configuration、analytics、audit logging 和運維整合。

不要把所有許可權給一個泛泛的“管理員組”。Codex Admin 應只給少數負責 rollout、policy 和 governance 的人員。

## 先決定開放哪些入口

```mermaid
flowchart TB
    Codex["Enterprise Codex rollout"]
    Local["Local<br/>App / CLI / IDE"]
    Cloud["Cloud<br/>Web / integrations / remote tasks"]
    Both["Both<br/>統一治理"]

    Codex --> Local
    Codex --> Cloud
    Codex --> Both
```

Local 入口：

- 執行在開發者機器或本地 workspace。
- 更接近個人開發環境。
- 重點治理 sandbox、approval、local config、MCP 和憑據。

Cloud 入口：

- 執行在 hosted environment。
- 需要 GitHub、environment、secrets、internet access 和 integration 許可權。
- 重點治理 repo 訪問、環境隔離、網路和任務觸發。

同時開放兩者時，必須解釋兩套執行位置和資料邊界的差異。

## RBAC 和最小許可權

建議建立兩類組：

- Codex Users：可以使用 Codex 的普通使用者。
- Codex Admins：可以管理 policies、analytics、environment 和治理設定的少數管理員。

原則：

- 預設使用者不需要管理許可權。
- 管理許可權要可審計。
- 透過身份提供商和 SCIM 管理組成員。
- 不同團隊可以有不同 policy。
- group rule 順序要明確，避免許可權意外擴大。

RBAC 的目標是把“誰能用”和“誰能管理”分開。

## Managed configuration

Managed configuration 用來統一下發要求，而不是依賴每個開發者手動配置。

適合強制：

- 允許的 approval policies。
- 允許的 sandbox modes。
- web search 和 network behavior。
- MCP allowlist。
- feature flags。
- command rules。
- automatic reviewer policy。

先給大多數使用者設定 baseline policy，再為高風險團隊或特殊 workflow 建立更嚴格或更寬鬆的變體。

## Cloud 設定的額外邊界

啟用 Codex Cloud 前確認：

- GitHub repositories 是否託管在支援的環境裡。
- 誰有權連線 repositories。
- environment setup 是否最小化。
- secrets 是否只在必要階段可用。
- 是否需要 internet access。
- 允許哪些域名和 HTTP methods。
- task 完成通知是否會把敏感內容發回 Slack 或其他系統。

Cloud 的便利性來自非同步執行，但風險也來自遠端自動化。預設先保守開放。

## Local 設定的額外邊界

啟用 local 入口前確認：

- 開發者能否安裝 App、CLI、IDE extension。
- 是否允許 device code authentication。
- 是否限制登入方式和 workspace。
- 是否允許專案級 `.codex/`。
- 是否允許本地 MCP。
- 是否限制 browser use、computer use 或 plugins。

Local 入口更靠近開發者機器，必須讓預設 sandbox 和 approval 合理。

## 治理和可觀測

企業 rollout 不能只看啟用人數。還要建立可觀測指標：

- 使用量和活躍使用者。
- Cloud tasks 成功率。
- review 觸發和反饋質量。
- policy 命中情況。
- MCP 和 tool 使用。
- 失敗原因和阻塞點。
- 安全事件和審計日誌。

這些資料用於改進 policy、培訓和 workflow，而不是隻做報表。

## 推薦上線順序

1. 明確 owner、使用者組和管理組。
2. 先開放小範圍 pilot。
3. 配置 baseline managed policy。
4. 開放 local 入口。
5. 配置 Cloud environment 和 GitHub access。
6. 逐步接入 integrations、MCP、automations。
7. 開啟 analytics、audit 和 compliance 流程。
8. 根據真實 usage 調整 policy。

每一步都應有回復方案和聯絡人。

## 管理員檢查清單

上線前確認：

- 使用者是否知道 local 與 cloud 的區別。
- Admin 許可權是否最小化。
- managed configuration 是否生效。
- secrets 和 internet access 是否受控。
- MCP 是否有 allowlist。
- 自動 review 是否有質量標準。
- 日誌、審計、合規是否能查詢。
- 有無明確支援和升級路徑。

企業版 Codex 的目標不是“讓所有人馬上自動化”，而是把 agent 能力放進可治理的工程系統裡。
