Cloudflare’s automated response came for me

9 Sep 2026

We live in a world where algorithms are increasingly judging our actions and automatically moving against us. Often these judgements are flawed, the consequences are real for us, and we have little to no recourse.

I have been active in the intrusion detection space for over 35 years, and during those years, sponsors, program managers, and customers have regularly asked for automated response.

And automated response does make some sense. Attacks can move fast—sometimes very fast. Furthermore, few organizations have the on-site expertise available 24x7 to quickly understand an evolving threat, identify a plan to stop the attack, and implement that plan fast enough to stay ahead of it.

But the intrusion detection space has always had to contend with the false positive problem, where benign activity is incorrectly tagged as malicious. Automated response based on false positives can create its own self-denial-of-service attack.

I first heard of a self-denial-of-service attack at Aviano Air Base in Italy in the 1990s, where a high-ranking military officer had his access terminated because defenders thought his activity was an attack.

Last week, automated denial of service came for me.

Account creation denied

I went to sign up for a Cloudflare account. I entered my email address, created a password, and submitted it.

While this initial login gave me access to the Cloudflare dashboard, I also received an email from Cloudflare asking me to "Verify my email."

I clicked the button, and within seconds I received a second email saying my account had been suspended for "a possible Terms of Service violation."

The suspension came so fast that I literally had not had a chance to do anything on the Cloudflare dashboard. I had not clicked a single button or link.

The only action I had taken was clicking the "Verify your email" button in the email.

Despite having my account suspended, I could still log into the Cloudflare dashboard. I could not do anything like register a domain name, but I could find a report about my purported violation.

The only clue as to what might have gone wrong: I had supposedly committed FRAUD.

An automated response was taken on a false positive, resulting in my own automated denial of service.

My best guess: the IP address currently assigned to my home router or my email address was in some threat feed. Another possibility, my timing on clicking the "Verify your email" might have been interpreted as an automated/robot response.

I have submitted an appeal via email.

Threat feeds

Threat feeds are a modern version of signature-based detection. IP addresses, domain names, URLs, and file hashes are often used by network security intrusion detection and prevention systems to detect and optionally block activity.

At Ennetix, we subscribe to multiple threat feeds for our xVisor platform and use the data to tag entities we observe on networks.

But I am also aware of how dirty some organizations' threat feed data can be. Almost certainly, much of their data is generated by automated tools with little or no effort to verify that the content is truly malicious. Some examples:

Major DNS servers such as Google's 8.8.8.8 can end up on threat feeds.
Private, non-routable IP addresses can end up on threat feeds.
Victims of denial-of-service attacks can end up on threat feeds.

That last point is important.

Malicious placement on threat feeds

Network packets are easily forged, and the forger can insert any address into the source field of the IP header. This is how many denial-of-service attacks work: the attacker forges a packet, inserting the victim's IP address in the source field. The destination receives the forged packet, constructs a reply, and sends it back to the purported source—the victim. If the attacker does this at a high enough rate, and the replies consume enough resources to process, the victim is overwhelmed.

This is how DNS amplification DDoS attacks work.

Unfortunately for the victim, because the attacker sends out so many packets containing the victim's IP address, that IP address can end up on threat feeds.

So the victim is victimized twice: first by the initial DDoS attack, and second by ending up on threat feeds that can potentially block legitimate attempts to connect to websites long after the initial DDoS attack has ended.

In DNS DDoS attacks, getting the victim placed on a threat feed might not be the attacker's intended purpose. However, an attacker could also purposely seed these threat feeds with data associated with a victim.

Am I on a threat feed? Did I fail the human test?

Am I on a threat feed that Cloudflare uses to trigger automated responses?

Given that I had not done anything on Cloudflare's website when I was suspended for fraud, it seems unlikely that my direct actions—my behavior on their site—triggered anything.

Perhaps when I clicked the "Verify your email" button, I did it within some time window that caused an algorithm designed to detect automated responses to flag me. That is, maybe I failed the "Are you a human?" test when clicking the button in the email.

I don't know. And that is part of the problem.

How common are automated responses based on false positives?

When I posted my experience on social media, the post received an anomalously high amount of engagement for me. I also heard from others who had experienced similar issues on other platforms.

Being accused of being a robot is not only frustrating; it can be detrimental to one's ability to make a living. As these platforms increasingly become critical middlemen for reaching audiences, finding customers, and delivering content, they increasingly influence our ability to financially succeed.

Often, it is difficult to find out how to appeal one of these automated verdicts. And when you do appeal, it is often another automated system that processes the appeal.

So... a robot/algorithm accuses a human of being a robot, and then another robot hears the human's appeal and determines whether the first robot was correct.

Can we trust the models?

When I worked at FICO, I worked with people on the Falcon team who developed models used to determine whether credit card transactions were fraudulent.

They built models using large amounts of past transaction data tagged as fraud or non-fraud. Generally, the data they worked with was pretty clean because humans will often complain when they see fraudulent charges on their credit cards.

This (relatively good) ground truth made evaluating the models' performance a scientific process.

Other fields, like intrusion detection, don't have anything remotely approaching this level of ground truth, making model performance analysis more of a black art (at best) than a science.

And when uncertain models are connected directly to automated response, false positives stop being merely annoying alerts. They become actions with real consequences.

Wrapping up

Knowing how high false positive rates of intrusion detection systems can be, I have always been uncomfortable with automated response. I understand the many technical and financial reasons for tying automated response to automated detection, and increasingly, platforms like Cloudflare are deploying detection and automated response at many points across their platforms.

However, having recently been on the receiving end of an automated response based on a false positive, I am more sensitive to the problem than ever before.

Automated detection can make mistakes. The question is how much power we should give those mistakes.