You describe a limit in a sentence, and Iris drafts the config. That is the pitch for how you generate rate limit rules with ai in Ngris: you tell Iris what you want to protect and how hard to clamp down, and it drafts the exact rate-limit rule the platform runs. Rate limiting is one of those tasks where the concept is trivial ("don't let anyone hammer my login endpoint") but the config is fiddly — you have to decide the key, the window, the ceiling, and where in the traffic policy it sits. Iris is good at turning the sentence into the config. You stay good at deciding whether the config is right.
Why rate limiting is fiddlier than it looks
The hard part of a rate limit is not the number, it is the shape. Three decisions come up every time:
- Per-IP vs per-key. Limiting by client IP protects a public endpoint from a single noisy source, but it punishes users behind a shared NAT and does nothing against a botnet. Limiting by API key or authenticated identity is fairer and more precise, but only works once you have a key to bucket on. The right choice depends on the endpoint, not on a default.
- Burst vs sustained. "100 requests per minute" and "allow a short burst but cap the sustained rate" are different rules. A login form wants a low, strict ceiling. A read API wants headroom for a legitimate burst without letting a client sit at the ceiling forever.
- Which endpoints. A blanket limit across every route is easy to write and usually wrong — it either throttles your busiest healthy traffic or leaves the endpoint that actually gets abused wide open. Limits belong on specific paths.
None of this is hard to reason about. It is just tedious to encode by hand, especially because a rate limit is one rule inside a larger ordered traffic policy — Ngris has 23 rule types across phases (WAF, JWT, mTLS, rate limits, transforms), and getting the ordering right is the part people get wrong. Iris handles the placement so a generated limit lands in the right phase.
Say the limit out loud
The interface is a chat box. You say the limit the way you would explain it to a teammate, and Iris drafts the rule. Some things people actually type:
- "Rate limit login to 10 attempts per minute per IP." Iris drafts a per-IP limit keyed on client address, scoped to the login path, with a one-minute window and a ceiling of 10.
- "100 requests per minute per API key on everything under /v1." This one buckets on the API key rather than the IP, so a single key cannot exhaust the budget for everyone, and scopes the match to the
/v1prefix. - "Protect my signup endpoint from abuse." Vaguer on purpose — Iris drafts a conservative per-IP limit on the signup path and tells you the numbers it chose so you can tighten or loosen them. It knows your account, so it can scope the rule to the endpoint you actually have.
Because Iris knows the platform and your account — your endpoints, your existing policies, your plan — it can point a generated rule at a real path instead of a placeholder. Describe a rule, get the config: the same flow drafts firewall rules, WAF policies, transforms, and custom error pages, not just rate limits.
Attached per endpoint, reviewed by you
Rule generation is create-only. Iris drafts a new rate-limit rule; it never silently edits or removes one you already have. The draft shows up attached to the endpoint you named, and nothing is enforced until you read it and save it. That is deliberate — a rate limit that is wrong in the wrong direction either lets an attack through or throttles your own users, and neither is something you want an assistant to ship on your behalf.
So the loop is: describe, review the drafted config, adjust the window or ceiling if the numbers are off, then save. Iris also raises this proactively — if it notices an endpoint exposed without protection, it will nudge you in the dashboard. The nudge is a prompt, not an auto-action; the fix is still yours to apply.
Pairs with the WAF and auth for a full policy
A rate limit is one layer. On its own it slows abuse down; it does not inspect what the request is trying to do, and it does not decide who is allowed in. That is why a rate-limit rule usually sits next to two other rules in the same traffic policy:
- The Coraza-powered WAF, attached as one traffic-policy rule, inspecting request content for injection and other attack patterns. It runs detect-by-default, so you can watch a generated policy in the Traffic Inspector before you flip it to blocking.
- Identity-aware access — JWT or mTLS or SSO/OIDC — deciding whether a request is even from someone allowed to be there before you bother counting their requests.
Iris can draft all three, and because it places each rule in the correct phase, the WAF check, the identity gate, and the rate limit end up ordered the way they should run. You review the whole policy, then save it.
If you want to try it, spin up an endpoint and ask. Install the CLI and start a tunnel:
# install and expose a local service
brew install ngris
ngris http 3000
# or claim a fixed hostname for it
ngris http 3000 --url app.ngris.comThen open the chat widget and describe the limit you want. The free plan gives you 5 endpoints with no credit card, which is enough to draft a policy, watch it in detect mode, and see whether the numbers Iris picked match your traffic before you enforce them.