Cloudflare adds a field that lets rules react to failed security detections

Cloudflare has added a new field to its Rules language that lets customers write rules around security checks that report a failure. According to a changelog post dated October 9, 2026, the field, cf.appsec.request.failed_detections, can be used "to control how your rules handle requests when a security detection reports a failure."

The field is an array of text strings, each one the ID of a detection that reported a failure. Cloudflare says it covers content scanning, WAF attack score, attack signature detection and leaked credentials detection, plus AI prompt detections for personally identifiable information, prompt injection, custom topics and unsafe topics. When nothing is reported, the field returns an empty array.

What is new is the ability to act on those failures inside a rule. Cloudflare's examples show two patterns: matching any reported failure by checking that the array is not empty, and matching one specific failure, such as the leaked credentials check, by comparing against its ID. A team could, for example, send requests with a reported failure down a different handling path than requests with none. The post does not prescribe which action to take. That choice stays with the rule author.

Cloudflare states the field "does not alter the existing behavior of detections." In other words, the detections run as before, and the field only exposes their reported failures to rules.

The field works in custom rules and rate limiting rules at both zone and account level, and in Request Header Transform Rules at zone level. Cloudflare says it can be used on all plans, but a plan must still include the detections and rule features a customer wants to use. The field does not unlock detections a plan lacks.

Several points remain unconfirmed. The changelog does not say what causes a detection to report a failure, how often failures occur, or how the field behaves under load. It also offers no data on how customers will use it. This account rests on a single source, Cloudflare's own changelog. Other pages found that discuss the field, including a short repost and a how-to guide, repeat Cloudflare's documentation rather than adding independent reporting or testing, so we have not counted them as corroboration.

The change matters mainly for teams that already rely on Cloudflare's WAF and AI prompt detections. It gives them a single condition for requests where a detection reported a failure, which they can use in custom rules, rate limiting rules or zone-level header transform rules. Because Cloudflare describes the change from its own perspective, claims about its usefulness should be checked in a test zone before they are applied to production traffic.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.