OpenAI has published details of two cybersecurity products, Daybreak Red Team and Daybreak Defense Factory. Daybreak Red Team, which targets web applications, verifies attack paths and whether fixes actually work; it is currently accepting early-access sign-ups. Daybreak Defense Factory analyzes issues found by Red Team or existing security tools and helps create code fixes that developers can review.
Finding a vulnerability and confirming that a fix has resolved it are separate tasks. With the two products, OpenAI describes a workflow that covers attack-path verification, fix drafting, human review, and re-verification after the code is merged. However, Defense Factory is still a research preview, and with continuous monitoring, the meaning of the results depends on the scan scope and execution conditions you configure.
AI Agents Verify Web App Vulnerabilities and Re-Check After Fixes
Daybreak Red Team is a product that performs penetration testing on web applications, verifying attack paths in authorized environments. According to OpenAI, multiple AI agents work together, analyzing source code and application structure while exploring exploitable paths and validating vulnerabilities. Rather than simply flagging suspicious spots in the code, it is designed to determine how an issue actually affects the application's behavior.
Existing security tools and externally submitted reports can also be verified. The product investigates code scanner findings, reports submitted through bug bounty programs, and information received through vulnerability disclosure, and uses the evidence it gathers to prioritize fixes. OpenAI also says it can confirm whether a patch now blocks the attack, and can repeat verification after the application is updated.
Understanding this approach requires distinguishing between traditional scanners, which point out possible vulnerabilities, and the work of checking whether those findings are actually exploitable. OpenAI describes its existing Codex Security similarly: it supplements scanner findings with repository-specific investigation and verification. It examines input data, code execution paths, and existing defenses to decide whether a finding needs action, is out of scope, or requires further review. The sources it can investigate include GitHub code scanning, Dependabot, security advisories, and reports managed in Jira and Linear.
The announcement is less a debut of entirely new capabilities than a presentation of a mechanism linking attack-path verification with code fixes as two products. That said, the published descriptions of the verification features come from OpenAI itself and should be distinguished from independent performance evaluations by third parties.
From Verified Findings to Fixes Humans Can Review
Daybreak Defense Factory takes issues found by Red Team or existing security tools, analyzes the vulnerabilities in the code, and creates patches. Developers can give Codex additional information and adjust a proposed fix while reviewing the verification results. Changes are not automatically finalized into the code; engineers decide after review and testing.
According to the official documentation, when you instruct the tool to fix an issue, patch generation runs in the background. Developers can review the proposed code diff and the results of the "Patch checker," which validates the fix, and can create a draft pull request on GitHub. A person then reviews the code and runs tests, and the issue is treated as fixed only after confirming that the original attack path no longer works in the merged code.
In investigating a vulnerability, developers can see the evidence behind the detection, its cause, and the attack path. When evaluating a proposed fix, they can see not only the changed code but also how the change addresses the root cause and what the Patch checker verified. The key point is to distinguish between the stage at which a fix is proposed and the stage at which it is confirmed that the problem is resolved in the patched code.
OpenAI says that when it is safe and practical, it reproduces the issue and prepares a narrowly scoped patch along with verification results. Where feasible, it also adds a regression test that fails before the fix and passes after it. When a safe and reliable test cannot be created, the approach is to record what could not be verified. Engineers then decide whether to adopt a fix based not just on the code diff but also on which issues were reproduced and which items remain unverified.
Evaluating a fix also means checking not only that it blocks attacks but that legitimate operations continue to work. In an example in the official documentation involving an export feature, a handler was missing a check that the requester belongs to the project. The documentation says to verify both a test that rejects an unauthorized request from another project and a test that allows an export by a properly authorized user. Rejecting unauthorized requests is not a proper fix if it also blocks legitimate ones. This example illustrates how to judge a fix's validity and is not a measured result of real-world deployment effectiveness.
What Can Continuous Monitoring Actually Scan?
Vulnerability scanning comes in several forms: a one-time scan that examines a repository once, continuous monitoring that targets new commits, and scheduled scans that repeat at set intervals. Each differs in what it scans and when it runs, so enabling continuous monitoring does not mean all code is scanned every time. Based on OpenAI's official setup guide, the differences are summarized below.
| Scan type | Main target | Timing |
|---|---|---|
| One-time repository scan | Current code on the default branch | When the scan is started |
| Continuous monitoring of new commits | New commits to the default branch | Runs in response to new commits |
| Scheduled scan | Default branch | Re-scans on the configured schedule |
Note: Summary based on the current official specification. Scan targets can be the entire repository or limited to specific folders or files.
Monitoring new commits and periodically re-scanning the default branch differ both in the conditions under which scans run and in what they cover. Continuous monitoring also lets you configure how far back through past changes to look, but results from scanning new commits alone cannot be taken to mean that the entire existing codebase was checked each time. When evaluating scan results, you need to check both the code scope you configured and the scope that was actually scanned.
If a scan fails partway or finishes earlier than expected, the official guide asks users to check how much was actually scanned. OpenAI says scans of large repositories can take several hours. Without checking the breadth of the scan and whether it completed, the absence of reported vulnerabilities cannot be taken as proof that security has been sufficiently verified.
Early-Access Terms and the Performance Data Still Needed
For Daybreak Red Team, OpenAI says it controls the verification scope using an isolated environment and review by "Guardian," limiting the applications and connection destinations the AI agents can access. However, the product page does not disclose Guardian's specific decision criteria or how accurately it can block dangerous operations. In real deployments, it will be important to clearly define the environments and connection destinations where testing is permitted.
For Daybreak Defense Factory, the official setup guide says to install the preview plugin in a supported ChatGPT workspace. Cloud scanning runs on Codex cloud, and each user who starts using it needs a personal GitHub connection. Workspace-level GitHub connections are not currently supported. Scan targets can be the entire repository or limited to specific folders or files.
Daybreak Red Team is accepting expressions of interest for early access, but registering does not guarantee access. Daybreak Defense Factory is also presented as a research preview, and the conditions for general availability have not yet been disclosed. In addition, OpenAI's official event page lists separate access requests for the product and for the model. "Daybreak Red," which is used for advanced authorized security research and testing, requires separate approval and safeguards.
From the product information published so far, Daybreak Red Team's vulnerability detection rate and false-positive rate, as well as results of any third-party comparison under identical conditions, cannot be confirmed. A unified pricing structure, a general availability date, and Japan-specific terms have also not been determined. When evaluating adoption, the first step is to clarify the scan targets and the scope that was actually verified, then confirm with evidence that the attack path is blocked in the patched code and that legitimate operations are preserved. Going forward, quantitative results demonstrating the effectiveness of this verification, along with formal availability terms, will be worth watching.