OpenAI says Daybreak agents confirm web app flaws and draft patches; its text prints 0 numerals and no result

No numeral in about 450 words of text, and sample screenshots that print dozens

OpenAI's Daybreak Red Team and Daybreak Defense Factory pages were rendered in a browser and saved at 11:20 UTC on 13 November 2026 (the time stamps inside the two PDF files are 11:20:28 and 11:20:33). Their body text runs to about 235 and 218 words, 453 in total (derived, counting headings and buttons, not the cookie banner, menu or footer). It contains no numeral at all (derived by searching the text: the only digits on either page are in the menu's model names and the footer years). It holds 17 sentences that say what the agents do or what a user can do with them (8 on Red Team, 9 on Defense Factory; derived, and the sorting is this site's judgement), and no sentence that reports a result. No customer, price, benchmark, test score or false positive rate is printed in words.

The screenshots are another matter. Each page carries four product screenshots (eight in all, derived from the image files inside the PDFs), and they print dates, counts, durations and dollar amounts. The pages give them no caption and do not say whether they show a real run, a demonstration or a mock up; one of them labels its evidence items with the words ev-demo. This briefing reads them as what they are, vendor illustrations, and says what each does and does not show. It also corrects an easy assumption: the text is silent on how a target is authorised, but a screenshot on the Red Team page shows an approval step.

What this does not establish. Nothing here shows that either product has found a vulnerability, confirmed one, written a patch that was merged, or been used by a customer. The pages print no date and mention no event; press reports that the products were announced at an OpenAI event on 12 November were not read for this briefing, and the pages are the only source. Anything OpenAI changed after 11:20 UTC on 13 November is not included. OpenAI sells AI products and writes these pages about its own new products; an early access invitation is also marketing.

How this differs from earlier briefings. The Cairn and AntiFox briefings were about AI penetration testing platforms in attackers' hands, described by security vendors with counts. These two pages are a defender product pitch with no counts. An earlier briefing on OpenAI and bug reports recorded that OpenAI's separate Daybreak programme page printed counts of codebases, issues and patches; that page was not read for this briefing and none of its figures is carried across. One name needs care: an earlier briefing described a "Daybreak Red" access tier for GPT-6 Cyber. The pages read here call the product Daybreak Red Team, never mention that tier, and do not say how the two relate.

What the two pages say agents do, in their own verbs

Red Team is headed "AI penetration testing for web applications" and carries the label "early access". Defense Factory is headed "Turn your security backlog into fixes". The verbs are the story. Red Team agents investigate attack paths and confirm vulnerabilities; they test, validate and check. Defense Factory agents trace, investigate and develop patches, and prepare them for review. Nothing in the text says how an agent confirms a vulnerability, what it does to a target to do so, or what counts as a confirmation.

Availability is worded differently on the two pages. Red Team says "Talk to our team about early access to Daybreak Red Team." and its button reads Register interest; the page prints no eligibility rule. Defense Factory carries no early access label and offers Contact sales and Documentation buttons. The text does not say whether it is generally available, who can buy it, or what it costs.

Zoom

The loop is closed by wording, not by a described step. The Red Team page's further reading card says "Turn verified findings into fixes" and points at Defense Factory, whose text says "Bring findings from your security tools and Daybreak Red Team into the Defense Factory." The word verified is never defined. A reader might assume the retest follows the merge; on the page it is only a sentence about patches: "Test whether a patch stops the exploit." It does not say whether the patch is tested before or after engineers merge it.

Claims against evidence

Of the 17 capability sentences, 3 describe a limit on the agents or a human check (the two Red Team control sentences and the Defense Factory review sentence; derived, this site's sorting). None of the 3 says how the control works, and none is backed by a figure.

Zoom

The screenshots: where the numbers are, and what they are

Every figure below comes from a screenshot, read at full size from the images embedded in the saved PDFs. The pages do not caption them. The sums are this site's (derived) and are checked where the screenshot allows. Treat all of it as illustration: one screenshot labels evidence ev-demo-4 and ev-demo-5, and two names, Northstar Docs and an identity platform, are not customers the pages name.

Zoom

Zoom

Zoom

Two readings follow from the table. First, the product's own sample dashboard has figures that do not sum to each other without an unstated filter, which is a reason to ask what each count means before building a metric on it. Second, the only money on either page is an Estimated cost per scan in one screenshot. It does not say who pays, what is included, or how the estimate is made. The text names no price.

Scope and authorisation: silent in the text, illustrated in one screenshot

The text of the Red Team page says only that scope is enforced with isolated environments and Guardian review, and that the product will control which apps and endpoints agents can reach. It does not say who sets the scope or who may approve it. The scope approval screenshot shows what a flow could look like. The panel lists, for a staging assessment, the access (two test identities in two workspaces, using supplied test profiles), the changes allowed (synthetic test records only, removed afterwards), the exclusions (production, billing, email, external origins, destructive operations and denial of service tests), a duration of up to 8 hours and an evidence line. It ends by asking the user to approve the scope, the source uploads, test account use and evidence retention, with two buttons, Deny and Allow once. A second screenshot has the agent ask whether it may change the staging system, offering synthetic test data only or read only checks.

That is a better answer than the text gives, and it is still an answer about a sample. Not shown: who in an organisation may press Allow once, whether the product refuses to act outside the approved targets or only records them, what happens if an agent reaches an excluded system, how the approval is logged, and how a standing authorisation (the campaign file's own term) differs from Allow once. The approval line mentions source uploads, which implies that source code is sent to the service. That is this site's inference. Where it goes, how long it is kept, and whether it is used for training are not stated anywhere on either page; the only retention line is the sample's Evidence: Retain the report and redacted evidence, which concerns assessment output.

The test is the one an outside tester would face. A human penetration tester is given targets, hours, data rules and stop conditions in writing, and a client can point at the paper. A screen that says Allow once is a good start, and a reader should ask whether it produces the paper.

What confirm looks like in the one sample finding

The sample finding is titled with a flaw in a document export route: a test account could read a private document through export despite having no access to its workspace. It carries the status Confirmed after review and the severity High reviewed severity, with Review method: Target observation. The shared knowledge thread behind it shows a first agent worker asking another to verify the identity and workspace boundary before confirming, and a second worker replying that it will check the workspace identity against the recorded evidence, adding that no extra test record is needed. The finding was updated two minutes after the first post (derived).

Two things this does and does not show. It shows a design in which one agent's claim is reviewed by another before the status changes, which is a real control against a single agent reporting something false. It does not show whether the second worker repeated the request against the target or only re read the first worker's evidence; the reply says it will check against the recorded evidence, while the finding lists the method as target observation. It also shows 6 attached references on the finding and 2 on the thread, which are different objects and cannot be reconciled from the images. And nothing says how often such a review changes an outcome.

Labels that do the work of controls

Guardian appears once in the text of the two pages, in the Red Team sentence about scope. It is capitalised like a product and used like a control, and the page does not say whether it is a person, a model, a rule set or a service, or what it reviews. A name is not a mechanism.

What the pages state, and what they do not

What to do, in order

Only one item below is the vendor's: the Defense Factory page says engineers review and test proposed patches before merge. The rest are this site's suggestions, drawn from the questions the pages leave open.

Technical details

Neither page prints a command, an API call, a request format or a log line in its text. What they print is product and control names, button labels and, inside the screenshots, a campaign file excerpt and a finding record. The blocks below copy those exactly, so an operator comparing their own process has the vocabulary. The claims table above holds the product claims.

The first block lists the names and button labels as printed in the text. An operator maps each to a decision: which team registers interest, who signs the order, and who owns the review.

Daybreak Red Team early access
Daybreak Defense Factory
Register interest
Contact sales
Documentation
isolated environments and Guardian review
Engineers review and test proposed patches before merge.

The second block is the campaign file excerpt shown in the Red Team scope screenshot, transcribed by this site from the image (lines 1 to 16 are visible; line 17 is cut off). It is a sample, the target host is a reserved example name, and the font draws the block scalar marker on line 10 as a ligature, read here as a greater than sign and a hyphen. A defender reads it as the shape of a scope file to ask for: a named campaign, a target list, a maximum duration and a standing authorisation that states an objective and what may change.

# Scope excerpt
campaign:
  name: northstar-docs-staging
  targets:
    - https://staging.northstardocs.example

  max_duration: 8h

  standing_authorization:
    objective: >-
      Assess the approved staging application
      and reviewed source.

      Create and remove synthetic test records
      only. Remove temporary records after
      validation.

The third block is the scope text beside it, as shown in the same screenshot (the top line is cut off in the image). It is the closest thing either page has to a statement of who may do what to which system.

Access: Alice in Workspace A and Bob in Workspace B, using the supplied test profiles.
Changes: Create and remove synthetic test records only. Remove temporary records after validation.
Excluded: Production, billing, email, external origins, destructive operations, and denial-of-service tests.
Duration: Up to 8 hours.
Evidence: Retain the report and redacted evidence.
Approve this scope, the source uploads, test-account use, and evidence retention to start the assessment.
Deny | Allow once

The last block is the field list of the sample finding on the Defense Factory page, transcribed from the image. The two people named in the scope text are placeholder test identities in a sample screen. An operator uses the field names to see what a finding record would carry into their tracker, and which fields (Likelihood, Owner) the sample leaves open.

ID: SEC-1042
SEVERITY: Critical
CONFIDENCE: Moderate
LIKELIHOOD: Not assessed
STATUS: Triaged
OWNER: Assign owner
OBSERVED BY: Daybreak
Scan type: PR review
Reported severity: Critical
Location: src/auth/callback.ts:84
Potential fix: Restrict callback destinations to the configured trusted origin and reject redirects to other destinations.

What to hunt and harden, from these names alone: if you adopt an agent that tests your applications, ask for the equivalent of the scope file before the first run, make the exclusions explicit (production, billing, email, external origins), and check your own logs for the agent's accounts and requests afterwards.

The question the pages leave open

If an agent says it has confirmed a flaw in your application and a second agent agrees, what exactly did each of them do to your systems, who approved it, where did your source code go, and how many of those confirmations has OpenAI shown to be wrong?

Key facts