Iris is the fastest way to build a rule when you can describe the behavior but not the syntax. When you generate traffic policy with ai, you hand Iris a plain-English description of what the edge should do — block a bot fingerprint, cache a JSON endpoint, validate a JWT before the request ever reaches your origin — and it drafts a real, ready-to-review traffic-policy rule of the correct type, in the correct phase, with the correct matchers. Iris runs inside the gateway, so it knows every rule type the platform supports and how they compose. It writes the draft; you read it, edit anything, and click to save. Nothing goes live until you approve it.
This matters because a traffic policy is the single most expressive thing you configure at the Ngris edge, and it is also the easiest to get subtly wrong. A firewall rule allows or denies. A traffic policy inspects, transforms, authenticates, caches, and rewrites — across an ordered pipeline where the wrong phase means your rule runs too late to matter. Iris exists to collapse the gap between "I know what I want" and "I know the exact CEL expression, the exact phase, and the exact matcher syntax to express it."
A traffic policy is more than a firewall
If you only need to allow or deny by IP, ASN, path, or method, a firewall rule is the right tool — and Iris has a dedicated firewall generator for that. A traffic policy is a different surface. It's roughly twenty rule types spread across ordered phases: request-side rules that run before your origin sees anything, and response-side rules that run on the way back out.
The rule types Iris can draft include, among others:
- Coraza WAF rules (OWASP Core Rule Set, custom SecLang directives)
- JA3/JA4 TLS-fingerprint bot management
- CORS policies (allowed origins, methods, headers, preflight handling)
- JWT, API-key, and webhook-signature validation
- Response and edge caching with key and TTL control
- CEL
set-varexpressions, header add/remove, and URL rewrites - Circuit breakers and routing rules
Each of those lives at a specific point in the pipeline. A WAF rule that runs after a rewrite inspects the wrong URL. A cache lookup placed after auth validation pays the auth cost on every cache hit. The phase is not a detail — it is the rule.
Describe the behavior, Iris drafts the rule
You talk to Iris in the chat widget or the full-page chat the same way you'd describe the change to a teammate. A few concrete examples of what it drafts:
"Add a Coraza WAF rule that blocks SQL-injection attempts on /api but only logs everything else." Iris drafts a SecLang rule that runs the Core Rule Set in detection mode globally and switches to blocking on the /api path prefix:
# Coraza WAF — detect everywhere, block SQLi on /api
SecRuleEngine DetectionOnly
SecRule REQUEST_URI "@beginsWith /api" \
"id:1001,phase:1,pass,nolog,ctl:ruleEngine=On"
SecDefaultAction "phase:2,deny,status:403,log""Block clients whose JA3 hash matches these three scraping tools." Iris drafts a bot-management rule that matches on the TLS fingerprint before any application logic runs:
# JA3 fingerprint deny-list (request phase)
when: tls.ja3_hash in [
"e7d705a3286e19ea42f587b344ee6865",
"6734f37431670b3ab4292b8f60f29984",
"a0e9f5d64349fb13191bc781f81f42e1"
]
action: deny(403)"Allow CORS from my two app domains, credentials on, preflight cached an hour."
# CORS policy (response phase)
cors:
allow_origins: ["https://app.ngris.com", "https://admin.ngris.com"]
allow_methods: ["GET", "POST", "PUT", "DELETE"]
allow_headers: ["Authorization", "Content-Type"]
allow_credentials: true
max_age: 3600"Require a valid JWT signed by my issuer on everything under /api, reject the rest."
# JWT validation (request phase, before origin)
jwt_validation:
paths: ["/api/*"]
issuer: "https://auth.example.com/"
audience: "ngris-api"
jwks_url: "https://auth.example.com/.well-known/jwks.json"
on_failure: deny(401)"Cache GET responses on /static for a day, keyed by path and Accept-Encoding."
# Response caching
cache:
match: { method: "GET", path_prefix: "/static" }
key: ["url.path", "req.header.Accept-Encoding"]
ttl: 86400"Set a request-id header from a CEL expression and strip the Server header from responses."
# CEL set-var + header rewrite
set_var:
request_id: 'req.header["X-Request-Id"].orValue(uuid())'
request_headers:
add: { "X-Request-Id": "${request_id}" }
response_headers:
remove: ["Server"]You don't have to remember which knob is called what. You describe the behavior; Iris picks the rule type and fills in the fields.
Create-only, and you review before it ships
The traffic-policy generator is one-shot and create-only: Iris produces a draft, and you review, edit, and save it. It never silently changes your live configuration. Every write flows through a confirmation card with a field-level before-and-after diff, and because traffic-policy changes can be high-impact, they also get a blast-radius dry-run — Iris replays the proposed rule against your own recent traffic so you can see what it would have matched before it goes live. You click to apply.
For anything security-sensitive, prefer detect-first. Ship a WAF rule in detection mode, watch what it flags against real traffic, then flip it to blocking once you trust it — the same posture we recommend for the web application firewall at the edge. Iris drafts that detection-only variant for you when you ask for it, which is why the WAF example above starts in DetectionOnly.
Why letting Iris place the rule matters
The hardest part of a traffic policy isn't the syntax of any single rule — it's ordering. Rules execute in phases, and a rule in the wrong phase either does nothing or does damage. Authenticate before you cache, or you leak private responses to anonymous clients. Run the WAF before your rewrites, or it inspects a URL your origin never sees. Set a variable before the rule that reads it, not after.
Because Iris runs inside the gateway, it knows the phase model and places each rule where it actually belongs. When you describe "validate the JWT, then cache the authorized response," it doesn't just write two rules — it orders them so the auth check gates the cache. That ordering is exactly the thing that's tedious to reason about by hand and easy to get backwards, and it's where an assistant that understands the pipeline earns its place. Pair it with traffic inspection and replay to confirm a saved rule behaves the way you meant against real requests.
To try it, install the CLI and put an endpoint online:
# install and start a tunnel
brew install ngris
ngris http 3000
ngris http 3000 --url app.ngris.comThen open the chat and describe the rule you want. The free plan gives you five endpoints with no credit card, which is enough to draft a policy, dry-run it against your own traffic, and see the phase ordering Iris chose before you commit to anything.