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.

WERKVERSTAND / 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.

Assess connected tools separately

A local coding task can use additional apps, browser access or MCP tools. Include their identities and permissions even when local file access is narrow. Record possible external changes and applicable controls. Run sensitive test cases with suitable substitute data; credentials must appear neither in the diff nor in unnecessary logs.

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