Collecting threat reports is easy. Deciding which indicator is relevant, current, and safe to act on is the harder job. A summarized feed should shorten that review, not replace it.
Cloudflare announced Threat Signals general availability on September 29, including a free option for every account. The free tier supports one RSS feed and retains data for up to 30 days. Enterprise tiers add capabilities such as more feeds, extended storage, and custom skills. Free does not mean unlimited collection or permanent retention.
What the workflow is intended to do
Cloudflare describes a workflow that summarizes reports, extracts indicators of compromise, attaches context and source provenance, and stores the results in an account-scoped dataset. Those are vendor-described capabilities. We have not independently measured extraction accuracy, false positives, or the protection that follows from using the results.
A concise summary can help a small team find reports worth reading. It can also omit the sentence that explains when an indicator is relevant. For that reason, I would treat each summary as an entry point to the original report, especially before changing a rule that affects real traffic.
Choose the first feed for relevance.
With one free feed, coverage is a deliberate choice. Start with a source that reports on the systems you actually operate. A broad collection of unrelated incidents can create activity without useful decisions. A narrower source may be easier to evaluate against the software, regions, and services in your environment.
For the pilot, keep a small review log. Record the original report URL, publication date, extracted indicator, why it might apply to your service, and the reviewer’s decision. Include rejected items. Otherwise, a collection that extracts many indicators can appear successful even when none leads to a justified action.
Do not confuse a feed with an enforcement policy.
Cloudflare’s June 8 changelog already described creating WAF rules from saved threat views. That integration predates this announcement. It is not a reason to assume that the free tier includes every enterprise enforcement feature, or that every extracted indicator should become a block rule.
An IP address or domain can change ownership, serve multiple customers, or appear in a report for a limited period. Before enforcement, confirm the report’s context, your exposure,e and the likely effect on legitimate users. Prefer a reversible trial with an owner who can explain why the rule exists.
Check data boundaries as well as limits.
The Threat Signals API reference is the implementation starting point for automation. Read its current schema and permissions before building an exporter. Account-scoped storage is a documented product boundary, not evidence from an independent confidentiality audit.
Our Cloudflare production AI controls guide covers the broader problem of observing and constraining AI-driven actions. The Fastly runtime-control article covers a different enforcement product; it should not be treated as an interchangeable feed reader.
How I would judge a two-week trial
Measure how long a reviewer takes to find the original evidence, how many extracted items retain useful context, and how often an item relates to your actual environment. Track unsupported or stale items alongside useful ones. These are proposed evaluation measures, not results from a test we ran.
If the workflow saves review time without encouraging unjustified rules, the free tier may be a practical place to begin. If it mostly creates summaries nobody checks, adding more feeds will not resolve the underlying problem. Keep collection, review, and enforcement as three separate decisions.
