Cloudflare ties AI-found flaws to live traffic. Finding a flaw and knowing it matters are different jobs

AI has made finding vulnerabilities cheap. This week’s PHP emergency showed one consequence: frontier models found critical flaws in code that had been audited for years. The quieter consequence is the backlog. Every scanner, every coding agent and every security model now produces more findings than any team can read, and the question that decides risk is no longer “is this a bug?” but “does this bug matter here, today?”

Cloudflare’s answer, described in an OpenAI customer story on October 21, is to stop judging findings by the code alone.

Code evidence plus production evidence

Cloudflare, which proxies roughly a fifth of the web’s traffic by its own count, is offering an early-access service for vulnerability discovery and remediation built with OpenAI’s Daybreak models. The approach connects a vulnerability in source code to what is happening in production, through three questions:

• Is the affected route active? A flaw in an endpoint nobody calls is a different priority from one in the login path.
• Is it receiving suspicious traffic? Exploitation attempts in live requests turn a theoretical finding into a current incident.
• Do existing controls already protect it? A finding behind a working firewall rule is less urgent than one with nothing in front of it.

From those signals, the service gives customers evidence for prioritization, proposed edge protections, such as web application firewall rules, and proposed code fixes. In OpenAI’s words, customers “retain control over which changes to implement.” Nothing in the description has the system patching customer applications on its own.

Why exposure is the missing input

Most vulnerability programs rank findings by severity scores computed from the flaw itself. That ranking ignores the facts that decide real risk: whether the vulnerable code is deployed, reachable and under attack. Security teams fill the gap by hand, which is exactly the work that does not scale when AI multiplies the findings.

This is the same pattern we saw at Block, where security agents keep the raw evidence behind every investigation, and in GitHub’s move to measure whether developers fix findings, not how many are found. The model is useful in all three cases. What makes it trustworthy is the evidence it is forced to work from: traffic logs, firewall state, deployment records. Those are facts the model did not generate and cannot talk its way around.

It also matches the argument we have made about verification capacity being the new bottleneck. When generation is cheap, the scarce resource is deciding what deserves a person’s attention. Production evidence is a cheap verifier for that decision.

The productivity numbers, read carefully

The same story reports that every software developer at Cloudflare, about a third of the company, uses Codex, and that a team of four rebuilt a postponed product in three days with $1,100 of model tokens. Mark Anderson, Cloudflare’s President of Revenue, estimates it would otherwise have taken months and “maybe 10x more developers.”

Those are customer-reported figures for one project, and the $1,100 covers tokens, not the engineers’ time, review or testing. They are a useful signal that capable teams now ship much more code. Read alongside the security half of the story, they also explain why prioritizing by exposure has become urgent: more code, written faster, means more findings, faster.

What to copy

1. Join findings to runtime data before ranking them. Route activity, traffic signals and control coverage belong in the prioritization, not in a separate dashboard.
2. Keep two outputs separate: a mitigation and a fix. A firewall rule buys time; a code change removes the flaw. Both need approval, and they have different owners.
3. Require evidence with every proposed action, linked to the logs it came from, so the reviewer can check rather than trust.
4. Track time to decision, not just time to patch. If findings wait days for someone to judge their relevance, that is the bottleneck to fix.

OpenAI also published a policy blueprint the same day, calling this period “a defender’s window” and urging stronger incident reporting and independent evaluations. It is a proposal, not law. The operational version of the same idea is simpler: defenders win the window when their findings arrive with the evidence needed to act on them.