Cloudflare has documented a new field, cf.appsec.request.failed_detections, that can be referenced inside rules to control how requests are handled when a security detection reports a failure. The change is described in the company's developer changelog, which is the sole source for this report.
For this field, an Array<String> holds the detection IDs. According to the changelog, the failures it reports originate from multiple sources: WAF attack score, content scanning, leaked credentials detection, attack signature detection, and AI prompt detections. Personally identifiable information, prompt injection, custom topics and unsafe topics are all covered by those AI prompt detections.
The changelog is explicit that the field does not change how detections themselves behave. Its stated purpose is narrower: it gives rule authors a way to choose how to handle requests that carry reported failures. That distinction matters for anyone maintaining a WAF configuration, because adding the field to a rule expression changes routing logic, not detection logic.
Two documented behaviours define the field's edge cases. When no failures are reported, the field returns an empty array. And the field is available on all plans, but the changelog states that a plan must still include the detections and rule features the author wants to use. In other words, access to the field is not the same as access to the underlying detections.
The changelog lists where the field can be used: custom rules at both zone and account levels, rate limiting rules at both zone and account levels, and Request Header Transform Rules at the zone level. That is a specific and bounded set of rule types rather than a blanket statement about every Cloudflare rules product.
Two example expressions are given. To match any reported failure, the changelog shows len(cf.appsec.request.failed_detections) gt 0. To match a reported leaked credentials detection failure specifically, it shows any(cf.appsec.request.failed_detections[*] eq "waf_credential_check"). These illustrate the two broad patterns the field supports: a catch-all check on array length, and a targeted check against a named detection ID.
For freelancers and small studios who manage client sites on Cloudflare, the practical value is in the targeted form. A rule that branches on a single detection ID lets an operator treat one class of failure differently from the rest, while the length check lets them treat any failure as a single condition. Which of those is appropriate depends on the site, and the changelog does not recommend one over the other.
The changelog does not state what a rule should do with a failed detection, and it does not describe default handling. It only says the field lets authors choose how to handle requests with reported failures. Any decision about blocking, logging or transforming such requests is left to the rule author and is not specified in the supplied material.
Nor does the changelog explain why a detection might report a failure, how long a failure persists, or whether failures are surfaced anywhere outside rule expressions. Those questions are unanswered in the source and should be treated as open rather than assumed.
The changelog also does not provide pricing, plan-tier specifics beyond the general statement that all plans can use the field, or a migration path for existing rules. It points readers to a separate failed detections field reference for more information, which is not included in the supplied evidence.
The event date is not established by the supplied material. The changelog URL carries a 2026-10-09 path segment, but the excerpt text does not state a publication or release date, so no event date is asserted here.
For this audience, the sensible reading is that this is a configuration-surface addition rather than a new detection capability. Developers who already write Cloudflare rule expressions gain one more field to test against; designers and other freelancers who inherit a client's Cloudflare setup may encounter it in rules written by someone else.
The honest limitation is that everything above rests on a single changelog entry. There is no independent confirmation, no field reference in the evidence, and no statement about behaviour under failure conditions beyond the empty-array case. Treat the examples as documentation samples, not as tested configurations.