An assistant produces an answer. An agent can inspect a repository, run commands, change files, test software, and propose actions that reach other systems. That difference moves the enterprise architecture question beyond model capability. The first question is now: under whose authority, inside which boundary, and with what evidence may the system act? OpenAI documents the primitives that make this question operational. Luminity's independent architectural interpretation is that they form the basis of a governance-first execution architecture: not a promise of correct outcomes, but a disciplined way to bound consequential agency from its first action.
The Primitive: A Controlled Execution Environment
Codex is often introduced through its outputs: code, tests, fixes, reviews, and completed tasks. For enterprise architecture, the more durable primitive is the environment in which that work occurs.
OpenAI documents two control layers. Sandbox mode determines what model-generated commands can technically do, including where they can write and whether they can reach the network. Approval policy determines when Codex must stop and ask before acting. Local execution uses an operating-system-enforced sandbox; Codex cloud uses isolated OpenAI-managed containers. Cloud environments separate setup from the agent phase: agent-phase network access is off by default unless explicitly enabled, and setup secrets are removed before that phase begins. [1]
This is the narrow documented guarantee: Codex supports bounded execution through explicit runtime and decision controls.
An enterprise agent acts from an identity, inside a workspace or cloud environment, against repositories and tools, with defined filesystem and network reach. Intelligence becomes operational only through that envelope.
The Enterprise Property: Permissioned Execution
Luminity’s architectural interpretation is that these controls make permissioned execution possible: the technical capability to act can be separated from the authority to act, and both can be made narrower than the model’s general capability.
OpenAI’s permission profiles express least privilege for local command execution. A named profile can combine filesystem and network rules, allowing a task to inspect or edit selected workspace roots without broad machine or network access. The boundary is explicit: permission profiles govern sandboxed local commands, while connectors, MCP servers, browser and computer-use surfaces, Codex cloud, and approved escalations retain separate controls. The feature is beta and may change; the architectural principle is more durable than any configuration key. [2]
Enterprises therefore need not treat autonomy as one global switch. Authority can fit the workflow: read-only inspection for one task, bounded workspace writes for another, and broader privileges only where identity, review, and recovery justify them.
This is an operating-model choice. Teams can define what the agent may inspect or change, what requires a decision, which integrations are valid, and what evidence a change must produce.
Policy Moves to the Point of Execution
Written policy describes intent. Runtime policy changes what can happen.
OpenAI’s managed configuration lets administrators constrain supported local runtime behavior across covered capabilities in the ChatGPT desktop app, Codex CLI, and IDE extension. Requirements can constrain approval policy, sandbox mode, permission profiles, web search, managed hooks, MCP servers, and plugin marketplace sources. Administrator-enforced requirements cannot be overridden; managed defaults can change during a run and reapply when the client restarts. Coverage differs by client and version, and managed configuration does not replace workspace role-based access control. [3]
For enterprise architecture, that distinction creates three separate statement classes:
- OpenAI-documented capability: supported runtime settings can be constrained centrally on covered clients.
- Luminity architectural interpretation: policy can be applied closer to the point where consequential work executes.
- Luminity enterprise recommendation: define a small set of workflow-aligned permission profiles, test them with representative users and clients, and widen them only when assurance evidence supports the change.
Instructions remain operating procedure, not deterministic enforcement. Repository guidance, skills, and review criteria express purpose; sandboxes, permission rules, managed requirements, downstream authorization, and repository protections constrain different parts of what can occur. A credible design uses both without confusing them.
Authorization Is Compositional
The execution boundary is not one control plane. It is a composition of boundaries.
OpenAI’s administration guidance identifies six control boundaries: the ChatGPT workspace, local clients, Codex cloud, the OpenAI API Platform, plugins, and connected systems. Access at one does not grant access at another. Workspace permissions, managed configuration, cloud eligibility, API roles, plugin controls, and source-system authorization remain separate. [4]
An approval is therefore a decision inside one execution flow—not universal authorization. A user may approve a command while a branch rule blocks the merge. A plugin may be available while its connected system denies the action. A workspace role may permit Codex use while a local permission profile denies network access.
Effective authority is the intersection of these boundaries: every applicable boundary must permit the action. OpenAI controls its documented surfaces; the enterprise remains responsible for identities, credentials, repository protections, secure development, data governance, connected-system permissions, and human accountability.
The Operational Consequence: Govern First, Then Widen
The strongest objection to governance-first is velocity: it can sound like completing an enterprise-wide control regime before one useful workflow begins. That is not the recommendation.
Governance-first begins with a minimum viable execution boundary: the smallest useful combination of identity, workspace, runtime, filesystem reach, network policy, integrations, approvals, and downstream permissions for one consequential workflow. It should be narrow enough to understand and reverse, yet useful enough to produce evidence from real work. Governance is not a separate program before value; it defines how the first value is created.
Because effective authority is the intersection of applicable boundaries, expansion should change those boundaries deliberately. Luminity recommends a five-stage sequence:
- Establish the minimum viable execution boundary. Select one owner, one workflow, and the narrowest viable Codex envelope: workspace, sandbox mode, permission profile, approvals, network access, integrations, cloud eligibility, and downstream authorization.
- Run and validate inside it. Use task instructions, reusable procedures, tests, review criteria, repository protections, and recovery paths to assess the work without exceeding the intended envelope.
- Collect boundary-specific evidence. Examine validations, approval decisions, denied or exceptional actions, human review, change artifacts, and supported operational records. Locate friction in the workflow, boundary, or connected system.
- Change one named authority dimension. Through an accountable decision, grant network access, add an integration, extend filesystem reach, alter an approval, permit cloud execution, increase cadence, or admit another user population. Avoid changes whose effects cannot be separated.
- Retain, tighten, or revoke. Compare the result with the prior envelope. Keep evidence-supported changes; reverse those that weaken quality, control, or accountability; reassess as product behavior, dependencies, incidents, and risk change.
This sequence turns assurance into feedback on a named authority boundary. The model may remain constant while the enterprise operating envelope expands through observable and reversible decisions.
A minimum viable boundary reduces the first decision, makes failure cheaper to contain, and creates evidence for expansion. Starting broad may accelerate access, but it makes outcomes harder to attribute and authority harder to unwind. Governance-first trades a small amount of initial reach for faster, more credible scale.
Evidence Makes the Boundary Operable
Governance becomes credible when it connects authorized intent to bounded action, produced change, validation, accountable review, and operational records.
OpenAI positions the Compliance API for security, legal, governance, and investigation workflows requiring auditable records. It separates those records from adoption analytics and cautions against using compliance data as a productivity dashboard or to infer code quality or individual performance. [5]
That separation should remain visible in the architecture:
- Validation asks whether the produced work passed defined tests, checks, or review criteria.
- Analytics describes how a system is used and how adoption or activity changes.
- Audit evidence supplies supported records for governance, investigation, retention, or legal processes.
None substitutes for another. A passing test is not an audit record; an adoption trend is not proof of compliance; an audit event does not prove a decision correct or establish complete provenance.
Design evidence requirements with the boundary. Decide which change artifacts, validations, approvals, identities, lifecycle records, and downstream logs are required before authority expands. Evidence should improve future policy and procedure, not decorate deployment.
Limits and Failure Boundaries
Governed execution is not risk-free execution. Sandboxing reduces technical reach; it does not prove correctness. Approval creates a decision point; it does not guarantee a safe choice or confer authorization in every downstream system. Managed configuration constrains covered capabilities on supported clients; coverage varies by client and version. Permission profiles bound local commands; other surfaces retain their own controls.
Repository protections, credential design, supply-chain assurance, data classification, secure development practices, incident response, and human accountability remain necessary. Connected services can introduce their own trust and authorization boundaries. Audit records can support investigation and governance without establishing complete decision provenance.
The failure mode to avoid is architectural compression: treating operating guidance as enforcement or one control decision as enterprise-wide authority. The correct design preserves the seams between boundaries and makes their composition explicit.
Enterprise agentic systems should create their first value inside a minimum viable execution boundary, then earn wider authority through evidence.
OpenAI’s documented primitives make bounded, administered, and evidenced execution possible. Luminity’s durable claim is that the execution boundary—not model capability alone—should determine how enterprise agency begins, expands, and remains accountable. Governance-first narrows the first deployment so the enterprise can move quickly without making its first grant of authority broad, opaque, or difficult to reverse.
Bound the first workflow. Prove it in operation. Widen one authority dimension at a time.
