Enterprise Management and Governance: Playing Alone vs. Using in a Company are Two Different Things

📚 Series Navigation: The previous post [38 Glossary (Beginner-Friendly)] compiled all the jargon that appeared throughout the Codex section into a dictionary for quick lookup—that was for you to "understand others". This is the last post in the Codex section, and it is also an optional read: aimed at team administrators / technical leads, explaining how a company can roll out Codex to an entire team in a secure, controllable, and auditable manner. If you are an individual user, you can skip this post entirely, the previous 38 posts are more than enough for you; but if you ever need to be responsible for setting it up for a team, it's not too late to come back and read this. This is the end, and at the end of the post, I'll wrap up the entire Codex section.

To say something that might offend some: one person playing with Codex and a company using Codex are two completely different things.

When you use it yourself, you care about "whether this model is smart, runs fast, and is easy to use." But once you are the person who has to make the decision to "let 200 engineers across the company use it," the first question that pops into your head is often not "is it easy to use," but—"Will our code be used for training? Can I audit who did what? If someone accidentally runs rm -rf on a production configuration one day, can I stop it?"

I fell into this cognitive gap myself. In April this year, when helping a friend's small team evaluate whether to adopt Codex, I enthusiastically demonstrated how powerful and fast it was. After listening, he only asked me one question: "So will OpenAI use our customers' code to train models?" I was stumped on the spot—I hadn't researched this part at all, so I could only go back with a dusty face to dig through the official documentation. Since then, I realized: For administrators, "governance" is not the icing on the cake; it is a prerequisite for whether it can be used.

This post will clarify this prerequisite.

After reading this post, you will get:

• What is the actual difference between the individual version and the team / enterprise version—some governance capabilities are not configuration switches, but subscription tier thresholds
• Unified provisioning and account management: What the three acronyms SSO, SCIM, and RBAC actually mean for administrators
• The data issues of greatest concern: Will code be used for training, where is the data stored, and how long is it kept? What the official policy says
• How to use a "centrally dispatched policy file" to lock down the security baseline for the entire team, without configuring individual computers one by one
• Auditing and compliance: Who did what, which model was used, who created the token, and how to export them for reconciliation
• How to view and manage costs and quotas, so you aren't shocked by the bill at the end of the month
• A "pre-launch self-check list" for administrators to follow before rolling it out

⚠️ All specific pages, commands, configuration items, and default behaviors mentioned below are based on the Codex enterprise documentation; model names, subscription tiers, and the availability of various capabilities will change with versions and your specific contract, so what you see in your workspace backend shall prevail. This post does not write them in stone. Enterprise governance capabilities are mostly tied to the ChatGPT Business / Enterprise tiers. Whether you can see a particular switch depends on your tier and role.

---

01 First Recognize: The Difference Between the Individual and Enterprise Versions is Not Functionality, But "Controllability"

Many people think that the enterprise version is just "individual version + more quota." That's incorrect.

Analogy: Home kitchen vs. central kitchen. When you cook at home, where you put the knife, how high you turn the heat, and whether you wash your hands are entirely up to you; no one manages you, and no management is needed. But for a central kitchen of a chain restaurant, just "being able to cook" is far from enough—you must have unified operating procedures (no one cooks by feel), access control and badges (who can enter which area), surveillance footage (to trace back if something goes wrong), and inventory ledgers (costs must balance). The large portion added in the enterprise version of Codex is entirely this set of "controllability" capabilities, rather than "being more capable of cooking."

The specific differences are shown clearly in this table:

Dimension	Individual Version (Plus / Pro, etc.)	Team / Enterprise Version (Business / Enterprise)
Who can use it	Just you, it's your call	Administrators toggle it globally in the workspace backend, delegating permissions by role / group
Login method	Your own account credentials	Enforceable SSO (Single Sign-On), MFA (Multi-Factor Authentication), and SCIM automatic account synchronization
Security baseline	Configure sandbox and approvals locally by yourself	Administrators dispatch policies centrally, which users cannot modify (requirements.toml)
Data training	Depends on your account settings	Enterprise data is not used for training, explicitly promised by the official guidelines
Auditing	Practically none	Exportable activity logs, who did what, and compliance reconciliation
Usage observation	General overview on your own interface	Analytics dashboard + API, broken down by user / product area
Who manages it	No such thing as management	Dedicated Codex Admin role, managing policies, environments, and analytics

