Your gateway logs already tell you a request came in, matched a rule, and got a 403. What they don't tell you is why that rule fired, whether it was a false positive, and what to change so a legitimate request stops getting caught. That gap is where you burn an afternoon grepping. Iris closes it: you can analyze traffic logs with ai one request at a time, in the same gateway that served the traffic, so the analysis is grounded in your real captured request — not a generic model guessing at a log line you pasted into a chat box. This post covers the two analysis surfaces that matter for logs: per-request AI analysis, and natural-language log search that turns plain English into a real Traffic Inspector filter and runs it. Iris explains individual requests and searches your logs from a plain-English query; it reasons per request rather than narrating your whole log history in one shot.
Logs tell you WHAT happened, not WHY
A log line is a record of an outcome. "GET /api/checkout, 403, matched firewall rule 12" is true and useless when you're trying to figure out whether rule 12 is protecting you or breaking a customer. When you open a single request and ask Iris about it, it doesn't just restate the line — it explains the decision. Per-request AI analysis will tell you why the request was blocked or allowed, which rule matched and what that rule actually does, classify the request (bot, scanner, legitimate client, misconfigured integration), run a security scan on it, and suggest a concrete fix.
Because Iris runs inside the gateway, the "why" is backed by the request as it was actually captured — the matching rule, the endpoint, the headers, and the outcome — instead of pattern-matching on raw text you pasted. This analysis is read-only: it explains the request, it never touches your config. If the fix it suggests is a rule change, that's a separate, gated step: any write comes back as a confirmation card with a field-level before-to-after diff, and firewall, rate-limit, and traffic-policy changes also get a blast-radius dry-run that replays the proposed change against your real recent traffic before you approve. You see what a rule edit would have done to the last N requests, then click to apply.
One thing to be clear about: this is per-request, not a single "explain this spike" button. Iris reasons about the one request you opened — the request, the rule it matched, its outcome. It's precise about one request at a time, which is exactly what you want when you're deciding whether rule 12 stays. It won't narrate your whole account.
Filter your logs in plain English
The other half is finding the requests worth analyzing. Traffic filters are powerful but fiddly to write from memory. Natural-language log search lets you describe what you're looking for in plain English; Iris extracts the search parameters (method, status, path, IP, time range) and searches your traffic logs, handing back a real Traffic Inspector filter you can see, tweak, and re-run — the same filter you'd set by hand, just generated and executed for you. Ask for something like:
# describe it, Iris compiles it to a real filter
"POST requests to /api that got a 403 in the last hour from outside the EU"
"5xx responses on the checkout endpoint slower than 800ms"
"anything blocked by a firewall rule where the client looked like a scanner"You get back an actual filter you can inspect, tweak, and re-run — not an opaque result set. It's a filter accelerator, not a black box: the compiled filter is the real thing your traffic view already understands, so nothing about it is magic once it lands. Combine the two surfaces and the loop is: filter in English to narrow to the suspicious requests, then open one and ask why it happened.
Analyze, then replay the fixed request
Analysis is most useful when you can immediately test the conclusion. This pairs directly with the live Traffic Inspector and Replay: inspect a captured request, ask Iris why it was blocked, apply the suggested rule fix behind the confirmation card, then replay the same request against the updated config to confirm it now passes. You're not deploying a guess and waiting for the next real user to hit the path — you replay the exact bytes that failed and watch the new outcome.
That closes the full loop. Filter in plain English to find the request, analyze it to understand the rule and get a fix, apply the fix through a dry-run-backed confirmation, and replay to verify. If the fix is a firewall rule, the same machinery that drafts it also powers the firewall rule generator — draft, dry-run, apply, replay.
All of this is one facet of Iris, the AI built into the Ngris gateway. Every AI tool call lands in an activity ledger, so "what has the AI done?" always has an answer. Spin up an endpoint on the free plan (5 endpoints, no credit card) with brew install ngris and ngris http 3000 --url app.ngris.com, send it some traffic, then open a request and ask Iris why it happened.