OpenAI announced an upgrade to Codex Security Cloud on September 29, 2026, with ongoing checks of GitHub commits and included access to Daybreak Blue models within Cloud. Application-security teams enabling that workflow need evidence tied to their release revisions and deployment assumptions.
An enabled monitor leaves several ways to miss work. A release branch may sit outside its scope. The team may have corrected the threat model after the last scan. Scanning can also pause when funding is unavailable. Before relying on a quiet findings queue, reconcile the work you expected with the evidence the scanner produced.
The procedure below is our engineering interpretation of OpenAI's current documentation. We have not run a Cloud scan or measured its detection accuracy.
Establish who can change the scan#
Cloud remains a research preview. Its plugin scans connected GitHub repositories; the local Codex Security plugin and CLI are separate surfaces. The included Daybreak Blue access applies only within Cloud, so check local-plugin and API eligibility separately.
For Enterprise and Edu, OpenAI documents separate permissions for using Codex Cloud, using Codex Security, and administering Security scan configurations. Limit administration to the people responsible for coverage: changing the scan's context can change how later results should be interpreted.
Connect only the repositories approved for the pilot. In New Scan, check the selected environment: Auto creates one at scan start; Customize selects an existing one. Choose One-Time Scan for the initial assessment. Cloud setup describes these controls.
Review that environment's setup and credentials before running it against sensitive code. A scanner that executes repository build steps needs the same scrutiny as other privileged coding-agent workflows. Use test fixtures and narrowly scoped access for any required services.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Correct deployment assumptions before trusting the baseline#
The generated threat model supplies context for future commit scans and prioritization. Open Repositories > Monitoring settings > Project context > Threat model to edit it. OpenAI explicitly says changes apply to future scans.
Consider a hypothetical document-processing service. Its repository contains a worker that reads files from a queue. The generated summary calls the queue internal and treats its inputs as trusted. In production, customers upload those files through a separate gateway repository.
The worker's code alone may not explain that route. Have the service owner correct the context to name the public upload path, the gateway's checks, the worker's own validation, and the credentials available to the worker. Avoid a vague instruction to "focus on security."
If the old scan treated uploads as trusted, the parser still needs review under the corrected assumption. Request that assessment explicitly. Keep the earlier report attached to its original context instead of treating the saved edit as completed work.
Record a copy or revision of the reviewed context outside the mutable settings screen. We recommend including its approval date and owner. These are your team's records; the docs do not establish an automatic threat-model revision ledger.
Reconcile monitoring with the revisions you release#
To enable ongoing work, select Continuous Scanning and review Scan commit history from. OpenAI's setup instructions specify the repository's default branch. Monitoring settings let you change the environment and history window or pause monitoring.
Start with the release inventory: repository, release branch, and exact source revision. Then inspect completed scans and available artifacts for evidence covering that requirement. Preserve anything you cannot match as unknown. A recent scan timestamp does not identify every revision it examined.
The following actions are our recommended coverage policy, derived from the documented monitoring scope, future-scan context changes, and funding behavior.
| Observation | Coverage question | Action before relying on the result |
|---|---|---|
| Production ships from a maintenance branch | Did any assessment cover that branch's release revision? | Obtain a separately scoped assessment or record the release as outside this monitor. |
| The chosen history window begins after a relevant change | Was that older code covered by a repository assessment? | Review the baseline; arrange broader assessment if the evidence is missing. |
| The threat model changed after a completed scan | Which components depended on the old assumption? | Reassess those components and retain both context versions. |
| Scans paused for lack of funding | Which expected reviews have no completed evidence? | Resolve funding through the authorized owner, then reconcile the gap. |
| Monitoring is enabled again | Has the missed work actually completed? | Inspect resulting scans; do not assume resumption backfilled the gap. |
OpenAI says existing customers receive notice and must opt in before paid usage begins. If funds are unavailable, scanning pauses. Treat that as an operational monitoring condition: assign someone to check scan progress and unresolved coverage, alongside the person reviewing findings. Billing guidance.
The docs describe pausing monitoring without specifying what happens to an already-running job. If your task is to stop access, investigate active work and repository authorization separately.
Read validation failures before closing findings#
According to the Cloud FAQ, Codex can produce findings without compiling the project. Validation may attempt a build and run commands in an isolated container. When reproduction fails, the finding remains unvalidated and the attempt's logs and reports remain available.
In the upload-worker example, a missing queue dependency could prevent reproduction even if the source-level concern is plausible. A successful reproduction under permissive test settings also needs comparison with the deployed configuration. Have an engineer read the attempt and the relevant code path before deciding whether to fix, investigate, or dismiss the finding.
Keep three decisions separate in the review record: whether the suspected defect is supported, whether the proposed patch addresses it, and whether the release's required coverage is complete. One validated finding does not settle the last question. OpenAI describes the scanner as a complement to SAST and human review, so retain those other checks.
Keep a coverage record that survives configuration changes#
Use a short record in your existing security tracker. This illustrative YAML describes a hypothetical coverage gap; it is neither a Codex API response nor a configuration file. Replace the example values with evidence from your own repository and leave unavailable observations unresolved.
Code source: illustrative.
repository: example/upload-worker
required_release_branch: release/2026-10
required_release_revision: null
monitor_default_branch: main
monitor_history_start: null
reviewed_context: upload-boundary-v2
completed_scan_evidence: null
coverage_status: unresolved
gap: Release-branch assessment has not been established.
owner: Application security
next_action: Match release revision to completed assessment evidence.
Record the scan reference, observed revision or range, environment, context copy, and any unresolved validation when that evidence is available. Do not populate a missing value from the monitor's current settings: those settings may have changed since the scan ran.
If you also enable Codex Security Review on pull requests, record its configuration separately. Automatic reviews default to High and Critical reporting; manual reviews include Medium as well. A quiet PR can therefore reflect a reporting threshold. Open the full report in Codex, and remember that posted findings inherit the PR's GitHub visibility. Repository monitoring and PR reporting should not silently substitute for one another.
Accept a monitoring period only when the evidence covers the source and assumptions your team required, or a named owner has accepted the remaining gap. The assessment worksheet can help document broader evaluation requirements.
Frequently asked questions
- Does continuous scanning cover every branch?
OpenAI's Cloud setup guide says Continuous Scanning scans the repository's default branch. Record other release branches as separate coverage requirements; do not infer their coverage from an enabled monitor.
- Does editing the threat model update earlier findings?
OpenAI documents threat-model changes as applying to future scans. Preserve earlier evidence with its original context and decide which affected code needs reassessment. Saving new context does not establish that earlier work was repeated.
- What happens when a finding fails validation?
The finding remains unvalidated, with logs and reports describing the attempt. Investigate whether the issue is unsupported or the environment prevented reproduction before closing it.