Do you see it now?—The entire right column is not about "features" in essence, but about "control." Individual users don't need it at all, but for administrators, this column is the true core.

There is also a point that easily trips people up at the beginning: Codex is split into two setups, "local" and "cloud", and their provisioning is separate.

Codex local (local) includes the desktop App, CLI, and IDE extensions, with agents running in sandboxes on developers' own computers. Codex cloud (cloud) includes cloud tasks, Code Review, iOS, etc., with agents running in hosted remote containers, which requires connecting the codebase (currently requiring GitHub cloud repositories).

Administrators can enable only local, only cloud, or both. This choice directly determines "on which machine the code is processed," which is the first decision you must make during data assessment. In my evaluation for my friend's team, we got stuck here—their code was on a self-hosted GitLab, so the cloud setup was completely unusable. They could only go with the local + SDK custom implementation, and the evaluation direction changed on the spot.

💡 One-sentence summary: What the enterprise version adds is not "being more capable", but "being controllable"—authorization, policies, auditing, and cost are the four things administrators actually want.

---

02 Unified Provisioning and Account Management: The SSO, SCIM, and RBAC Trio

When a team adopts a tool, the first headache is never "whether it's easy to use," but "how to provision it for a group of people, and how to cleanly revoke access when someone leaves." Adding them manually one by one will drive you crazy by the 20th person, let alone if someone leaves and you forget to turn off their access.

This is exactly what the SSO, SCIM, and RBAC trio is designed to solve.

Analogy: Company badge access system. SSO is "one badge to open all doors" (no need to remember passwords for every system); SCIM is "hiring/resigning in the HR system automatically opens/closes access" (accounts follow HR workflow without manual IT intervention); RBAC is "permission levels on the badge—interns can only enter the work area, while finance can enter the server room" (different roles see different switches).

Explaining them in plain English:

SSO (Single Sign-On)—Employees use the company's unified identity (such as Okta, Azure AD) to log in to Codex, without needing to register separately. Administrators can also enforce MFA (Multi-Factor Authentication) to block the path of weak passwords.

SCIM (Automatic Account Sync)—Connect Codex user groups to your Identity Provider (IdP). When someone joins, you add them to the IdP, and they automatically enter the corresponding group and receive corresponding permissions; when someone leaves, you remove them from the IdP, and their access is automatically revoked. The key value is "auditable and centrally managed"—member changes leave a trace, rather than relying on the memory of an IT colleague.

RBAC (Role-Based Access Control)—This is the one administrators should pay the most attention to. The official docs provide a grouping pattern that is highly worth copying:

• Create a "Codex Users" group for everyone who should use Codex;
• Create a separate "Codex Admin" group, containing only the few people who should manage policies and settings;
• Grant the permission of "allowing management of Codex" only to the Codex Admin group.

Why separate them this way? Because what a Codex Admin can modify is very heavy—they can view workspace-wide usage analysis, change the safety policies dispatched to everyone, and manage cloud environments. Giving this permission too broadly is equivalent to handing over the company's entire security baseline to a bunch of people to modify at will. The official principle is just one sentence: grant administrative permissions to the fewest people possible. My own habit is to grant roles that can modify global policies to only two or three people, rather than enabling it for an entire team just to save trouble.

On a practical level, the general workflow for an administrator to enable access looks like this (specific pages depend on your backend):

1. Go to ChatGPT enterprise backend → Workspace Settings → Settings and Permissions
2. Turn on "Allow members to use Codex Local" → Local trio (App/CLI/IDE) becomes available
3. For cloud: Turn on "Allow members to use Codex cloud" + Connect the GitHub connector
4. Go to Custom Roles, create two groups: Codex Users and Codex Admin, and split permissions according to the pattern above
5. Use SCIM to connect these two groups to your IdP, synchronizing member changes automatically

