Practical guide

Codex security: sandbox and approvals

The objective is to configure sandbox, network and approvals to match risk. The review baseline covers workspace boundary, write access, network, secrets and external effect.

LOL.MARKETING / CONNECTING INTELLIGENCE

The essential answer

Codex security combines technical sandbox boundaries, approval policies and permissions for additional tools. Assess these layers separately. Local execution means neither fully offline processing nor automatic protection of every connected service.

01 / FIT

A good fit when

  • A concrete assignment and an accountable domain owner are defined.
  • A recorded boundary test shows permitted work in the workspace and handling of forbidden writes, network access or external effects. Secrets appear neither in the result nor in unnecessary logs.

02 / LIMITS

Not the first choice when

  • Avoid: putting convenience ahead of least privilege. If permissions are expanded for convenience without assessing the concrete need and additional effects, the basis for accountable approval is missing.

Configure sandbox and approvals separately

The sandbox technically limits access by executed commands. Approval policy determines when additional confirmation or review is needed. A permissive approval setting does not narrow access; a prompt alone does not provide technical isolation. Check the effective configuration for the chosen host and task, including overriding organisation rules.

Limit tool identity and API keys separately

Apps, browser access and MCP tools bring their own permissions into a task. Check them in addition to the file sandbox. For API integrations, OpenAI documents expiration dates and administrative limits on creating new keys this September. Organisation rules take precedence over project rules; a new creation restriction does not retrospectively revoke existing keys. A key register and planned rotation remain necessary. These API controls replace neither Codex approval rules nor permission checks for a connected app.

Test the boundary directly

An allowed task should work inside the intended project. A deliberate boundary test checks forbidden write destinations, unnecessary network access and denied external actions. Evaluate observed behaviour rather than only the displayed setting. Repeat the affected test after permission changes. A successful build does not replace this security check.

Decision matrix

Decision pointProceed whenStop when
Data and accountabilityDocumented: workspace boundary, write access, network, secrets and external effect.Scope, data or accountability remains unresolved.
Control evidenceA recorded boundary test shows permitted work in the workspace and handling of forbidden writes, network access or external effects. Secrets appear neither in the result nor in unnecessary logs.There is only an unevaluated demo without acceptance evidence.
Approval boundaryOwner, approval, fallback and next review date are defined.Avoid: putting convenience ahead of least privilege. If permissions are expanded for convenience without assessing the concrete need and additional effects, the basis for accountable approval is missing.

Keep it verifiable

Primary sources

The next sensible step

Which AI system fits your business?

Eight steps from a general interest in AI to a clearer decision for your business.

Start AI System Check
FreeProvider-neutralNo credentials