An enterprise rollout of Codex starts not with granting full access but with an inventory. Before enabling anything, you draw a map: which surfaces are used, what identity, which repositories, what data policy, which models are allowed, how plugins and skills are controlled, what network and who is responsible for support. The temptation to "give everything and see what happens" is especially costly at the organization level, because a mistake is replicated across everyone. Inventory first, then conscious enabling in parts.
Managed requirements is the tool by which an organization sets mandatory boundaries. Through requirements you can restrict the allowed approval policies, sandbox modes, MCP identity, hooks, the reviewer for auto-review, network domains, plugins and skills. The key property distinguishing requirements from ordinary config: user config must not be able to expand the enforced boundary. An ordinary layer can be overridden by a layer above; a managed requirement cannot, and that is the whole point of centralized policy.
It helps to separate the roles of the configuration mechanisms in a table once. System, user and project config.toml set defaults that a lower layer can override by precedence. requirements.toml sets admin-enforced constraints and allowlists that cannot be overridden. These are different things by nature: one is convenient defaults, the other mandatory frames. Confusing them means either expecting from config guarantees it does not give or from requirements a flexibility it deliberately lacks.
The rollout is led in order rather than enabling everything at once. First you create a non-production pilot identity, check the provider and models, access and behavior on it. Then you deploy the managed policy to a canary group rather than everyone at once: invalid entries may be stripped, and security-sensitive boundaries must fail closed. And only on a verified base do you enable the rest. Enterprise forgives less than a local setup, so order and gradualness here are not bureaucracy but protection.
| Mechanism | Role |
|---|---|
| System/user/project config.toml | Defaults a lower layer overrides by precedence |
| requirements.toml | Admin-enforced constraints and allowlists (cannot be overridden) |
| Provider (e.g. Bedrock) | A model deployment; != equivalent of ChatGPT sign-in |
|---|
| Analytics | Adoption, cost, behavior - without source content |
|---|
The provider in enterprise is a separate decision, and Bedrock is telling as an example. Local Codex surfaces can use OpenAI models available through Amazon Bedrock, with AWS-managed authentication and access control. But this is exactly a provider deployment, not an equivalent of signing in through ChatGPT. From having access to models through Bedrock you cannot automatically assume access to the cloud, workspace features or connectors: these are different things, checked separately rather than assuming that "since the models work, everything works".
Analytics and observability at the organization level are what make a rollout manageable rather than blind. An organization needs to see adoption, cost, behavior and denials - but not the content of sources without a documented necessity. Here is the same privacy boundary as everywhere: you collect what is needed for operation and security and do not collect the excess. Observability is built consciously, understanding which dimensions carry value and which a privacy risk and cost without benefit.
The point of the enterprise approach is that trust is granted centrally and consciously, not by default. Requirements set the mandatory, config the convenient, the provider is chosen for identity and billing, analytics for need. All this is layers of one architecture where the organization is responsible for the boundaries rather than shifting them onto each user. Autonomy and broad access are a consequence of the rollout's maturity, not a starting point: they are widened as the environment proves it copes.
The typical enterprise rollout failures are predictable. Starting with full access instead of an inventory and rolling out a problem to everyone. Relying on user config to hold boundaries that should be in requirements. Deploying the managed policy to everyone at once, skipping the canary. And assuming from access to models via Bedrock access to the cloud and workspace. Start with an inventory, keep the mandatory in requirements, roll out through a canary and do not confuse a provider deployment with full access to the ecosystem.