OpenAI

The tidy mental model for buying an AI coding tool is a developer-tools line item: engineering picks it, engineering owns it, engineering's budget carries it. OpenAI does not sell it that way — Codex arrives through the same workspace that serves the company assistant, on the same meter, under the same admin console.

Scope note: this series covers tools engineers use to write software, not putting a model inside a shipped product.

Codex — the coding agent, across local and hosted surfaces.

• Local surfaces — command-line client, desktop app, and an editor extension
  • The extension covers Visual Studio Code and VS Code–compatible editors — Cursor, Windsurf, and VS Code Insiders — from one marketplace package
  • Xcode and the JetBrains IDEs are served by their own separate integrations rather than that extension
• Hosted surfaces — web, mobile, and a cloud runner for delegated longer tasks
• Cloud-side capabilities — automated code review on pull requests, a chat integration
  • These run on the vendor's infrastructure, not the developer's machine

The split that matters — local versus cloud maps onto both billing and control.

• A team can adopt local only, cloud only, or both
• "What leaves the laptop" differs for each
• Naming trap — in workspace settings, Codex Local is a grouping label for access controls covering the desktop app, CLI, and editor extension
  • Not a separate product. Administrators reading it as one assume a boundary the product does not draw
• Cloud runs are governed separately — hosted environments, repository connections, their own runtime policy
• Approving local use is not approving cloud use

Adjacent, separately purchased — a code-scanning product in the same family: plugin, CLI, typed SDK, and a CI mode emitting the standard findings format with severity policies. Shares a brand with the coding agent; conflating them produces an inaccurate rollout scope.

• Individual tiers — free, lightweight paid, standard, high-limit
  • All personal subscriptions. No admin console, no central billing, no workspace data terms
  • Same shadow-rollout exposure as every other lab in this series
• Business — the smallest genuine company seat
  • From 2 users · $20 per user per month billed annually · $25 billed monthly
  • Lists both assistant and Codex access across desktop and mobile
  • Dedicated workspace · essential admin controls · federated single sign-on · multi-factor authentication
  • Larger virtual machines for cloud runs
  • No training on business data by default, stated on the plan card
  • A two-user floor is genuinely low — the distance from an expensed personal subscription to a governed workspace is shorter than most teams assume
• Enterprise and Edu — quoted, not listed

• Seat-type trap — seats are not interchangeable. A Codex-only seat does not grant access to the broader assistant capability
  • Sizing a rollout by headcount rather than by seat type gets the count wrong
• API-key path — for shared and automated environments such as CI
  • Runs the local clients · drops cloud-side features · follows whatever models the key reaches · bills per token
  • Usually the honest fit for a build pipeline that needs an agent but no workspace identity
  • Moves governance into the platform team's existing key management

Directory synchronization is absent from the small tier and present in the quoted one. That single line decides whether a rollout can answer the leaver question automatically — and it is easy to miss on a pricing page.

Stated directly in the pricing documentation: assistant usage inside the chat product and Codex usage draw on the same pricing, the same credits, and the same limits.

• Practical effect — a quarter where the rest of the company leans hard on the assistant is a quarter with less coding headroom
  • Neither group connects the two without being told
  • Credits extend usage flexibly, so the failure mode is rarely a hard stop — it is a bill that grew for unattributable reasons
• Two habits that make it manageable
  • Budget the two workloads together, because the platform already does — bring whoever owns the assistant rollout into the evaluation
  • Instrument attribution early — workspace analytics, and at the higher tier the compliance interface, make "which team spent this" a query rather than an argument

Four questions a legal team asks, in the order it asks them. The governing document is the services agreement covering the API, the business tier, and the enterprise tier.

1 — Who owns the output?

• Customer retains all ownership rights in Input and owns all Output
• OpenAI assigns to the customer all of its right, title, and interest, if any, in Output
• Affirmative assignment, same shape as two of the other three labs in this series

Two qualifications that belong in the evaluation:

2 — Does the source train the model?