New workspaces have Codex local enabled by default; if a user hits a 403 - Unauthorized. Contact your ChatGPT administrator for access. error during login, it is highly likely that this local switch is not turned on, or they are not in the authorized group.

💡 One-sentence summary: SSO manages "how to enter", SCIM manages "automatic sync when people come and go", and RBAC manages "who can see which switch"—administrative permissions are always given to the fewest people possible.

---

03 Data Governance: Will Code Actually Be Used for Training?

This was the question that stumped me during that evaluation, and it is also the first question asked by almost every team lead. Here are the conclusions, straight from the official docs in black and white:

• No training on enterprise data (企业数据不用于训练模型)
• The local trio (App, CLI, IDE) supports Zero Data Retention (ZDR), keeping code within the developer's environment
• Data residency and retention policies follow your ChatGPT Enterprise settings
• Static encryption AES-256, transit encryption TLS 1.2+
• Audit logs are available via Compliance API

Translating these into the three questions administrators actually care about:

First, will it be used for training? No—enterprise data is not used to train models. This is a solid commitment difference between the enterprise version and the individual version.

Second, where is the code stored and how long is it kept? The local trio supports Zero Data Retention (ZDR)—simply put, Codex works on the developer's machine and does not retain code on OpenAI's side long-term. Since the cloud setup requires connecting repositories to hosted containers, the data residency and retention involved follow the settings in your Enterprise contract. Therefore, "local vs. cloud" is not just a performance choice, but also a choice of data flow.

Third, can data residency be locked to specific regions? Yes, you can use key constraints like enforce_residency in the dispatched policies (e.g., enforce_residency = "us") to keep data processing within a designated region. For specific supported regions and how they take effect, please refer to your contract and the official enterprise configuration documentation.

Here is a detail I must point out for you, otherwise it is easy to misjudge: Audit logs and "code retention" are two different things. Tasks run by Codex logged in with ChatGPT identity generate an audit record (used for compliance, detailed in the next section), and this audit log is kept for a maximum of 30 days according to the official documentation; while "no training on enterprise data, local ZDR" manages "whether OpenAI keeps your code for usage". One is "for you to check", the other is "to prevent others from using it"—do not confuse them.

Analogy: Bank's "surveillance footage" vs. "not misappropriating your deposits." Surveillance footage (audit log) is kept for a period of time to trace back if something goes wrong; "not lending out your money" (no training, ZDR) is a promise of a different matter. You need both, but do not mistake one for the other.

💡 One-sentence summary: Enterprise data is not trained, the local trio has zero retention, and data residency regions can be locked—however, "audit log retention for 30 days" and "code not being retained for training" are two independent commitments and should be understood separately.

---

04 Centrally Dispatched Policies: Locking Down Security Baselines for the Whole Team without Individual Configuration

In posts 15 and 16, we talked about local sandbox, approvals, and requirements.toml—that is "you tightening the screws on your own machine." But as an administrator, you cannot go to 200 computers and configure them one by one, right?

The enterprise solution is: dispatch policies centrally, which users cannot modify locally.

Analogy: Operations manual dispatched by chain headquarters. A store manager can adjust daily routines like "whether to launch a new product today"; but safety baselines such as "ingredient shelf-life redlines and cash register reconciliation procedures" are dispatched centrally by headquarters, must be executed by all stores, and cannot be changed by managers. The enterprise policy of Codex is this "headquarters manual."

The official guidelines divide dispatchable items into two categories, which must be clearly distinguished:

Type	What it is	Can users modify it
Requirements (Mandatory)	Security constraints locked down by the administrator: allowed approval policies, allowed sandbox modes, internet connectivity, allowed MCP servers...	Cannot modify; when a conflict occurs, Codex automatically rolls back to compliance values and prompts the user
Managed defaults (Managed defaults)	Starting values applied when Codex boots up	Can be modified temporarily in the session, but is reset back to managed defaults at the next boot

