# D4 · Team Adoption and Governance Admin rollout, authentication options, groups and provisioning, roles and workspace permissions, managed configuration, analytics and compliance APIs, HIPAA configuration and Codex Security. import { Accordions, AccordionItem } from '@prosefly/astro-components'; 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. | Rollout element | Purpose | | --- | --- | | Admin rollout guide | The sequence: workspace setup, auth, groups, roles, config, monitoring | | Managed configuration | Centrally set and enforce settings (model availability, permissions, extensions) | | Workspace model availability | Control which models the workspace may use | | Plugin / connector / skill controls | Decide which extensions are allowed | ```text UNGOVERNED ROLLOUT GOVERNED ROLLOUT each engineer configures admin sets managed configuration their own model, perms, ──► → consistent model availability, extensions → drift, risk permissions, allowed extensions ``` :::tip[Assessment signal] `Consistent settings across the team`, `stop engineers each configuring their own` → **managed configuration**. `Which models can the workspace use` → **workspace model availability**. `Which plugins/skills are allowed` → plugin/connector/skill controls. ::: ## 4.2 Authentication options Pick the auth mechanism by *who or what is acting*. | Option | Who it is for | Reach for it when | | --- | --- | --- | | **Workload identity federation** | Systems / CI running in a cloud (K8s, AWS, Azure, GCP, OCI, GitHub Actions, SPIFFE, X.509) | An automated workload needs to authenticate without a long-lived secret | | **Service accounts** | Non-human, org-owned identities | A shared automation or bot acts on behalf of the org, not a person | | **Personal access tokens (PATs)** | An individual, scriptable use | One person needs a token for their own scripted access | ```text 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) ``` :::tip[Assessment signal] `CI / Kubernetes / GitHub Actions authenticating without a stored secret` → **workload identity federation**. `Shared bot / org automation` → **service account**. `A person's own script` → **PAT**. ::: ## 4.3 Groups, provisioning, roles and permissions Governing access at scale means managing identities and what each can do. | Control | What it governs | | --- | --- | | **Groups & provisioning** | Who is in the workspace and how they are added/removed (user lifecycle) | | **Roles & workspace permissions** | What each member may do — admin vs member vs restricted | | **GPTs & sharing** | What can be created and shared, and with whom | 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. | Surface | Use it for | | --- | --- | | **Workspace analytics** | A dashboard view of adoption and usage | | **Analytics API** | Programmatic access to usage/adoption data for your own reporting | 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. | Surface | What it provides | | --- | --- | | **Compliance API & audit events** | A record of actions for compliance and investigation | | **HIPAA configuration** | Configuration for workloads handling protected health information | 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. :::tip[Assessment signal] `Prove who did what, investigate an incident` → **Compliance API / audit events**. `Protected health information` → **HIPAA configuration**. `Report adoption programmatically` → **Analytics API**. ::: ## 4.6 Codex Security and CI scanning Codex Security scans the code Codex (and your team) produces, across the plugin, CLI and cloud. | Capability | What it does | | --- | --- | | Scans / deep scans | Find vulnerabilities in code | | Security workbench | Triage findings | | Triage, fixes, hardening | Move from finding → fix → hardened code | | Vulnerability reports | Communicate risk | | CI / GitLab CI integration | Run scanning in the pipeline | | Cyber-safety models & trusted access | Governed, safety-aware security work | ```text 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)**: **R**ollout config, **O**wnership (auth), **S**cope (roles), **A**udit. | Step | Question | The move | | --- | --- | --- | | **Rollout config** | Are settings consistent across the team? | Managed configuration: model availability, permissions, allowed extensions | | **Ownership (auth)** | Who or what authenticates? | Workload identity for CI/cloud workloads; service accounts for org automations; PATs for individuals | | **Scope (roles)** | Who may do what? | Groups + provisioning + least-privilege roles and permissions | | **Audit** | Can we prove and measure it? | Compliance API / audit events; workspace analytics + Analytics API; Codex Security in CI; HIPAA config where required | ## Common mistakes | Mistake | Why it happens | What to do instead | | --- | --- | --- | | Letting each engineer configure their own Codex | Fastest to "everyone has it" | Use managed configuration for consistent settings | | Using a PAT for a CI pipeline | It is the token you know | CI/cloud workloads use workload identity federation (no long-lived secret) | | Using a personal account for a shared bot | It is already set up | Use a service account for org-owned automation | | Granting everyone admin | Fewer permission errors | Least privilege: few admins, most members, permissions match responsibility | | No audit trail | It was not set up | Enable the Compliance API and audit events from day one | | Manual, occasional security scans | Someone will remember | Integrate Codex Security into CI / GitLab CI so code is scanned before merge | | Assuming "internal use" needs no HIPAA config | The data feels contained | PHI requires HIPAA configuration regardless of internal framing | | Measuring adoption by anecdote | Dashboards feel optional | Use workspace analytics and the Analytics API for real numbers | | Leaving provisioning manual | Small team today | Automate provisioning so leavers lose access promptly | ## 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 | Trap | Why it is tempting | The discriminator | | --- | --- | --- | | "Let engineers self-configure; it is faster" | It removes admin work | At scale it causes drift; managed configuration enforces consistency | | "Use a PAT for the CI job" | It is the token on hand | CI/cloud workloads use workload identity federation | | "A personal account is fine for the shared bot" | Already set up | Org automation uses a service account, not a person | | "Internal PHI does not need HIPAA config" | The data feels contained | PHI requires HIPAA configuration regardless of framing | | "We will pull audit data if we ever need it" | Setup effort now | Audit events must be enabled up front to have a record | | "Manual monthly adoption numbers are fine" | Dashboards seem optional | Use workspace analytics and the Analytics API | | "Security scans can be a manual step" | People will remember | Put Codex Security in CI / GitLab CI so it runs before merge | | "Give everyone admin to avoid permission errors" | Fewer support tickets | Least privilege; permissions match responsibility | ## Practice questions Each item states how many responses to select. Attempt before revealing. A. Ask each engineer to configure their own Codex the same way B. Managed configuration set centrally by the admin C. A shared document describing the settings D. Nothing; defaults are fine **Answer: B.** Managed configuration lets an admin set and enforce settings centrally, avoiding drift. Self-configuration (A) and a document (C) rely on individuals matching settings by hand, and defaults (D) do not enforce the team's chosen policy. A. A personal access token committed to the repo B. Workload identity federation C. A shared admin password D. A service account password in an env file **Answer: B.** Workload identity federation lets cloud/CI workloads authenticate without a long-lived stored secret. A committed PAT (A) and a password in an env file (D) are stored secrets, and a shared admin password (C) is both a secret and a governance failure. A. An individual engineer's personal account B. A service account C. A group email inbox D. The admin's PAT **Answer: B.** A service account is a non-human, org-owned identity, which is exactly what a shared automation should use. A personal account (A) or the admin's PAT (D) ties the automation to an individual, and a group inbox (C) is not an auth identity. A. None; it is internal B. HIPAA configuration C. Only a stricter model D. Disable Codex entirely **Answer: B.** Workloads handling protected health information require HIPAA configuration. "Internal" (A) does not exempt PHI, a stricter model (C) is not the compliance control, and disabling Codex (D) is unnecessary when HIPAA configuration exists. A. The workspace analytics dashboard only B. The Compliance API and audit events C. The Analytics API D. `AGENTS.md` **Answer: B.** The Compliance API and audit events provide the action record used for compliance and investigation. The analytics dashboard (A) and Analytics API (C) are for adoption/usage, and `AGENTS.md` (D) is repo guidance. A. The workspace analytics dashboard B. Anecdotes from a few engineers C. The Analytics API for programmatic reporting D. Reading each engineer's shell history E. Guessing from license counts **Answer: A and C.** Workspace analytics (dashboard) and the Analytics API (programmatic) are the real measurement surfaces. Anecdotes (B), shell history (D) and license-count guesses (E) are not reliable adoption measures. A. As a manual step someone remembers to run B. In CI / GitLab CI via Codex Security C. Only after an incident D. Never; the model is trusted **Answer: B.** Integrating Codex Security into CI / GitLab CI ensures code is scanned before merge automatically. A manual step (A) gets skipped, post-incident scanning (C) is too late, and trusting the model without scanning (D) is the risk to avoid. A. None; it is efficient B. It violates least privilege; permissions should match responsibility, with few admins and most engineers as members C. Admins cannot code D. It disables analytics **Answer: B.** Granting universal admin breaks least privilege and widens the blast radius of mistakes and compromise. It is not simply efficient (A), admins can of course code (C), and it does not disable analytics (D). A. No problem; PATs are for automation B. A PAT ties an org automation to one person and breaks when they leave; use workload identity federation or a service account instead C. PATs are slower; switch models D. Use the admin's PAT instead **Answer: B.** A personal token binds an org automation to an individual, creating a fragility and governance gap; workload identity or a service account is the correct org-level identity. PATs are for individuals, not org automation (A); the fix is not a model change (C); and using the admin's PAT (D) has the same personal-account problem. A. `AGENTS.md` in each repo B. Managed plugin / connector / skill controls at the workspace level C. Each engineer's local settings D. The model picker **Answer: B.** Workspace-level plugin/connector/skill controls decide which extensions are allowed. `AGENTS.md` (A) is per-repo guidance, local settings (C) are per-engineer and ungoverned, and the model picker (D) selects models, not extensions. A. To pick the model automatically B. To manage who is in the workspace and ensure leavers lose access promptly (user lifecycle) C. To scan code D. To generate adoption reports **Answer: B.** Groups and provisioning manage membership and the user lifecycle so access is granted and revoked correctly. They do not select models (A), scan code (C, that is Codex Security), or generate reports (D, that is analytics). A. HIPAA configuration for PHI-handling repositories B. Broad auto-approve to speed things up C. Compliance API and audit events for the action record D. Disabling analytics for privacy E. A single shared admin account for everyone **Answer: A and C.** A regulated workload needs the right configuration (HIPAA for PHI) and an audit trail (Compliance API and audit events). Broad auto-approve (B) increases risk, disabling analytics (D) removes useful oversight, and a shared admin account (E) destroys accountability. A. The CLI only B. The plugin, the CLI and the cloud C. Only after purchasing a separate product D. Only in the IDE extension **Answer: B.** Codex Security spans the plugin, CLI and cloud, with scans, workbench triage, fixes and CI integration. It is not CLI-only (A) or IDE-only (D), and it is part of the Codex security surface rather than a wholly separate purchase (C). A. Workspace model availability B. `codex exec` C. The reasoning ladder D. Record & replay **Answer: A.** Workspace model availability controls which models the workspace may use. `codex exec` (B) is a run mode, the reasoning ladder (C) sets effort, and record & replay (D) captures sessions — none restrict model availability. ## 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".