If you run Ngris in front of a real app, you already know the tedious part of a traffic policy isn't the intent, it's the syntax and the ordering. You know you want to block requests to /admin unless they carry a valid session cookie, but you have to remember which phase that check belongs in, what the match expression looks like, and how it interacts with the WAF and rate-limit rules sitting above it. This post is about how to generate firewall rules with AI using Iris, the assistant built into Ngris: you describe what you want to block in plain English, Iris drafts the exact traffic-policy config, and you review it before it ever enforces.
Iris knows two things at once: the Ngris platform and your account. It has read your endpoints, your existing policies, your plan, and your certificate state. So when you ask it for a rule, it isn't guessing at a generic template, it's drafting config for the endpoint you actually have. It shows up as a chat widget, a full page, and "Ask AI" in the docs, so you can reach it wherever you're working.
The problem: hand-writing rules and getting the phase order wrong
Ngris traffic policies have 23 rule types spread across ordered phases: WAF inspection, JWT validation, mTLS, rate limits, request and response transforms. The phases run in a fixed order, and a rule in the wrong phase either never matches or matches too late to matter. Put a rate limit ahead of your WAF and you're spending budget inspecting traffic you meant to drop. Put a JWT check after a transform that already rewrote the header it reads, and it silently fails open.
None of this is hard once you know it. But it's exactly the kind of detail you have to re-derive every time, and the failure mode is quiet: the rule saves fine, it just doesn't do what you thought. That's the gap Iris fills. You supply the intent; it supplies the phase, the match expression, and the ordering that make the intent actually hold.
Describe what to block
You write the request the way you'd describe it to a teammate. A few examples of what Iris turns into config:
- "Block any request to /admin that doesn't have a valid session cookie." Iris drafts a WAF or match rule scoped to the path prefix, keyed on the cookie's presence and validity.
- "Block traffic from a country or ASN." You name the geo or the network; Iris drafts the match condition and drops it in the phase where a hard block belongs, ahead of the expensive checks.
- "Require a JWT on this endpoint." Iris drafts a JWT-validation rule in the JWT phase, so requests without a valid token never reach your backend. If the endpoint is really an app boundary, it may also nudge you toward identity-aware SSO instead of a raw token check.
This works because Iris is create-only for rule generation: you describe a rule, you get the config. It drafts a new rule every time and never silently edits one you already have. What comes back is real traffic-policy config, the same shape Ngris runs, not pseudocode you have to translate.
You review before it enforces
Nothing Iris drafts is live until you save it. That's the whole contract: it drafts, you decide. Because rule generation is create-only, the worst case of a bad draft is a rule you looked at and discarded, never a working policy that got mutated out from under you.
The WAF makes this even safer. Ngris's WAF is Coraza-powered and attaches as a single traffic-policy rule, and it runs in detect-by-default mode before you flip it to block. So a generated WAF policy starts out observing, not enforcing. You save the draft, then watch what it would have matched in the Traffic Inspector against real traffic. Only once the matches look right do you switch it to enforce. You're never trusting a first draft against production, you're watching it first.
Under the hood
When Iris drafts a block rule, what it emits is a real traffic-policy rule placed in the correct phase, not a comment or a suggestion you have to wire up. A geo block lands as an early hard-block match. A JWT requirement lands in the JWT phase. A WAF policy lands as the Coraza rule described in the web application firewall at the edge. The point of letting Iris place it is that phase ordering is the part people get wrong by hand, and it's the part that determines whether the rule does anything at all.
Iris also watches your account without being asked. It surfaces proactive nudges in the dashboard: a certificate about to expire before it takes you down, usage burning toward a plan limit, or a posture gap like an endpoint exposed with no WAF in front of it. A nudge is a prompt, not an auto-action. It points at the fix and drafts it; applying it is still yours.
To try it, put an endpoint behind Ngris and ask Iris for a rule:
# install and start a tunnel
brew install ngris
ngris http 3000
# or bind it to your own hostname
ngris http 3000 --url app.ngris.comThen open the chat and describe the rule you want, in the same words you'd use to explain it to another engineer. Iris drafts the config, you read it, and you save it when it's right. The free plan gives you 5 endpoints and no credit card, which is enough to draft a policy, watch it in detect mode, and flip it to enforce once you trust it.