How to Secure a Public AI Chat Without Ruining the User Experience
A lot of developers love building public tools.
An AI chat.
A small utility.
Something anyone can try without signing up.
Sounds perfect… until abuse starts.
One user sends 100 messages.
Another opens incognito.
Another uses a VPN.
Someone keeps refreshing like it’s a game.
And suddenly your server bill starts screaming.
So how do you allow guest users, but still control usage?
Let’s talk about how this is actually done in real systems.
The real problem is not messages
It’s identity
When a user is logged in, life is easy.
You have a user ID.
But with guests, there is no account, no email, no login.
So the question becomes:
“Who am I counting requests against?”
The answer is:
You don’t rely on one thing.
You build a temporary identity.
The correct approach: layers, not one trick
One of the biggest mistakes is relying on a single method.
-
IP only ❌
-
Cookies only ❌
-
Fingerprinting only ❌
Each one can be bypassed.
But when you combine them, abuse becomes difficult and annoying.
That’s the goal.
You don’t need perfection.
You need friction.
1. Guest ID (your main key)
On the first visit:
-
Generate a UUID
-
Store it in a signed cookie
-
Send it with every request
Example:
Pros:
-
Simple
-
Fast
-
Works for most users
Cons:
-
Incognito clears it
-
Clearing cookies resets it
That’s fine. This is only layer one.
2. IP address as a backup
Every request still has an IP.
So you also track limits per IP.
This helps when:
-
The cookie disappears
-
Someone keeps refreshing
-
Multiple guest IDs come from one source
VPNs can rotate IPs, yes, but many abusers don’t even bother.
This alone already blocks a big percentage of abuse.
3. Lightweight device fingerprint
Not heavy tracking.
Not invasive.
Just a soft fingerprint like:
-
User agent
-
Timezone
-
Language
-
Screen size
Hash them and treat the result as a signal, not a truth.
It won’t stop everyone, but combined with cookie and IP, it adds another lock on the door.
The golden rule
No single method is enough.
But together:
-
Cookie
-
IP
-
Fingerprint
You get a reasonably stable guest identity.
Enough to protect your system without hurting real users.
Implementing: 10 messages every 5 hours
The logic is straightforward.
For each guest:
-
Count sent messages
-
Store the time window start
-
Allow only 10 messages
-
Reset automatically after 5 hours
Example state:
At 19:00:
→ counter resets.
Where should this live?
Redis
Redis is perfect for this.
Why?
-
Extremely fast
-
Built-in TTL
-
Designed exactly for rate limiting
Example key:
When the value reaches 10:
→ block further messages until TTL expires.
Clean, simple, reliable.
User experience matters
Never show errors like:
Access denied.
Instead say:
You’ve reached your free limit. Try again in a few hours.
Tone matters.
You’re limiting usage, not punishing the user.
Can you block incognito or VPN completely?
Short answer: no.
Anyone claiming otherwise is lying.
What you can do:
-
Detect known VPN IP ranges
-
Apply stricter limits to them
-
Reduce message count
-
Or require login after a threshold
For example:
-
Guest: 10 messages
-
After that: login required
This is exactly how large platforms handle it.
The professional model
-
Anonymous guest
→ limited usage -
Interested user
→ signs in -
Abusers
→ get bored and leave
You don’t fight them directly.
You outlast them.
Final thoughts
If you launch a public AI chat without protection, you’re basically saying:
“Unlimited access. Please don’t abuse it.”
And unfortunately, someone always will.
The solution is not closing the door.
It’s building a fair, intelligent system.
One that:
-
protects your infrastructure
-
respects real users
-
and keeps your costs under control
That’s how production systems actually work.