Manually Blocking an Address
Adding an address by hand blocks it until somebody removes it. It is the right response to a specific, identified source and the wrong response to most other things.
Where to find it
Architect Panel → Security:
- Blocked IP Addresses — where manual blocks are added
- Blocked User Accounts — the account-level equivalent
Architect Panel → Activity:
- Activity Log — evidence for the decision
When it is the right tool
- A single source generating sustained abuse that the automatic rule is not catching.
- An address you have positively identified during an incident.
- A known-bad source you have been told about by somebody credible.
When it is not
A distributed attack is the important case. Blocking addresses one at a time against a botnet is a losing race — you will add entries faster than you can think, and the attack will not notice. That needs handling upstream at your firewall or CDN, which can act on patterns rather than individual addresses.
It is also the wrong tool for a specific user's behaviour. If one person is doing something they should not, deal with their account; blocking their address affects everybody who shares it and does nothing when they move.
Verify the address first
Take it from the platform's own records — the error log, the activity log, the API log — rather than from a report or a screenshot. Addresses are easy to misread and the consequence of blocking the wrong one is locking out someone legitimate with no obvious explanation.
Check what else is behind it
Before blocking, look at whether that address has successful sign-ins from real users. A shared office connection, a mobile carrier gateway or a corporate VPN can carry an attacker and a hundred legitimate users at once, and blocking it stops both.
Manual blocks are permanent by default
Nothing removes them. That is why the list needs a review habit — treat every manual block as temporary in intent, note when you added it and why, and revisit.
Prefer the narrowest action
If the problem is one account, block the account. If it is one address, block the address. If it is a network, that is a firewall matter. Reaching for the broadest available action because it is the easiest to apply is how organisations end up unable to explain their own block lists.
Worked example
During an incident, the API log shows one address making thousands of malformed requests with a revoked credential. It has no successful sign-ins from anybody. It is blocked manually, the ticket records the address, the evidence and the date, and a calendar reminder is set to review it in a month. When the review comes round, the traffic has long stopped and the block is removed.
Recommendations
- Take the address from platform logs, never from a report.
- Check for legitimate users behind it before blocking.
- Handle distributed attacks upstream.
- Record the reason and a review date every time.