Security Guide · Technical
Residential-proxy networks and autonomous AI are eroding the controls that judge traffic by where it appears to come from. Exact /32 allowlisting doesn't judge reputation at all — it checks whether a connection is the specific path you authorised. That distinction is becoming more important, not less.
They answer fundamentally different questions. Conflating them is why teams over-trust "looks-normal" traffic and under-invest in the one control residential proxies can't defeat.
"Does this address look suspicious?" — a probabilistic judgement from geo, ASN, hosting type and history. Residential proxies make that judgement unreliable.
"Is this one of the small number of paths I explicitly authorised?" — a deterministic yes/no against a fixed set. Reputation is irrelevant to the answer.
Neither control tells you who someone is. Allowlisting reduces reachability; identity and authorisation still do their own jobs behind it.
Don't trust the address. Constrain the path.
A classic model grades traffic by where it appears to originate. Routing through ordinary consumer connections collapses that model: malicious traffic arrives looking exactly like a normal home user. Add AI, and reconnaissance spreads thinly across thousands of endpoints so no single address looks aggressive.
100,000 requests total — yet no single IP looks noteworthy.
The same shift weakens a whole family of source-based controls at once:
Rules like "Australian IP → allow" or "known residential ASN → trust" are exactly what proxies defeat. Never let broad network trust stand in for identity — especially for administrative access.
The pattern is consistent: controls that classify internet traffic degrade as proxies and AI improve. Controls that constrain reachability to an exact path keep their value, because they never depended on the address looking trustworthy.
| Control | What it decides on | Under proxies + AI |
|---|---|---|
| IP reputation / blocklists | Address history & category | Weakening |
| Geo-blocking | Apparent country | Weakening |
| ASN / datacentre detection | Network operator | Weakening |
| Per-IP rate limiting | Requests per address | Weakening alone |
Exact /32 allowlisting | Is this the authorised path? | Holds |
| Cryptographic identity (mTLS, passkey) | Who the principal is | Holds |
| Multi-dimensional rate limits | Identity · account · resource | Holds |
Exact allowlisting doesn't ask "does this IP look good?" It asks "is this exactly the path I authorised?" — a far stronger statement that a residential-proxy fleet cannot answer for.
The same application behind two different network boundaries presents a completely different problem to an attacker with a proxy fleet.
/32 can reach the serviceA dedicated fixed-IP VPN in front of a private service changes the first challenge from "find a believable source address" to "compromise this exact authorised path".
User device connects over an encrypted VPN (or zero-trust access) that presents a single dedicated static IP.
user device → encrypted VPN → 203.0.113.47The WAF / firewall permits one source and drops everything else — no reputation lookup, just an exact match.
allow source == 203.0.113.47/32 · else dropReaching the door is not being trusted. Passkey / MFA establishes who; least-privilege policy establishes what.
passkey / mTLS → short-lived session → least-privilege authzThe allowlist answers "who may reach the door?" — never "who is this?"
The VPN is still a security dependency — a trust chain of device, credentials, provider and exit infrastructure. The right comparison isn't "can the VPN ever be compromised?" but "is guarding a few known paths easier than facing every internet attacker?" For non-public services, generally yes.
Reachability is the first control, not the only one. When the source address carries little evidence, the layers behind it carry the weight — each one independent of what the IP claims to be.
/32 allowlisting for anything non-public.Per-IP rate limiting still helps, but on its own it's defeated by fan-out across thousands of proxies. Move the ceiling to the identity and resource: an account can only perform so many sensitive operations per minute, however many addresses the requests arrive from.
Choose by whether the service must be publicly reachable. Both assume the source IP tells you little about who is really making the request.
For admin, internal, operational and partner-only systems — take them off the open internet entirely.
Residential proxies become irrelevant to the initial network boundary.
Where 0.0.0.0/0 is unavoidable, lean on identity, behaviour and containment rather than source reputation.
Assume malicious traffic can look completely normal at the network level.
The same idea runs through both: the network decides who can reach the door; cryptographic identity decides who they are; authorisation decides what they may do; and isolation decides how little a breach can touch.
Reputation, geo, ASN and datacentre detection all rely on the source looking trustworthy. Proxies and AI erode exactly that assumption.
An exact allowlist doesn't care how believable an address looks. It only permits the specific path you authorised.
The address is never identity. Passkeys, MFA and mTLS establish who — the network only decides who may knock.
Residential proxies don't make exact allowlisting less effective — they make the difference between reputation and allowlisting matter more. As telling good traffic from bad gets harder, reduce how much of your infrastructure has to touch the internet at all.