Both of these are carried in TOML files. Administrators mainly deal with requirements.toml (mandatory requirements) and managed_config.toml (managed defaults). The easiest way to dispatch them is "cloud hosting"—write them on the Codex Policy Page, bind them to a user group, and after users log in using ChatGPT, the local trio automatically pulls and applies them, eliminating the need to push files to every computer beforehand.

Take the most common requirement: disabling "full privilege execution (YOLO)" and locking approvals and sandboxes to safe levels. You can dispatch the following snippet (this is an official example, modify it as needed):

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

The effect of these two lines is to completely block --ask-for-approval never and --sandbox danger-full-access (i.e. --yolo)—no matter how much a smart colleague wants to cut corners and run with full privileges, this wall will stop them.

For another example, if you want to disable certain experimental capabilities (like computer use) for everyone, dispatch:

[features]
browser_use = false
in_app_browser = false
computer_use = false

Or if you want to force approvals on certain high-risk commands:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "推送 / 提交前必须人工确认" },
]

Note: Rules in requirements can only be "prompt" (trigger approval) or "forbidden" (forbid), and cannot use "allow" to delegate authority to users—this is by design; enterprise policies are only used to "tighten", not to "loosen".

For scenarios where the cloud cannot be managed and device management is required (such as pure local setups, companies pushing configuration via MDM), the official guidelines also support macOS MDM (such as Jamf Pro, Fleet, Kandji) dispatching base64-encoded TOML, as well as system-level files like /etc/codex/requirements.toml (Unix) / %ProgramData%\OpenAI\Codex\requirements.toml (Windows). Take note of platform differences: paths differ between Mac/Linux and Windows, while cloud hosting is cross-platform unified. New teams should prioritize cloud hosting for the most hassle-free experience.

💡 One-sentence summary: Use requirements.toml to centrally dispatch security baselines. Cloud hosting is the easiest, and users cannot modify them—enterprise policies are only responsible for "tightening", not "loosening".

---

05 Auditing and Compliance: Who Did What, and It's Exportable

With policies tightening the baseline, you still need to be able to answer "when something goes wrong, who did what, when, and with which model." This is auditing.

The official guidelines provide three levels of observation methods, remembered from "light to heavy":

Tool	Purpose	Who uses it
Analytics Dashboard	Open in the backend to view: who is using it, how much, and Code Review feedback	For administrators' daily self-service check
Analytics API	Pull daily structured usage into your data warehouse / BI	Connect reports for leadership presentations
Compliance API	Export detailed activity logs to connect to SIEM / eDiscovery / DLP	For security, legal, and compliance investigations

Daily, checking the Analytics dashboard is enough—you can break down active users, usage, and token consumption by different product areas like CLI / IDE / Cloud / Code Review, and export to CSV / JSON. Note the official tip: usage data can have a delay of up to 12 hours, so do not use it for real-time monitoring.

To actually conduct compliance investigations and hold people accountable, you must use the Compliance API. The details it can export are very granular:

The fields it can export include: the original prompt sent to Codex, the reply generated by Codex, identifiers such as workspace / user / timestamp / model, token usage, and request metadata. In other words, you can answer "who ran this task", "who created or revoked a certain access token", "when was it run", and "which model was used".

How an administrator actually pulls logs looks roughly like this (specific endpoints and parameters depend on the official guidelines):

curl -L -H "Authorization: Bearer YOUR_COMPLIANCE_API_KEY" \
  "https://api.chatgpt.com/v1/compliance/workspaces/WORKSPACE_ID/logs?event_type=CODEX_LOG&after=2026-03-01T00:00:00Z"

Expected outcome: Returns a batch of downloadable compliance log file lists, which you then pull down one by one by log_file_id to connect to your own SIEM for monitoring and archiving.

I'll mark two pitfalls for you so you don't fall in:

