A targeted exception, not the general rule
A blocklist explicitly names specific identifiers — an IP address, a device fingerprint, an account — that are denied, checked before or alongside a system's ordinary policy evaluation. This is a different mechanism from a general default-deny posture: a blocklist doesn't change what's allowed by default across the whole system, it carves out specific, targeted exceptions on top of whatever the normal rules already permit, usually in direct response to a known, already-identified bad actor rather than as the system's general access-control logic.
This makes a blocklist a reactive tool by nature: it can only deny what's already been identified as a problem, which means it says nothing whatsoever about a bad actor who hasn't been caught yet, or one using an identifier that's never appeared on the list before.
Freshness and false confidence
A blocklist is only as good as how quickly and reliably new entries actually reach it — a known bad actor whose identifier hasn't yet propagated to every enforcement point is, functionally, not yet blocked at all, regardless of how promptly the underlying decision to block them was made elsewhere. Treating a blocklist as a comprehensive defense, rather than a targeted supplement to the general policy that governs everyone else, invites exactly the false confidence that leads a team to underinvest in the general rules that actually matter for the much larger population never destined to appear on any list.