A scanner that asks what is actually running

Cloudflare announced Vulnerability Discovery and Remediation on September 3, 2026, as an invitation-only early-access service within Cloudflare Managed Defense. The service is designed for authorized defensive reviews of customer code, not open-ended investigation of systems the customer does not control. Its central idea is practical: a suspected weakness in source code becomes more useful when defenders can connect it to the application that is running, the routes receiving traffic and the protections already standing in front of it.

Conventional scanners can produce long queues. A severity label may describe how damaging a weakness could be in theory, but it does not necessarily show whether the affected code is deployed or reachable. Cloudflare says its service begins with a snapshot from Web Assets and its web application firewall, or WAF. A WAF inspects web requests and can block requests that match security rules. The service uses that operational evidence to help distinguish a dormant code path from a busy endpoint that has recently attracted suspicious traffic.

That distinction matters because engineering time is limited. Teams cannot treat every possible defect as equally urgent, and a high count of alerts can slow remediation instead of accelerating it. Production context does not prove that a vulnerability exists. Cloudflare explicitly says a finding still has to be supported by evidence in the source code. Traffic and security signals can then influence priority, helping people decide where investigation and repair effort may have the greatest immediate value.

How the investigation is bounded

For a Cloudflare Worker, the service retrieves the authorized source version and configured routes, then relates those routes to Cloudflare's asset inventory and request metadata. For applications merely proxied through Cloudflare, the same broad goal applies: connect a code-level concern with observable behavior at the network edge. The investigation is limited to the code and evidence that the customer permits Cloudflare to inspect. Cloudflare also says irrelevant material is removed and engagement-specific redaction controls are applied before context reaches the model.

The AI work is divided into specialized stages. A reconnaissance component maps request paths to the code that handles them. Hunting components examine bounded portions of the approved codebase, while validation challenges proposed findings and mitigations. This structure follows an earlier Cloudflare vulnerability-harness design that separated discovery from validation, stored state outside the model and used fresh checks to reduce false positives. The important engineering choice is the harness around the model. Persistence, access limits and independent validation are system properties, not abilities that should be assumed from a model response.

Cloudflare identifies GPT-5.6 Cyber as the model used for reconnaissance, hunting and validation in this service. Prompts travel from Cloudflare Workers through Cloudflare AI Gateway to OpenAI's servers, and responses return to Cloudflare's harness. The announcement is unusually clear that inference does not run at Cloudflare's edge. Customers evaluating the service therefore need to understand both Cloudflare's controls and the authorized transfer of investigation context to OpenAI infrastructure.

Suggestions are not deployments

The output can include a proposed source-code patch and, when the evidence supports it, a narrowly scoped custom WAF rule intended to reduce exposure while engineers review the underlying fix. Those are different interventions. A firewall rule can sometimes reduce the requests reaching vulnerable code, but it does not repair that code. A patch changes the software itself and must survive normal engineering review, testing and release controls.

Cloudflare says every tool call is logged and checked against an access policy before it runs. Proposed patches and rules must also pass checks implemented outside the model. For a suggested edge rule, Cloudflare describes syntax validation and testing against synthetic fixtures, meaning constructed examples rather than live customer traffic. Ambiguous or failed results are withheld for diagnosis. Cloudflare personnel validate the output before it is shown to the customer.

Most importantly, the model cannot apply a patch or rule on its own. The customer reviews every result and decides whether to test or deploy a change. Cloudflare also says an edge rule may be deployed when a customer has separately authorized the service to defend the relevant zone. The announcement does not fully detail the approval sequence for every engagement, so buyers should require that boundary to be written into access policies, change-management rules and rollback procedures before use.

What authorized defensive use looks like

A sensible first engagement would begin with one application, which is also the limit Cloudflare states for the start of early access. The customer would identify the repository, routes and operational data that Cloudflare may read. Security and application owners would define who can approve analysis, who receives findings and who can authorize any temporary WAF mitigation. Development teams would still reproduce the issue, review the proposed code change, run their own tests and control the production release.

This arrangement could help smaller security teams focus scarce attention. OpenAI's September 3 Daybreak announcement placed Cloudflare's offering within a network of more than 35 partner products and partner-operated services. OpenAI describes the broader program as a way to bring advanced defensive models into tools organizations already use. Cloudflare's contribution is the combination of code access, network visibility and managed human review. If it works as described, the benefit is not simply finding more possible bugs. It is shortening the path from a credible finding to a controlled response.

There are also governance questions that should be answered before source code or logs are authorized for analysis. Teams need to know which repositories and environments are in scope, what request metadata is collected, how redaction is configured, how long investigation records persist and which people can expand access. They should confirm that secrets and personal data are excluded wherever possible. These controls matter even when the purpose is defensive because source code and operational telemetry can expose architecture, business logic and user behavior.

Promising architecture, limited public evidence

The public evidence supports the existence, date and stated architecture of the early-access service. It does not establish broad effectiveness. Cloudflare has not published a product-specific benchmark showing detection rates, false-positive rates, time saved, patch acceptance or outcomes across independent customers. Its earlier internal harness report provides useful engineering detail, including the observation that repeated runs found more issues than a single pass, but internal experience is not a substitute for external evaluation of this managed product.

Availability is another constraint. Vulnerability Discovery and Remediation is not generally available, and entry is limited to selected customers through the Managed Defense team. Each engagement starts with one authorized application. That narrow rollout is appropriate for a system handling sensitive code and security data, but it means the announcement should be read as a controlled deployment stage rather than proof of mature performance at market scale.

Even with those limits, the design points in a productive direction for AI-assisted software security. Models can expand the amount of code defenders examine, but greater search capacity creates value only when findings are grounded, prioritized and routed through accountable change control. Cloudflare's proposal treats the model as one component inside that process. The next evidence to watch is operational: independently measured accuracy, customer-reported remediation time, rejected suggestions and the record of changes that reached production safely.