First, audit logs are kept for 30 days—as mentioned in the previous section, this is the window period. Do not expect to pull records older than 30 days, so for long-term retention, you must export and archive them yourself regularly.

Second, only tasks run by logging in with ChatGPT identity are included in compliance export. The official wording: Codex usage authenticated via API key follows the settings of your API organization, which is outside the scope of Compliance API export. Therefore, if your team has automations running via Platform API key, this part of the audit must be handled separately on the API organization side, so do not wait for it here.

There is also something closely related to auditing that needs management: access token. It is the "Codex identity token" used for automation (CI, scheduled tasks, codex exec scripts). The tasks run under it will be credited under the name of the workspace member who created it and go into governance data. Administrators must manage it as a credential:

• Save it in a secret manager, keep it out of logs, rotate it regularly, set an expiration period (7/30/60/90 days is stronger than "never expires"), and revoke it immediately after use;
• Do not use it in public CI, fork PRs, or shared machines—places where tokens can easily leak to people outside the workspace.

My own experience is: never set access token to "never expires" just to save trouble. Last year, I had a token for a personal script sitting there for more than half a year. Later, during troubleshooting, just confirming "is this thing still valid, who created it, and where else is it used" took half an hour. When managing for a team, an expiration date + regular rotation is the only way to save peace of mind.

💡 One-sentence summary: Check the Analytics dashboard daily, and use the Compliance API for compliance accountability; keep two redlines in mind—logs are kept for only 30 days, and only usage via ChatGPT login enters the compliance export.

---

06 Cost and Quota Management: Don't Be Shocked by the Bill at the End of the Month

Finally, let's talk about money. When a team uses AI tools, the biggest fear is "the bill comes at the end of the month, and nobody knows where the money went."

Cost observation for Codex mainly relies on the Analytics dashboard / API mentioned in the previous section—it can break down credit (quota) and token consumption by product area (CLI / IDE / Cloud / Code Review) and by user, making it clear at a glance who the heavy users are.

Analogy: Categorized bookkeeping in a household ledger. If you want to know where the money went, simply looking at "spent 10,000 this month" is useless; you must break it down into "rent, food, and taxis." The "by product area / by user" breakdown of Analytics gives you this categorized ledger—which team is running heavily in the cloud, who is pulling reasoning effort to the maximum every day, the data is all there.

There is roughly three types of cost dials that administrators can adjust:

First, save from the policy level. When dispatching requirements.toml earlier, you can easily restrict "expensive usages"—for example, limiting sandbox modes and disabling certain heavy experimental features are inherently cost-controlling actions.

Second, save from the model / reasoning effort level. As mentioned in post 30, maximizing reasoning effort is the most expensive. You can set a conservative default value for the whole team in managed_config.toml (e.g., model_reasoning_effort = "medium"), allowing everyone to start from an appropriate level rather than everyone starting with xhigh. Using small models like gpt-5.4-mini for lightweight subtasks can also significantly lower costs.

Third, manage from the quota / service tier level. Configurations like service_tier (where fast increases speed by 1.5x but consumes more credits, and flex is another built-in value, with specific differences depending on your contract and backend) can also be unified in managed defaults to turn "defaulting to the cost-saving tier" into a team habit.

Here is a "cost reconciliation rhythm" I summarized from leading teams, which can help you avoid many pitfalls if you follow it:

❌ Pitfall-prone approach	✅ More stable approach
Waiting until the monthly bill arrives to look at it	Check Analytics weekly at fixed times, keeping an eye out for abnormal spikes
Set global default to xhigh top-tier reasoning	Set managed default to medium, only manually pulling it higher for truly hard tasks
Allowing anyone to use the most expensive flagship + full features	Use policies to set conservative tiers for most users, opening up for a few heavy scenarios
No one reconciles accounts, shifting blame when problems arise	Designate a "usage owner" to issue reports periodically

The official suggestions are also very practical: Assign an owner for both "adoption report" and "audit compliance", set a review cadence, and figure out "what success looks like" before rolling it out. Don't open it up to everyone from the start and try to tighten it later after overspending—by then, bad habits will have already formed.

