D4 · Team Adoption and Governance

This domain is worth 20% of the mock — roughly 10 of 50 items. It moves from one engineer’s workflow to an organisation’s: how an admin rolls Codex out, authenticates it, governs who can do what, keeps it configured consistently, audits it, and secures the code it produces. The exam rewards the governed default — least privilege, managed configuration, audit trails, and security scanning — over the fastest path to “everyone has Codex”.

What you need to know

Admins roll Codex out through a rollout guide and managed configuration so settings are consistent, not left to each engineer. Authentication has several options — workload identity, personal access tokens (PATs) and service accounts — chosen by whether a human or a system is acting. Access is governed by groups and provisioning, roles and workspace permissions, and controls over plugins, connectors and skills. Oversight comes from workspace analytics, the Analytics API, and the Compliance API and audit events; regulated workloads use HIPAA configuration. Finally, Codex Security (plugin, CLI, cloud) scans code and integrates with CI and GitLab CI.

Learning objectives

By the end of this page you should be able to:

1. Plan an admin rollout using managed configuration for consistency at scale.
2. Choose an authentication option — workload identity, PAT or service account — for a given actor.
3. Govern access with groups, provisioning, roles and workspace permissions.
4. Control extensions — plugins, connectors and skills — at the workspace level.
5. Audit and measure Codex with workspace analytics, the Analytics API and the Compliance API / audit events.
6. Configure regulated and secure workloads, including HIPAA configuration and Codex Security with CI scanning.

4.1 Admin rollout and managed configuration

A rollout that leaves configuration to each engineer produces drift and risk. Managed configuration lets admins set and enforce settings centrally.

UNGOVERNED ROLLOUT              GOVERNED ROLLOUT
each engineer configures        admin sets managed configuration
their own model, perms,   ──►   → consistent model availability,
extensions → drift, risk        permissions, allowed extensions

4.2 Authentication options

Pick the auth mechanism by who or what is acting.

Who is acting?
│
├─ A cloud workload / CI ─────► workload identity federation (no long-lived secret)
├─ An org-owned automation ───► service account
└─ An individual scripting ───► personal access token (PAT)

4.3 Groups, provisioning, roles and permissions

Governing access at scale means managing identities and what each can do.

The principle is least privilege: admins are few, most engineers are members, provisioning is automated so leavers lose access promptly, and permissions match responsibility.

4.4 Analytics and adoption measurement

You cannot govern what you cannot see. Codex exposes both a dashboard and a programmatic surface.

Adoption is measured, not assumed: who is using Codex, how much, and — combined with quality signals (D5) — whether usage is producing good outcomes.

4.5 Compliance, audit and regulated workloads

Governance requires an audit trail and, for some industries, specific configuration.

For a regulated workload, the exam-correct answer combines the right configuration (e.g., HIPAA) with an audit trail (Compliance API and audit events) — not one without the other.

4.6 Codex Security and CI scanning

Codex Security scans the code Codex (and your team) produces, across the plugin, CLI and cloud.

CODE (human or Codex) ─► SCAN / DEEP SCAN ─► WORKBENCH TRIAGE ─► FIX / HARDEN
                                │                                    │
                          CI / GitLab CI                      vulnerability
                          gate the pipeline                   report

Security scanning belongs in the pipeline (CI / GitLab CI), not as a manual step someone remembers, so that Codex-produced code is scanned before it merges.

Decision framework

Use ROLL OUT SAFELY (ROSA): Rollout config, Ownership (auth), Scope (roles), Audit.

Common mistakes

Scenario challenge

Scenario. A healthcare software company is rolling Codex out to 120 engineers across six teams. Today, a pilot group each installed the CLI, signed in personally, pinned different models, and one engineer wired a nightly cloud job using their own personal access token. Some repositories touch protected health information. Leadership wants adoption numbers for a board update and an auditable record for their compliance team. An engineer proposes: “let everyone self-configure like the pilot, keep the personal token for the nightly job, and pull adoption numbers manually each month”.

Expert reasoning trace.

1. Self-configuration does not scale or govern. 120 engineers each pinning models and permissions is drift and risk. The rollout needs managed configuration setting model availability, permissions and allowed extensions centrally.
2. The nightly job’s auth is wrong. A personal access token ties an org automation to one person — it breaks when they leave and is not an org identity. A cloud/CI workload should use workload identity federation; a shared org automation could use a service account. Either is correct over a PAT here.
3. PHI forces regulated configuration. Repositories touching protected health information require HIPAA configuration; “internal use” does not exempt them.
4. Compliance needs an audit trail. The compliance team’s auditable record is the Compliance API and audit events, enabled as part of the rollout — not reconstructed later.
5. Adoption numbers should be programmatic. Manual monthly pulls are error-prone; workspace analytics plus the Analytics API give the board update repeatably.
6. Secure the code path. Codex-produced code in a healthcare product should be scanned in CI via Codex Security before merge, not manually.

Exam-correct decision: roll out with managed configuration; authenticate the nightly job with workload identity federation (or a service account), not a personal token; apply HIPAA configuration to PHI-touching repos; enable the Compliance API and audit events; report adoption via workspace analytics and the Analytics API; and run Codex Security in CI. Not self-configuration at scale, not a personal PAT for an org automation, not manual adoption pulls, not skipping HIPAA config because it “feels internal”.

Assessment traps

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• Roll out with managed configuration so model availability, permissions and allowed extensions are consistent, not per-engineer.
• Choose auth by the actor: workload identity federation for CI/cloud workloads, service accounts for org automations, PATs for individuals.
• Govern access with groups, provisioning and least-privilege roles and permissions; automate the user lifecycle.
• Measure adoption with workspace analytics and the Analytics API — numbers, not anecdotes.
• Keep an audit trail with the Compliance API and audit events; apply HIPAA configuration to PHI workloads.
• Scan Codex-produced code with Codex Security (plugin, CLI, cloud) integrated into CI / GitLab CI, before merge.
• The governed default — least privilege, central config, audit, in-pipeline security — beats the fastest path to “everyone has Codex”.