---
title: "When the Bot Filter Blocked the Office's Own IP Address"
canonical: https://dxdev.com/everyday-ai/the-filter-that-couldnt-tell-us-from-an-attacker/
datePublished: 2026-06-15
---
Late one morning, the office lost access to its own admin panel. A customer hadn't done it, and neither had someone else's system going down out of our reach. We did it to ourselves, and we were locked out of the very tool we needed to fix the thing that had locked us out.

The cause was an internal tool running entirely inside the building. It was doing routine page checks against our own sites, and it moved fast enough to cross about fifteen hundred requests in a day from one address. That address was the office's own. The automated filter that watches for scrapers and credential-stuffing attempts (bots guessing passwords in bulk) saw exactly the pattern it was built to catch, high volume from a single source, and blocked the address.

Fifteen hundred fast requests a day from one address is a reasonable signal for "this might be a bot." The rule fired correctly, on correct logic, against the wrong target. It could only measure one thing: how much traffic came from where. It had no second question to ask, such as "do we already know and trust this address," that could separate a legitimate internal tool from an attacker running the identical pattern.

## Finding the answer took longer than it should have

There was an unrelated migration happening around the same time, so that had to be ruled out first as a possible cause. The answer was sitting in a database, not a log file. To get to it, we queried the filter's own ban records directly and confirmed that the trigger reason and the timing lined up with the internal tool's activity.

Once that was confirmed, the fix was to add the office's address to an allowlist (a list of addresses the filter must never block) inside that same database. We did not slow the internal tool down. The tool was doing legitimate work, and throttling it would have punished the wrong side of the problem.

## The same trap is still open

What stuck with us afterward is that the exact same trap remained open for the next piece of internal tooling. Any future tool that ramps up its own traffic against the company's sites, for a perfectly good reason, will trip the identical rule, because the rule still only knows volume. Fixing this one lockout taught the filter nothing about what else it should already trust.

If your systems have an automated block or throttle, find out what single number that rule watches: request rate, failed logins, error count, whatever it is. Then check whether anything you already run internally, a monitoring tool, a QA script, a bulk job, could cross that same number on a normal day. If the rule has no way to tell your own infrastructure from a stranger doing the same thing, it is waiting for the day your own tools trip it.