The 5 Access Boundaries Your ChatGPT Enterprise Seat Does Not Control

SSO can be live, SCIM can be syncing, and a Codex pilot can still stop before its first pull request. I hit the same class of failure in this site's publication workflow: the repository MCP was configured, but its database call returned a permission error while a finished post waited for publication. The first check found zero rows; adding the project-scoped server and completing one OAuth grant made the same read return one. That was an access failure, not a model failure.

Most enterprise teams start by assigning seats. A seat opens a product surface; it does not open every repository, runtime, network, or merge path. I treat the rollout as an access-design problem, not a seat-purchase problem.

Usage shows adoption, not safer code or time saved. A rollout is successful only when a named team can complete bounded work with the right access, approvals, tests, review, and evidence.

The rollout works when five boundaries line up:

1. Seat access
2. Workspace roles and identity
3. GitHub repository permissions
4. Runtime, network, and approval controls
5. Monitoring and human review

OpenAI’s ChatGPT Enterprise admin quickstart recommends setting up identity, groups, roles, security controls, and monitoring before broad onboarding. That sequence matters more than the number of seats you purchase.

1. A seat controls product access

OpenAI currently describes two Enterprise seat types. A standard ChatGPT seat includes ChatGPT and Codex, subject to workspace settings. A Codex seat provides Codex access without ChatGPT access. Codex seats use usage-based billing, so check the current Enterprise seat guidance before building a budget model.

Use standard seats for people who need ChatGPT and Codex. Use Codex seats for specialists whose work stays inside Codex.

My rule: never confuse an invoice line item with authority.

A seat does not grant API Platform membership, GitHub access, local terminal permissions, or every workspace feature.

2. Workspace roles and identity control who can use the surface

Name a Workspace Owner and a small group of Workspace Admins. Give each person one responsibility: identity, GitHub, Codex environments, security, or pilot support.

Use verified domains, SSO, and SCIM before broad onboarding. Create groups around different access needs, such as codex-pilot, codex-admins, sensitive-repos, and reviewers.

SSO answers sign-in; SCIM answers workspace membership. Neither answers which repository a person can change. GitHub controls that boundary.

My rule: identity is provisioning, not repository authorization.

3. GitHub controls the repository boundary

OpenAI’s Codex Enterprise admin guide says the setup requires GitHub access to the repositories used by the organization. Codex can work with a connected repository and create a cloud environment, but GitHub remains the source of truth for repository membership, team access, branch protection, and merge permissions.

Start with a low-risk repository. Confirm organization approval, visibility, team membership, protected branches, required checks, and who can merge. Add sensitive repositories only after the team has tested the full path.

My rule: the first repository should be boring enough to test the workflow, not impressive enough to hide its failures.

Codex review adds another signal. The official GitHub review guide explains @codex review, automatic reviews, and repository-specific guidance in AGENTS.md. Review does not replace tests, branch protection, or human ownership of the merge.

4. The environment controls what the agent can do

Codex cloud environments add another boundary. The environment defines the repository, branch or commit, runtime, dependencies, environment variables, and internet access available to the task.

For a first pilot, keep internet access off unless a task needs it. Pin runtime versions. Keep setup separate from agent actions. Review which secrets are available at each stage.

My rule: secrets are a boundary, not a convenience.

For local work, put the stack, test commands, sensitive paths, and stop conditions in AGENTS.md. Guidance improves behavior; it does not grant access to GitHub, the workspace, the API Platform, or production systems.

5. Approval and monitoring control the risk boundary

Sandboxing limits what Codex can touch. Approval policy decides when it must stop and ask. Use both.

Start read-only, then allow workspace edits with approval on request. Require review before network calls, untrusted commands, production actions, or anything that changes an external system.

My rule: an approval that is not recorded is only a feeling.

Measure outcomes alongside usage. Workspace analytics show adoption. GitHub shows pull requests, review findings, tests, and rollbacks. Support tickets and a short pilot survey show where the workflow breaks.

Usage shows adoption, not safer code or time saved.

A 30-day rollout

Days 1–5: choose one team, two or three repositories, three task types, owners, stop conditions, and measures. Days 6–10: configure SSO, SCIM, groups, GitHub, branch protection, and one read-only task. Days 11–20: run bounded issues with explicit files, tests, approvals, and evidence. Days 21–30: compare completed pull requests, test pass rate, rework, approvals, and incidents; remove unused access and expand only when the team can repeat the safe path without an expert rescue.

The next phase will make the boundary more dynamic: agents will request narrowly scoped repository, environment, and tool access for a task, then lose it when the task closes. Teams that record those grants, approvals, and outcomes will have a much clearer audit trail than teams that treat an AI seat as standing access.

If you need the operator version first, use the Codex tutorial and ChatGPT Work tutorial. For team-level operating support, see Team Brain.

Which boundary would block your first Codex pilot today: identity, GitHub, environment access, or approvals?

---

P.S. The fastest way to find the missing boundary is to run one real, low-risk task and document exactly where the agent had to stop.