Cloudflare Introduces Continuous Trust Bands for Verified Bots, Starting With Internal Use
Cloudflare announced a continuous evaluation system, already in internal use, that measures Verified bots on robots.txt compliance and HTTP 429 response, producing explainable trust bands instead of permanent scores. Public Radar reporting and customer-selected trust thresholds are planned; no release date was stated.
Cloudflare has announced a continuous evaluation system for Verified bots that it is already using internally to measure whether they keep honoring site preferences over time, not just at signup. The system assesses consistency with robots.txt (RFC 9309) and whether traffic slows after HTTP 429 “Too Many Requests” responses, producing explainable trust bands rather than permanent scores. Public reporting of those bands on Cloudflare Radar, and customer controls to set the trust threshold that decides how Verified bot traffic is handled, are planned; the announcement states no release date for either.
The announcement, published October 16 on the Cloudflare Blog by Chris Tsoukaladelis, appeared as the lead story among a busy week of launches that included a programmable secure web gateway, the Void deployment SDK, and a joint discovery pilot with OpenAI. The timing underscores how seriously Cloudflare is treating the accountability problem as AI agents proliferate across the web.
Cloudflare’s Verified bot program requires operators to identify themselves accurately, do only what they say they will do, and avoid abusive behavior. The company previously addressed identity through Web Bot Auth, which lets bots sign requests to establish who they are, and BotBase, which catalogues verified identities in an open format. The new system tackles the behavioral side: it watches whether a verified bot keeps its promises once it starts crawling.
The system draws a careful distinction between risk and trust. Risk describes the likelihood that a particular request or point-in-time action may be harmful, and it can change from moment to moment. Trust is built over time through repeated, consistent behavior. The evaluation system measures that consistency across two initial signals.
The first signal is robots.txt compliance. A site’s robots.txt file communicates which paths crawlers should and should not access, as specified in RFC 9309. Cloudflare’s system checks whether a bot’s observed traffic patterns align with those published preferences over time. Isolated violations may not be significant; what the system looks for are repeated patterns of disregard. “And just to be clear,” the announcement notes, “a robots.txt sets the minimum rules for what bots and agents should not do. But there is no implication that anything not stated is allowed.”
The second signal is response to HTTP 429 status codes. When a website returns 429 (“Too Many Requests”), it is telling the visitor to reduce its request rate, sometimes with guidance about how long to wait before trying again. The system checks whether the bot slows down, pauses, or continues at the same pace after receiving that signal. Consistently adapting increases trust; repeatedly ignoring the directive lowers it.
These observations translate into what Cloudflare calls an “explainable trust band” — a range showing how consistently a bot respects site preferences and which observed behaviors informed that assessment. The bands are not permanent judgments about a bot or its operator. A bot that cleans up its configuration or starts honoring rate-limit responses can improve its standing. The announcement specifies sustained patterns rather than isolated events and publishes no evaluation cadence or maximum window.
Cloudflare is already using the system internally to evaluate Verified bots and build a history of behavioral patterns. The captured Cloudflare Status page shows an active WARP geolocation incident and a list of recently resolved incidents; no entry for the Verified bot evaluation system appears on that captured page, and a single snapshot cannot establish the absence of related incidents across any period. Its contents do not establish whether that system is operational. Cloudflare’s statement that it is using the evaluator internally comes from the announcement itself. The company plans to publish the trust bands publicly on Cloudflare Radar and to expand the ways it measures bot behavior, and says all Cloudflare customers will eventually be able to choose the trust threshold used to decide how Verified bot traffic is handled at their sites; no date was given for either step.
The system joins two existing Cloudflare products to form what the company calls “an accountability loop for automated traffic.” Bot Preference Sync helps website owners publish their crawling preferences, and Bot Management lets them decide how automated traffic is handled. The continuous evaluation layer sits between them, observing whether Verified bots consistently honor published preferences so that trust is earned through sustained behavior rather than assumed from identity alone.
This matters for the rapidly expanding population of AI agents crawling the web. Coding agents, shopping agents, and research bots increasingly traverse Cloudflare-protected sites. For now, repeatedly ignoring site preferences can lower an internally assessed trust band, while customer-selected thresholds for traffic handling remain planned. Bot operators who want public, comparable proof of good behavior must wait for Radar publication, which Cloudflare describes only as a future step.
The announcement follows Cloudflare’s recent collaboration with OpenAI on a joint discovery pilot for the agentic web, and arrives as the broader industry grapples with how to make automated access both useful and respectful of site operator preferences. By pairing persistent identity with continuous behavioral evidence, Cloudflare is betting that accountability — not just authentication — is what makes the agentic web sustainable.