💡 One-sentence summary: Manage costs by splitting accounts by user / product area via Analytics, set reasoning effort and service tiers to conservative levels in managed defaults, and designate someone to reconcile accounts regularly—don't wait for the end-of-month bill to teach you a lesson.

---

07 Summary

In this post, standing from the perspective of an administrator, we've gathered the pieces of the puzzle on "how a company can make good use of Codex":

• The difference between individual and enterprise versions is "controllability"—authorization, policies, auditing, and cost are the core, not "being more capable".
• Account management trio: SSO manages logins, SCIM manages automatic syncing when people come and go, and RBAC manages who can touch which switch; administrative permissions are always given to the fewest people possible.
• Data governance: Enterprise data is not trained, the local trio has zero retention, and residency regions can be locked; however, "audit logs kept for 30 days" and "code not being trained or retained" are two independent commitments.
• Centrally dispatched policies: Use requirements.toml to tighten security baselines for everyone. Cloud hosting is the easiest, and enterprise policies only tighten but do not loosen permissions.
• Audit compliance: Check the Analytics dashboard daily, and use the Compliance API for accountability; keep the two redlines in mind: "logs are kept for 30 days" and "only usage via ChatGPT login is included in compliance exports".
• Cost control: Break down accounts by user / product area, set reasoning effort and service tiers to conservative levels in managed defaults, and designate someone to reconcile accounts regularly.

You should now be able to: determine whether your team should enable local or cloud setup, answer the boss's question of "will our code be trained", use a policy file to set safety baselines for everyone, know where to export logs when something goes wrong, and how to keep costs under watch before the end-of-month bill blows up. This isn't about configuring everything today—it is so that when you actually need to roll it out one day, you have a plan, a basis, and a checklist.

Finally, here is a pre-launch self-check list for you to go through before rolling it out:

• [ ] Determined whether to use local / cloud / or enable both (directly deciding data flow)
• [ ] Designated three types of owners: workspace owner, security owner, and analytics owner
• [ ] Created two groups: Codex Users and Codex Admin, giving management permissions to only a few people
• [ ] Connected SSO / MFA / SCIM, enabling automatic sync and auditing of member changes
• [ ] Dispatched requirements.toml, blocking full-privilege execution and setting safety baselines
• [ ] Configured Analytics and Compliance API keys, knowing where to export logs and how long they are kept
• [ ] Set expiration dates for all access tokens and established a rotation plan
• [ ] Established a cost review cadence and defined "what success looks like"

---

Writing up to here, we have reached the end of the entire Codex section.

Looking back at this journey: we started from post 01 "What is Codex anyway", set up the environment, and ran the first task; along the way, we got to know the interfaces of CLI, desktop App, IDE, and Cloud, and understood parts like AGENTS.md, config.toml, permission sandboxes, MCP, sub-agents, Skills, and Hooks; we learned how to choose models, how to speed things up, and how to connect it to Git, Slack, and CI; finally, we wrapped things up with the glossary and this post on enterprise governance. With 38 main posts + 1 optional read, you have walked from "having heard of Codex" to "being able to use it steadily in your real workflow."

First of all, congratulations on reading this far—there aren't many people who can digest a whole set of tool tutorials.

But to tell the truth, reading these words is at most "knowing", and you are still one step away from "knowing how to use it"—that step can only be taken by yourself. My suggestion is simple: stop hoarding tutorials. Open your terminal right now, pick a real small task you have on hand—fixing a bug, writing a script, refactoring a piece of messy code—and hand it over to Codex to run. There will be stuck moments and disappointments, but that moment when you first hand-deliver a real problem for it to help you solve is more useful than reading ten tutorials.

Tools are dead, but what you achieve with them is alive. Go get hands-on, brother.

---

Recommended Reading

• Getting to Know Codex and the Four Entry Points
• How to Choose Models: Which Model to Send for the Same Prompt
• Advanced Tips and Speeding Up: It's Not the Model Slowing You Down, It's the Bad Context You Provide