Cloudflare and OpenAI combine Daybreak models with real traffic data to prioritize and patch vulnerabilities

Cloudflare has announced invitation-only early access to "Vulnerability Discovery and Remediation" (VDR), a new service built into Cloudflare Managed Defense that combines OpenAI models with Cloudflare's network visibility to detect and propose fixes for vulnerabilities in the code the customer authorizes it to inspect. The system relies on the OpenAI Daybreak models, including GPT-5.6 Cyber, through what the company calls the OpenAI Daybreak Defense Network, and uses them for reconnaissance, hunting and validation of findings.

The starting problem Cloudflare describes is familiar to any security team: a scanner can flag thousands of vulnerabilities at once (the article itself gives the example of a scenario with 4,000 new findings, 78 of them critical) without indicating which ones actually matter. Language models have accelerated the ability to find weaknesses in a codebase in a matter of minutes, which drives up alert volume but does not solve the real problem: deciding what to fix first, backed by evidence, and doing it fast, because attackers are also using AI to speed up the discovery and exploitation of flaws. An isolated scanner finding does not say whether that code is deployed in production, whether anyone is actually hitting that route, what security activity surrounds it or what protections already exist.

This is where Cloudflare says it adds distinctive value: by operating a global network, it can see which routes are active, how much traffic they receive and what security events have been recorded around them. If the customer also has the Web Application Firewall (WAF) enabled, Cloudflare additionally knows which rules are already in place and blocking attacks at that moment. That layer of context turns a generic finding ("there is a vulnerability in this handler") into a concrete, actionable priority: for example, a vulnerability in code that is in production, on a high-traffic route, with recent attack activity and no existing protection. From there, the system can propose both custom WAF mitigations and code patches tailored to the customer's systems.

The article explains that this capability builds on earlier work by Cloudflare itself, described in a previous post titled "Build your own vulnerability harness", where the company detailed a model-agnostic pipeline it uses internally to scan its own infrastructure, adversarially validate each finding and turn raw model output into fixes engineers can trust. That internal detection system is one of the pillars of VDR; the new service brings that same discovery process to the code the customer authorizes it to inspect, and connects it with production traffic, security events and the edge controls capable of acting on those findings.

As for how it works technically, the process starts with a traffic and security snapshot taken from Web Assets and the WAF, showing which routes are active, how much traffic they receive and whether there are recent associated security events; these two components (Web Assets and the WAF) act as the first and second pillars of the service. Routes with high request volume are treated as "hot paths", and the code deployed on them receives stricter security profiling. Next comes vulnerability analysis on the source code. For Workers, the system retrieves the most recent version of the code and its configured routes, and cross-references that information with Web Assets and with request metadata from Workers Observability, so that the code under review is tied precisely to the endpoints it serves in production.

The harness itself kicks off with a reconnaissance agent that maps request routes to the parts of the code that handle them. That map is used to send "hunter" agents to specific sections of the customer-authorized code, where they look for vulnerabilities drawing on the network context gathered; that context helps the agents pay closer attention to code sitting behind an active or recently attacked route, but in no case does it replace the requirement that every finding be backed by evidence in the source code itself. A validation phase then reviews the proposed mitigations and assigns each vulnerability an initial risk rating based on the code; that rating can rise if network evidence shows, for instance, that the affected endpoint has heavy traffic or signs of active probing by attackers.

The end result is a prioritized list of findings, each with a recommended code patch and, where the evidence supports it, a custom WAF rule that can reduce exposure while the underlying fix is being reviewed. If the customer has authorized VDR to defend their zone, Cloudflare deploys those rules conservatively, scoped to the method, the path and other request details needed to reach the vulnerable code; indeed, the article stresses that if a route pattern contains only variables and wildcards, the system does not suggest any rule at all, preferring to miss a possible connection rather than assert one the evidence does not support. As a concrete example, the post shows a case of HTTP method override bypass, where the system maps the code finding to the production route, uses traffic and security activity to prioritize it and scopes a WAF rule around the requests that can reach the vulnerable code.

An important section of the article is devoted to explaining where the model actually runs and what safeguards are in place. When an investigation is authorized, the harness runs on Cloudflare's infrastructure, and prompts are sent from Workers, through Cloudflare AI Gateway, to the OpenAI Daybreak models hosted on OpenAI's servers; GPT-5.6 Cyber is used during reconnaissance, hunting and validation, and its responses return to the harness so the workflow can continue on Cloudflare. In other words, there is no model inference at Cloudflare's edge, and the model has no ability to apply on its own any patch or rule it proposes. Each investigation stays scoped to the code and evidence the customer authorizes, and before that context reaches the model, data the investigation does not need is stripped out and the redaction controls configured for each engagement are applied.

Another detail that matters for the security of the system itself: the harness treats source code, logs and request metadata as evidence to be inspected, never as instructions to follow, a precaution aimed squarely at mitigating prompt injection attacks via malicious content embedded in the code or traffic being analyzed. Tool access follows the same containment principle: every call is logged and checked against the investigation's access policy before it runs, and every proposed patch or rule must pass checks implemented outside the model. If any of those checks fails, the flow stops before the proposal reaches customer review. For edge defense suggestions, that means validating the rule's syntax and testing it against synthetic fixtures representing the expected requests, not against real customer traffic; if a check fails or the result is ambiguous, the output is held back and routed for diagnosis. Passing those checks does not by itself change anything in the customer's environment either: only after Cloudflare's team validates the output is the code patch and WAF rule prepared for review.

Throughout the process, Cloudflare insists that the customer stays in control: while the system can propose code patches and other mitigations, it is the customer who decides whether they are implemented. Each early access engagement starts with a single application whose code the customer authorizes for investigation, and to connect findings with production, VDR uses authorized read-only access to the Web Assets operations inventory, the relevant WAF controls and, where available, Logpush of Workers trace events. The process is described as semi-automated: the customer reviews each result before deciding whether to test or deploy it.

For now, the service is available only to selected customers during the early access phase, through Cloudflare's Managed Defense team, and those interested should contact their Cloudflare account team. The announcement fits a broader trend in the cybersecurity industry: using AI models not just to generate code or spot surface-level patterns, but to reason about entire codebases by combining evidence from multiple sources (real traffic, existing firewall rules, event telemetry) and thereby cut the noise from automated findings, prioritizing what genuinely represents risk in production, all while keeping humans ultimately responsible for deciding what gets deployed.