Vercel shipped natural-language WAF custom-rule generation on 2026-05-12, letting a single sentence expand into a complete custom rule covering match conditions, rate-limit fields, and a persistent block duration. The feature lowers the cost of writing match logic but relocates the work: the model silently fills any field your prompt omits, so an over-broad rule blocks real users while an under-specified one fails open. The part worth getting right is not the prompt. It is what the model emits, how that config is staged, and where a human still has to sign off.
What does vercel firewall rules add --ai actually emit?
The flag turns a prompt like Rate limit /api to 100 requests per minute by IP into a complete custom rule: a match condition, an action, and the full set of rate-limit parameters the prompt never mentioned.
The actions available are deny, challenge, log, bypass, rate_limit, and redirect, with persistent time-based blocks that default to 1 minute. A rate-limit rule carries parameters the prompt never names: a time window, a request ceiling, a key the limit counts against, and the follow-up action taken when the limit is exceeded. None of those appear in the prompt above. According to the CLI firewall docs, the model fills whatever you leave out.
The implicit mapping is inferable from the prompt itself. The changelog’s example prompt, Rate limit /api to 100 requests per minute by IP, implies a one-minute window, a per-minute request ceiling, and an IP key, all derived rather than stated. The two examples in that changelog differ on purpose: one caps API traffic at 50 requests per minute per IP and blocks an offending IP for 5 minutes, while the other limits to 100 per minute with no persistent block. The contrast confirms that a time-based block is optional, and because it is optional, it is the field most likely to arrive without the reviewer noticing.
How does the staging and publish gate work, and what bypasses it?
Custom rule and IP block changes land as drafts and do not affect production traffic until you run publish; you inspect them with diff and throw them away with discard. This is the gate the --ai workflow hands you for free, and it is the one place a human can read generated config before it touches a request.
The gate has a hole. System bypass, attack challenge mode, and system mitigations apply immediately, with no publish step. A reviewer who treats every firewall action as draft-staged will miss toggles that take effect the moment they are set.
The dashboard path has a different shape. After Generate Rule, the user edits the generated name, conditions, and action, then saves and publishes. Per the custom-rules docs, configuration takes effect immediately on apply with no re-deploy, so the gap between “saved” and “live” in the console is effectively zero. Roles gate the flow end to end: Developer or Viewer can read rules, while Project administrator, Team member, and Security roles can configure, save, and apply them. That makes the role assignment the real checkpoint in the dashboard path, because the publish confirmation is the last chance to stop a bad rule before it serves traffic.
Why can’t --ai run in CI/CD?
The --ai and interactive-wizard modes require a terminal (TTY). In scripts and CI you must fall back to --condition flags or a --json payload, which blocks headless automation of AI generation entirely.
That constraint is by design, not an oversight. Natural-language generation is a human-in-the-loop authoring shortcut; the deterministic --condition and --json paths are the automation surface. The four modes are mutually exclusive in practice: AI and interactive want a person at a keyboard, while flags and JSON want a pipeline. A team that wants AI-authored rules committed to infrastructure-as-code has to run --ai locally, read the generated rule, then commit the resulting JSON rather than re-running the prompt on every deploy. The AI step produces an artifact; the artifact is what belongs in version control.
What should you audit before publishing an AI-generated rule?
Four things, in order: the implicit rate-limit defaults the model filled in, whether a persistent time-based action snuck in, whether the rule ships in Log mode first, and that the operator holds a role permitted to apply it.
Implicit defaults. The rate-limit parameters the model filled in are the core audit target. The prompt names the target and the rate; the model fills the rest. Per the custom-rules docs, a rate-limiting rule takes a follow-up action that logs, denies, challenges, or returns a 429 response, and the prompt almost never says which. A rule that only logs on exceed silently fails open where a deny would have enforced. Read every field before publish.
Persistent actions. A time-based block persists the offending client IP for a configurable window that defaults to 1 minute and, per the custom-rules docs, applies before the firewall processes the request, so blocked requests do not count toward CDN or traffic usage. That is efficient when correct and brutal when wrong, because the duration is hard to reverse mid-incident. Confirm whether the model added one, and what duration it chose.
Log-first testing. Ship a new rule in log action first, observe a period of live traffic, then switch to challenge, deny, bypass, or rate_limit. The instinct transfers from community writing on AI-powered WAFs: the same source notes that aggressive rules flag legitimate names like O'Brien as SQL injection, the classic false-positive problem that tuning and whitelisting chase but never fully solve. Natural-language authoring does not add a detection model, but it inherits the same review instinct: measure before you enforce, and let the log data tell you whether the match condition is as narrow as you assumed.
Role gating. A Developer or Viewer can read generated rules but cannot save or apply them. Only Project administrator, Team member, and Security roles can push a staged rule live. Confirm the operator’s role before relying on the publish step as a human checkpoint.
Is this the same as Cloudflare’s AI security features?
No. Vercel’s feature authors rules; Cloudflare’s AI Security for Apps, formerly Firewall for AI, scans LLM prompts for prompt injection, PII, and unsafe topics, and is model-agnostic. One is an authoring shortcut that lowers the cost of writing match conditions; the other is a detection category that inspects the content of model traffic.
Conflating the two misreads both. AI-authored rules still run deterministic match logic once the model has finished translating the prompt; the model’s involvement ends at generation, not at request evaluation. AI-based threat detection runs on every request and carries the latency, false-positive, and drift costs that AI-authored rules do not. For a team auditing what --ai produced, the relevant question is whether the generated config is correct, not whether the firewall evaluates requests with a model.
The evergreen takeaway is narrower than the launch framing suggests. The 2026-05-12 changelog, the exact flags, and the TTY constraint will drift as Vercel evolves the firewall command. The review discipline will not: audit implicit model-filled defaults, ship new rules in Log mode first, stage before publish, and keep rule authoring distinct from threat detection.
Frequently Asked Questions
Can AI-generated firewall rules be committed to vercel.json?
Partially. vercel.json routes support only the challenge and deny actions, so any rule the model generates with log, bypass, or redirect will not round-trip through version control and must be applied through the CLI publish step or dashboard instead.
Which rate-limit parameters does the model fill from fixed ranges?
The model picks from concrete option sets: a window between 10 and 3600 seconds, a request ceiling from 1 to 10 million, a key of IP, JA4 fingerprint, or a named header, and an algorithm of fixed_window or token_bucket. The prompt almost never names the algorithm or the key, which makes those two the fields most likely to ship as silent defaults.
Can natural language edit an existing rule, or only create new ones?
Both. The rules edit subcommand also accepts the —ai flag, so a prompt like ‘lower the rate limit to 50’ mutates a live rule’s fields. The same silent-default risk applies to edits as to fresh creation: an NL edit can swap in a new window, key, or duration without the operator reading the diff before publish.
What persistent block durations can the model assign?
Time-based actions use a fixed ladder of 1, 5, 15, 30, or 60 minutes, with 1 minute as the default. A prompt that says ‘block repeat offenders’ leaves the model free to pick any rung, and because the duration applies before the firewall processes the request, the chosen window is hard to reverse mid-incident.
If no model runs at request time, why keep a Log-first window?
Vercel’s documented guidance specifies a 10-minute observation period in Log action before promoting a rule to challenge or deny. The match condition the model generated can still misfire against real traffic, and although evaluation is deterministic, AI-authored rules inherit the same shadow-mode rollout discipline ML WAFs use, without the 50 to 100 millisecond per-request latency that model-based detection adds.
