Daybreak Red Team vs Defense Factory: Access, Workflow and Scan Costs

OpenAI's Cyber at the Frontier event presents Daybreak Red Team for testing web applications and Daybreak Defense Factory for investigating findings and preparing fixes. The useful distinction is the work each tool starts with: an application to assess, or code and findings that need remediation. Neither removes engineering review.

The event's official resources now link to both products. This is a workflow comparison, not a claim that every underlying capability first appeared this week. Defense Factory already appeared in OpenAI's earlier developer guidance, and access to GPT-6 Cyber remains a separate question from access to a particular product.

Which Daybreak tool fits the job?

Daybreak Red Team is advertised as early access, with registration of interest rather than unrestricted self-service availability. OpenAI describes coordinated agents using application context and source code to test web apps, validate reported vulnerabilities and check patches. Assessment scope is controlled through isolated environments and Guardian review.

Defense Factory takes a different starting point: a repository, a scan or an existing finding. It can investigate the code and prepare a patch for a human to review. You do not need to invent a new scanning campaign just because a new security tool becomes available. If your team already has a backlog, the bottleneck may be deciding which reports apply to the code you run.

Your immediate problem	Starting point to evaluate
A web-app vulnerability needs validation	Red Team early access, with an explicitly authorized assessment scope
An existing repository needs review	A Defense Factory repository scan
New commits need ongoing checks	Defense Factory continuous monitoring
Scanner findings are waiting for investigation	Defense Factory's import workflow, where available

These are product-fit choices, not promises of access or guaranteed detection. Ask the provider to confirm availability for your workspace and intended activity before building a process around either tool.

Set up one bounded repository scan

The Defense Factory setup guide starts with a ChatGPT workspace that has Daybreak access. Install and enable Daybreak Defense Factory (Preview), open Daybreak and choose an agentic scan. Cloud scans require each person starting them to have a personal GitHub connection; workspace connections are not supported.

If a repository is missing, check which repositories the GitHub app can access rather than assuming the repository format is unsupported. Choose a full repository or specific folders and files, then confirm the recorded scope after the scan is queued.

I would start with a service that has a clear owner and a build the team understands. For example, review the code that handles customer document downloads before scanning every repository in the company. That gives the reviewer a concrete security boundary: who should be able to access which documents, and which checks enforce that rule. It also makes an incomplete result easier to recognize.

Use a one-time scan to establish that baseline. Continuous monitoring checks new commits on the default branch, while scheduled scans repeat repository reviews. Those modes answer different questions; reviewing changes does not substitute for understanding the code already deployed.

Scan billing is separate from included usage

The current FAQ says repository scans and continuous monitoring are token-billed at the plan's rates, in credits or USD. They are not covered by the plan's included usage allowance. Workspace users share the scanning credit balance; free scanning credits do not expire, and further scans become billable when those credits run out.

The documentation does not establish one universal dollar price per repository. A scan's token use and applicable plan matter, so a fixed per-repository budget quoted without those details would be misleading.

For the pilot, record the initial scope, actual scan cost and time spent reviewing useful findings. A cheap run that leaves an engineer sorting weak reports can be more expensive operationally than a narrower investigation with clear evidence. Keep that review cost visible alongside the service bill.

Imported findings can carry sharing consequences

The scanner-import documentation supports connected scanners and uploaded reports, with options depending on the workspace. Assessment needs the scanner evidence and an accessible repository commit. Review the destination as well as the finding count: some confirmations authorize publication of eligible results to a shared workspace, while private assessment options keep them private.

For example, a dependency alert may refer to a container image while the selected checkout points to a later commit. Before interpreting an assessment, establish which version was checked and whether it represents the deployed application. More imported rows do not fix a mismatch between the report and the code.

Keep the source report, assessed revision, validation evidence and proposed change together. If a reproduction cannot run, retain that uncertainty instead of converting it into either a confirmed vulnerability or a dismissal. A patch can look plausible while changing legitimate behavior, which is why an accepted fix needs both security validation and normal regression checks.

The strongest reason to adopt these tools is a shorter path from a credible report to a reviewed correction. Measure that path. A larger queue of AI-generated findings, by itself, is not progress.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help security and developer-tool teams turn complex workflows into clear technical guides and launch stories.

Book a 30-minute call.