• No. OpenAI will use customer content only as necessary to provide the Services, comply with law, enforce policy, and prevent abuse
• It will not use customer content to develop or improve the Services unless the customer explicitly agrees
• Individual consumer tiers are a different contract — the reason the personal-subscription path is a governance problem rather than a preference

3 — Could generated code carry someone else's licence?

• The agreement puts responsibility on the customer directly: the customer is solely responsible for all use of Outputs and for evaluating their accuracy and appropriateness for its use case
• No public-code matching filter is documented for the coding agent
• Consequence for evaluation — as with Anthropic, prevention is the organization's own job. Licence and dependency scanning applied to agent-authored changes, not only to human-authored ones
• The vendor-side answer to contamination is the indemnity below

4 — Who defends the company if a third party sues?

• OpenAI indemnifies, defends, and holds the customer harmless against third-party claims alleging that the Services infringe any third-party intellectual-property right
• Exclusions — claims arising from combining the Services with products not provided by OpenAI; modification of the Services by anyone else; customer content; and customer applications where the claim would not have arisen but for that application
• The clause worth finding in a negotiation — a separate service-specific indemnity is incorporated, is expressly not subject to any liability cap, and OpenAI may not materially reduce the customer's protections under it without written agreement
  • An uncapped, contractually locked indemnity is a genuinely strong position. Confirm its current scope in the service-specific terms as part of the evaluation
• Mitigation ladder — if OpenAI believes the Services are likely to face an infringement claim it will obtain the right to continue, replace or modify the Service, or as a last resort terminate and refund prepaid amounts
• The hard limit — the agreement states that the indemnities are a party's only remedy for the other's violation of a third party's intellectual-property rights
  • No parallel path to damages. What the indemnity covers is what the company gets

How long is it kept?

• On termination, OpenAI deletes all customer content within 30 days, unless legally required to retain it or the customer has agreed otherwise in writing
• Retention and residency controls are configurable at the Enterprise tier
• Compliance documentation carries a caution worth honouring — do not assume the vendor's retention window replaces the organization's own retention policy. Exported records need the organization's access, retention, and legal-hold controls applied in its own systems
• Audit reports from an independent auditor are available on written request, no more than once per year, and are treated as the vendor's confidential information

Where does it run?

• Cloud runs — isolated vendor-managed containers, no access to the host system or unrelated data
  • Two-phase runtime — the setup phase can reach the network to install dependencies; the agent phase then runs offline by default unless internet access is explicitly enabled
  • Secrets configured for the environment are available only during setup and are removed before the agent phase starts
  • A genuinely good boundary: a prompt-injection attack against the agent phase cannot exfiltrate setup secrets, because they are gone
• Local runs — operating-system-enforced sandboxing, with no network access and writes limited to the active workspace by default

Identity controls scale with the tier, and the documentation is refreshingly direct about the gaps.

• Business — federated single sign-on, multi-factor authentication
• Enterprise adds — domain verification, directory provisioning, user lifecycle management, identity-group synchronization
  • Provisioning and group sync are explicitly absent from Business
• The candid detail — workspace-wide multi-factor enforcement is not provided
  • Users can enable account-level multi-factor themselves
  • An organization that requires it must enforce single sign-on and multi-factor through its own identity provider
  • Stated plainly rather than buried, and architecturally correct — but a team assuming the vendor console could mandate it needs to redesign that control
• Group synchronization is what makes access track employment automatically
  • Below that tier, tracking is a human process — and human processes are what compliance examinations sample hardest
• Boundary worth internalizing — workspace access grants nothing in a connected system
  • A user reaches only what their own account or shared connection allows in the native application
  • Limits blast radius; also means an access review has two places to look

The admin rollout guide is explicit about something most vendor documentation leaves implicit: the controls sit on separate planes, and none implies the others.

1 — Workspace access. Membership, seats, roles, feature reach.

• The plane administrators think in, and the one that misleads them
• The guide warns directly: verify local-client and cloud access against current guidance rather than assuming they follow from the same role

2 — Local runtime policy. A requirements file delivered to the machine through a management channel.

• Constrains approvals, permission profiles, filesystem and network reach
• Model is a default profile plus an allowlist of selectable profiles:

