This guide walks you through every security setting available in Agent Builder for protecting your frontend AI assistants. Whether you use Cloudflare, Nginx, Apache, or no reverse proxy at all, you’ll find the right configuration to keep your site safe, your costs under control, and your visitors happy.
Screenshots will be added soon to illustrate each section.
How the security layers work together
Agent Builder uses a multi-layered defense strategy. Each layer catches a different kind of threat, and they work together so no single point of failure can expose your site:
| Layer | Where it runs | What it protects against |
|---|---|---|
| Edge rate limiting (Cloudflare / Nginx / Apache) | Before your server | DDoS, volumetric attacks, brute-force bots |
| Cloudflare Turnstile | In the visitor’s browser | Automated bots, headless scrapers, fake form submissions |
| Per-minute rate limiting | Agent Builder (per request) | Casual abuse, burst traffic from a single user |
| Daily limits | Agent Builder (per day) | Sustained abuse, LLM cost overruns |
| Message scanning | Agent Builder (per message) | Prompt injection, jailbreak attempts, PII leakage |
You don’t need every layer — but the more you enable, the harder it is for bad actors to abuse your public chat. At minimum, we recommend enabling message scanning + daily limits + an edge rate limit.
Agent Builder security settings
All settings below are found in Agent Builder → Settings → Security.
Message scanning
Enable Security Filter — when checked, every incoming chat message is scanned for prompt injection attempts, jailbreak phrases, and known attack patterns before it reaches your AI provider. This adds less than 1ms of overhead per message.
The scanner catches:
- Common prompt injection phrases (“ignore previous instructions”, “you are now”, etc.)
- Structured injection formats (ChatML, Llama INST tags, XML system tags)
- Code execution attempts (eval, exec, shell commands)
- Social engineering (“I am the developer”, “this is a security test”)
- PII patterns (credit cards, SSNs, API keys) — flagged but not blocked, so you can monitor for accidental data exposure
We recommend keeping this enabled at all times. There is no performance cost worth worrying about.
Per-minute rate limiting
These settings control how many chat messages a single user can send per minute.
- Authenticated users — default: 30 requests/minute. This is generous enough for normal conversation but prevents automated abuse from compromised accounts.
- Anonymous users — default: 10 requests/minute. Tighter because anonymous traffic is more easily abused. Uses the visitor’s IP address for identification.
When a user hits the per-minute limit, they see “Too many requests. Please wait a moment before trying again.” and are blocked for the remainder of that minute.
Daily limits
Daily limits apply only to anonymous (not logged-in) visitors and are your primary LLM cost protection.
- Daily limit per IP — default: 50 messages/day. Prevents a single visitor (or bot) from exhausting your AI budget. Resets at midnight server time.
- Daily limit (site-wide) — default: 500 anonymous messages/day across all visitors. This is your hard ceiling for anonymous LLM spend. When hit, anonymous visitors see “Our AI assistant is currently at capacity” and are encouraged to log in for priority access.
How to set your daily limit: estimate your typical anonymous AI cost per message (roughly $0.001–$0.01 depending on provider and model), multiply by the daily limit, and verify the resulting daily cost is within your budget. For example, 500 messages/day × $0.005/message = $2.50/day or roughly $75/month.
Anonymous access
Allow Anonymous Chat — when checked, visitors who are not logged in can use the [agentic_chat] shortcode on your frontend. When unchecked, only registered users can chat.
If you enable anonymous chat, we strongly recommend also enabling Cloudflare Turnstile (see below) to verify that your anonymous visitors are real humans.
Cloudflare Turnstile (bot verification)
Cloudflare Turnstile is a free, privacy-friendly alternative to CAPTCHA. It runs invisibly in the visitor’s browser and verifies they are a real human — no puzzles, no friction. When enabled, Agent Builder requires a valid Turnstile token before processing each chat message.
Setting up Turnstile
- Go to Cloudflare Dashboard → Turnstile
- Click Add site
- Enter your domain name and choose Managed widget mode (recommended)
- Copy the Site Key and Secret Key
- Paste them into Agent Builder → Settings → Security → Cloudflare Turnstile
- Check “Anonymous users” under “Require Turnstile For” (recommended at minimum)
- Optionally check “All users” if you also want to verify logged-in users
Once configured, a small Turnstile badge appears in the chat area. It operates silently for most visitors — only showing a challenge if Cloudflare detects suspicious behavior.
Important: You do not need to have your site proxied through Cloudflare to use Turnstile. Turnstile is a standalone product — any site can use it, even if DNS is not managed by Cloudflare.
What happens when Turnstile fails
- If the Turnstile token is missing or invalid, the visitor sees “Bot verification failed. Please reload the page and try again.”
- If the Cloudflare verification API is unreachable (network error), Agent Builder fails open — the message is allowed through to avoid blocking real users during a Cloudflare outage. The other security layers (rate limits, daily limits, message scanning) still apply.
Edge rate limiting (your web server)
The most effective DDoS protection runs at the edge — before requests reach WordPress. This stops abusive traffic from consuming your server’s CPU, memory, and your AI provider’s tokens.
Choose the section below that matches your setup.
Cloudflare WAF (recommended if you use Cloudflare)
- Log in to Cloudflare Dashboard and select your domain
- Go to Security → WAF → Rate limiting rules
- Click Create rule
- Configure the rule:
— Rule name: Agent Builder Chat API
— If incoming requests match: URI Path contains/wp-json/agentic/v1/chat
— Rate: 50 requests per 1 minute
— Counting expression: IP
— Action: Managed Challenge - Click Deploy
Why 50/min and Managed Challenge (not Block)?
Many ISPs use Carrier-Grade NAT (CGNAT), where hundreds of subscribers share a single public IP address. A tight per-IP limit (e.g. 10/min) with a hard block would lock out all legitimate users behind the same NAT.
By setting a higher threshold (50/min) and using Managed Challenge instead of Block, real users can solve a quick, invisible challenge and continue chatting, while automated attackers are stopped. Agent Builder’s own per-IP rate limits handle the fine-grained per-user throttling at the application layer.
Additional Cloudflare settings
- Under Attack Mode — Security → Settings → toggle “I’m Under Attack Mode” during an active DDoS attack. This adds a JavaScript challenge to every visitor. Only use this temporarily during an attack.
- Managed Ruleset — Security → WAF → Managed Rules → enable “Cloudflare Managed Ruleset” for protection against common attack patterns (SQL injection, XSS, etc.).
- Custom firewall rules — if you see specific abusive IPs in your Agent Builder Audit Log, block them individually via Security → WAF → Custom Rules.
A note about Bot Fight Mode and AI discoverability
Cloudflare’s Bot Fight Mode (Security → Bots) blocks all automated traffic — including beneficial AI crawlers like GPTBot (ChatGPT), ClaudeBot (Anthropic), PerplexityBot, and GoogleOther. These are the bots that read your site’s content, llms.txt, and robots.txt to surface your website in AI-powered search results and recommendations.
If you want AI tools to discover and recommend your website (for example, when users ask ChatGPT or Perplexity about your industry), do not enable Bot Fight Mode. The targeted protections above (WAF rate limiting on your chat API + Turnstile) are far more precise and won’t hurt your AI search visibility.
Only enable Bot Fight Mode if you are under active, sustained bot attack and are willing to temporarily sacrifice AI search visibility. Turn it off again once the attack subsides.
Nginx rate limiting
If you run Nginx directly (no Cloudflare), you can add rate limiting at the server level. Add this to your Nginx configuration:
# Define a rate limiting zone (10MB shared memory, 10 requests/sec per IP)
limit_req_zone $binary_remote_addr zone=agentic_chat:10m rate=10r/s;
server {
# ... your existing server block ...
# Rate limit the Agent Builder chat API
location ~ ^/wp-json/agentic/v1/chat {
limit_req zone=agentic_chat burst=20 nodelay;
limit_req_status 429;
# Pass to PHP as normal
try_files $uri $uri/ /index.php?$args;
include fastcgi_params;
fastcgi_pass unix:/run/php/php-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
}
}What this does:
rate=10r/s— allows 10 requests per second per IP address on averageburst=20— permits short bursts of up to 20 requests before throttling kicks innodelay— excess requests beyond the burst are immediately rejected with a 429 statuslimit_req_status 429— returns HTTP 429 (Too Many Requests) instead of the default 503
After editing, test and reload Nginx:
sudo nginx -t && sudo systemctl reload nginxAdjust for shared IPs: If your audience commonly uses CGNAT (mobile networks, some ISPs), increase the rate to 30r/s and burst to 50 to avoid blocking legitimate users who share an IP address.
Apache rate limiting
If you run Apache, use mod_ratelimit or mod_evasive. The simplest approach uses mod_ratelimit (available in Apache 2.4+):
# Enable mod_ratelimit (if not already enabled)
# sudo a2enmod ratelimit
# In your VirtualHost or .htaccess
<Location "/wp-json/agentic/v1/chat">
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 512
</Location>For more granular per-IP rate limiting, install mod_evasive:
# Install mod_evasive
sudo apt-get install libapache2-mod-evasive
# Create config: /etc/apache2/mods-available/evasive.conf
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 10
DOSSiteCount 100
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 60
DOSLogDir "/var/log/apache2/mod_evasive"
</IfModule>
# Enable and restart
sudo a2enmod evasive
sudo systemctl restart apache2What this does:
DOSPageCount 10— if the same page is requested more than 10 times in the interval, block that IPDOSPageInterval 1— the interval is 1 secondDOSBlockingPeriod 60— blocked IPs are blocked for 60 seconds
No reverse proxy
If you don’t run Cloudflare, Nginx, or Apache in front of your WordPress installation, Agent Builder’s built-in rate limiting and daily limits are your primary defense. In this case:
- Reduce the anonymous per-minute rate limit to 5 requests/minute
- Reduce the daily limit per IP to 25 messages/day
- Reduce the site-wide daily limit to 250 messages/day
- Enable Cloudflare Turnstile — Turnstile works independently of Cloudflare’s proxy. You don’t need to route your traffic through Cloudflare to use it.
- Set a hard spending cap at your AI provider’s dashboard (OpenAI, Anthropic, etc.)
These application-level controls won’t stop a sophisticated DDoS from consuming server resources, but they will prevent LLM cost overruns and casual abuse. If you experience sustained attacks, consider adding Cloudflare’s free proxy tier in front of your site.
Recommended settings by scenario
| Scenario | Anonymous chat | Turnstile | Per-minute limit | Daily limit | Edge rate limit |
|---|---|---|---|---|---|
| Small blog with support chat | Off (require login) | Not needed | 30 auth | N/A | Optional |
| Product page with public Q&A | On | Required (anon) | 10 anon / 30 auth | 50/IP, 500 global | Recommended |
| High-traffic SaaS marketing site | On | Required (all) | 5 anon / 20 auth | 25/IP, 250 global | Required |
| Internal team tool | Off | Not needed | 50 auth | N/A | Optional |
Monitoring and incident response
Agent Builder logs all security events — blocked messages, rate limit hits, Turnstile failures, and PII detections — to its Audit Log. Check it regularly:
- Agent Builder → Audit Log — see all assistant activity including security blocks
- Patterns to watch for: repeated rate limit hits from the same IP (potential attack), Turnstile failures in bursts (bot probing), injection attempts (someone testing your defenses)
- If you see sustained abuse from specific IPs: block them at the edge (Cloudflare custom rule, Nginx deny, or Apache Deny directive) rather than relying on application-level limits alone
Related articles
- Frontend Chat Security — what visitors can and can’t do, cost implications, privacy obligations
- Security and Privacy — Agent Builder’s overall security architecture
- GDPR and Data Protection — data handling, retention, and compliance
- Performance and Scaling — caching, token optimization, and high-traffic considerations