Codex security guide: agent access and release checks

By Thunkle · Platform references checked 19 September 2026

Codex permissions and application security protect different things. Restricting an agent's filesystem or network access can reduce development risk. It does not establish that customers of the finished app can access only their own records.

This guide covers using Codex to build software and reviewing that software before release. It is not documentation for the separate Codex Security scanning product, nor an assessment of OpenAI's infrastructure. Thunkle's application security audit can review a Codex-built codebase against the product's actual requirements.

Get developer review of the application, not just the agent

When Codex completes a task, a developer should evaluate the resulting change against requirements the agent may not have been given: customer isolation, staff privileges and valid payment transitions, for example. Review the implementation and test both permitted and rejected actions. An approved tool call or a passing test suite provides useful evidence, but neither alone establishes that the released app meets those requirements.

Request a paid security review of your Codex-built app for a developer-led audit of the agreed release paths. Thunkle documents the observed behaviour, findings and remediation priorities, then re-reviews agreed fixes free. Implementation is quoted separately from the review.

Establish what this Codex session can access

OpenAI distinguishes the sandbox, which constrains available actions, from the approval policy, which determines when approval is required. Local and cloud environments have different execution boundaries. Use the official instructions for your installed client and configuration; do not infer effective access from the absence of prompts. OpenAI's agent approvals and security documentation.

Record the working directory, writable locations, network policy and connected services. Check which credentials are available to commands or tools. A narrowly scoped checkout is useful, but a connected deployment or database tool can still have important authority of its own. Review its account and permissions separately.

For ordinary feature development, use development resources and test credentials. Avoid copying customer exports into a workspace simply to make the agent's tests realistic. Synthetic fixtures are easier to share, review and clean up without creating another sensitive-data store.

Separate permission to build from permission to release

In a synthetic project, a routine source push might automatically deploy the website. “Can run Git” and “can publish to customers” are therefore connected permissions, even if the task looks like a file edit.

Map those side effects explicitly. Which branch deploys? Does a build run migrations? Can a test send email? What credentials can a setup script use? A successful local test is not authorization to execute the same script against a production database.

Keep sensitive deployment steps behind an appropriate review or approval process outside the prose of the prompt. Instructions are useful; operational permissions and release controls provide a different layer of protection.

Treat external context as input, not authority

An issue, documentation page, tool response or repository file may contain instructions the agent encounters during a legitimate task. Review any proposed expansion of scope against the actual request. A page telling the agent to upload a local file is not permission from the person who owns that file.

For connected tools, prefer the smallest useful access. Reading schema information and executing database writes are different capabilities. If production inspection is necessary, arrange suitable read-only access and avoid returning sensitive rows when schema or synthetic examples answer the question.

Review the code that will actually run

Use a synthetic team-workspace feature as an acceptance exercise. One organization member may read a shared project, a visitor may not, and a removed member must lose access. Inspect how the server establishes membership rather than trusting a browser-supplied organization identifier.

Test each permitted operation successfully before testing the denied cases. Review raw responses for unintended fields, and inspect stored state after a rejected write. Include background jobs and privileged service clients where they bypass ordinary user-level database permissions. Our authorization worksheet helps capture these expectations.

Also review changes to tests, package scripts, dependencies and deployment configuration. A green build proves that a particular set of checks passed; it does not certify the application's access model.

When to add an application audit

An audit is especially useful before a release involving multiple customers, payments, private files or new administrator capabilities. Automated scans and agent review remain valuable inputs. Ask the reviewer to validate findings and state which workflows and environments were actually examined.

Is this the same as running Codex Security?

No. A product scan and a commissioned application audit can have different inputs and scope. Compare the actual coverage and evidence rather than treating the names as equivalent.

Do I need to stop using Codex?

No. The aim is a controlled development process and a tested release, not removing a coding tool. No audit can guarantee the absence of every vulnerability.

Request a security audit quote with the app URL, roles and release goals. We agree scope and authorized test actions first, then provide prioritized findings, remediation guidance and a free re-review of agreed fixes. Do not include credentials in the quote form.