default_permissions = ":workspace"

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

• Capabilities switch off by key, not by master toggle
  • Disabling computer use means constraining every participating feature key — browser use, full protocol access, external browser use, the in-app browser, and computer use itself
  • More work, and the honest design: one switch would imply a boundary the product does not have
• Network control is layered, and the intuitive configuration does nothing:

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

• The proxy feature changes how enabled network access is enforced. It does not grant access, and adding domain rules does not turn the proxy on by itself
  • Network off + proxy on → network stays off, the feature does nothing
  • Network on + proxy off → unrestricted outbound
  • Network on + proxy on → outbound constrained by policy
  • Only the last is a controlled configuration, and it takes two settings rather than one
• Where this policy lives matters — it is a file that must reach the laptop
  • No device-management channel means no enforceable local runtime policy, whatever was purchased
  • Belongs in the rollout plan on day one

3 — Repository configuration. The friendliest plane.

• Project defaults, rules, and skills check into the repository in a dedicated directory
• Arrives with a clone rather than through setup instructions; rules govern which commands require approval outside the sandbox
• Same instinct as a committed linter config beating a wiki page — the constraint travels with the code and reviews like code

Approval behaviour worth knowing — destructive connector tool calls always require approval when the tool advertises a destructive annotation, even if it also advertises read-only hints. The agent can also request approval for connector actions with side effects that are neither shell commands nor file edits.

Workspace roles, a policy file on the device, and configuration in the repository are three independent planes. Configuring one and assuming the other two is the standard way a rollout ends up looking governed without being governed.

• The compliance interface is the evidence surface, and its documentation is disciplined about purpose
  • For — exporting records into an audit or investigation system, applying retention and legal-hold processes, correlating coding activity with other security and identity data, supporting approved investigations
  • Recommended pattern — an append-only compliance log stream, collected continuously, ingested into a security-event system or data lake, tested against a non-production system first
  • Explicitly not for — productivity dashboards, or inferring code quality or individual performance
  • Adoption reporting belongs in workspace analytics or the analytics interface instead
  • Preserve that separation in the rollout: conflating them turns an audit tool into a surveillance tool and loses engineering's trust
• Honest limitation — the authenticated admin reference is the source of truth for current event coverage, routes, schemas, filters, and retention behaviour, and the public documentation deliberately does not duplicate it
  • An evaluation cannot fully score the audit surface from public pages
  • Getting a named administrator into the authenticated reference is a prerequisite, not a formality
• Code-scanning product — findings export in the standard interchange format with configurable severity policies in CI
  • Composable with existing scanning pipelines rather than another silo

Strong fit

• Organizations already running, or intending to run, the company assistant from the same vendor — one workspace, one identity integration, one admin console, one meter
• Delegated longer-running tasks against connected repositories, where the cloud runner's two-phase secret boundary is a real security advantage over the same work on a developer's machine
• The very small end — a two-person company can be on business terms with an admin boundary at a listed price. A lower barrier to being governed than most vendors offer

Weak fit

• Where engineering wants an isolated budget it controls — the shared pool is architectural, and ringfencing coding spend fights the design
• Where required identity controls sit above Business — an organization needing directory provisioning is buying Enterprise, and should price that from the start rather than discover it in the security review

Disqualifiers

• Requiring workspace-enforced multi-factor from the vendor console — it does not exist; it must come from the identity provider
• No device-management channel — local runtime policy is a file that must reach the machine
• Source cannot leave the network at all

Order to evaluate in

1. Establish which tier carries the identity controls actually required — directory provisioning is the fulcrum
2. Scope the surfaces deliberately — local and cloud are separate approvals with separate data paths, and the label grouping the local clients is a label, not a boundary
3. Confirm the device-management channel before the rollout
4. Get an administrator into the authenticated compliance reference and score the audit surface for real
5. Budget the pool as one number, with the assistant owner in the room — one meter, two dials, and only one of them is engineering's

Next: Microsoft — the only lab here that answers "where does the source go" twice, with two different products.