Firewall rules for model extraction attempts
AI models exposed over APIs get probed. A lot. Sometimes that is just noisy curiosity. Sometimes it is patterned traffic meant to map out model behaviour and pull it apart. The useful bit is not pretending a firewall solves the lot. It does not. It does cut down the attack surface and buys time.
Start with deny-by-default
Keep inbound access to model endpoints closed unless you have a reason to open it. Allow known IP ranges, service accounts or authenticated API gateways only. Put model-serving hosts behind a reverse proxy or API gateway that handles authentication, TLS termination and request validation. Keep egress tight too, so a model host is not a handy pivot into the rest of the network.
Run the model-serving nodes in their own subnet. No direct admin access from the internet. Put management ports behind a bastion host or jump box. Firewall rules help here, but they are not a replacement for application checks such as quotas, input sanitation or output controls.
Rate limiting is where the obvious abuse gets caught
Extraction attempts usually look boring before they look clever. They are high-volume, repetitive and easy to spot if you are looking for them. Apply limits in more than one place: at the edge, at the API gateway and per account. Use short windows for burst protection and longer ones for sustained use.
Examples:
- Nginx: define a zone and limit requests per second per client IP.
limit_req_zone $binary_remote_addr zone=rl:10m rate=5r/s;
limit_req zone=rl burst=20 nodelay;- Cloud WAF: add a rate-based rule that blocks an IP after X requests in Y minutes.
- Per-account quota: throttle by API key or bearer token rather than only by IP.
Do not guess at the numbers and hope for the best. Start tight on new models, watch the traffic, then tune. Leave room for legitimate spikes with burst allowances and staged penalties, like delays before you block outright.
Watch for the odd patterns, not just the volume
Log every request with the bits that help later: source IP, API key, timestamp, request length, token count, prompt hash, response size and latency. The patterns that matter are usually simple:
- request rate per identity and per IP
- same or near-same prompts repeated
- odd prompt and response patterns
- many low-rate IPs hitting the same API key
Feed that into a SIEM or a stream-processing pipeline. Start with simple rules. Add statistical detection once you know what normal looks like. A decent rule is one that flags an account when the same prompt shows up N times across M distinct IPs inside T minutes. Keep the first pass conservative or you will drown in false positives.
Control the output as well
One easy way to reduce the value of probing is to make the responses less useful to an attacker. Remove chain-of-thought style reasoning from responses. Strip out verbose internal explanations. For suspicious patterns, return canned or high-level responses. Put caps on response size and token count per request.
Use content filters to block anything that leaks model internals. On higher-risk endpoints, return numeric summaries or structured data instead of free text. Sanitize or redact sensitive fields before the response leaves the service.
Keep the logs usable later
Logs need to survive the incident, not just the day. Forward request and response logs to write-once storage or an append-only logging service. Keep the authentication metadata and IP attribution with them. Have a retention policy and legal hold process that actually works when needed.
Keep suspicious requests and matching responses separate as evidence. Timestamp and hash them on ingest. Store chain-of-custody metadata with the lot. That gives you something solid for takedown requests, abuse reports or anything uglier that follows.
Alerts should be boring and specific
Set alerts for high-confidence patterns, not every wobble in traffic:
- one API key issuing more than 1,000 requests in 10 minutes
- the same prompt repeated across 10 distinct IPs within 30 minutes
- a sudden jump in average response length or in failed authentication attempts
Send those alerts to a central incident platform. Keep the triage steps simple: block the API key, add the IP stems to a temporary blocklist, capture the full request and response pair. Put the thresholds and playbooks under version control so changes do not vanish into memory.
Review the rules like code
Store firewall rules in a repository. Test changes in staging against traffic that looks like production. Run checks that catch unintended open ports or widened CIDR ranges before the change goes live.
Review the rules after model updates, after third-party integration changes and after any incident. Rotate default allowlists. Re-check long-standing exceptions. They have a habit of outliving the reason they were added.
Test the controls
Include model extraction attempts in security testing. Run targeted red-team exercises that try to reconstruct model behaviour using high-volume, patterned prompts. Check how far the firewall rules, rate limits and response filters get before the attempts fall apart.
Measure false positives and tune the detection logic. Review the logs and alert timeline to see whether the response would preserve evidence and stop the attack before it gets anywhere useful.
People still matter
Give staff short, role-specific briefings. Show them what model extraction looks like in logs. Give them examples of suspicious traffic and the first thing to do when an alert fires. Make it clear who can apply emergency firewall changes or revoke credentials.
Train operators to avoid sloppy test setups. Do not expose private model endpoints for convenience. Use short-lived credentials for experiments and require approval for exceptions.
Threat intelligence is useful, but only if it is handled properly
Feed anonymised indicators from trusted intelligence sources into firewall rules and WAF policies. Correlate internal alerts with external reports to spot organised activity earlier.
Keep the evidence trail intact if an external takedown is needed. Good logs and clear attribution save time when legal action or account suspension is on the table.
Start with deny-by-default rules, put the model behind an authenticated gateway and add rate limiting, response filtering and logging. Keep detection rules under version control. Segment the hosts. Preserve suspicious queries. That is enough to make extraction harder and to give you something useful when the probing starts.
