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, using your own forwarded token so the analysis is grounded in your real account data — 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 compiles to a real filter.
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 and reads through your token, the "why" is backed by your actual configuration. It can pull the matching rule, the endpoint, and the surrounding traffic to reason about the request instead of pattern-matching on the raw text. Reads are always allowed and read-only, so this analysis never touches your config — it only explains it. 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 and read-chained, not a single "explain this spike" button. Iris reasons about a request by reading the request, then the rule, then related traffic — a chain of scoped reads. It's precise about one request at a time, which is exactly what you want when you're deciding whether rule 12 stays.
Search your logs in plain English
The other half is finding the requests worth analyzing. Traffic filters are powerful but fiddly to write from memory. The natural-language smart-filter lets you describe what you're looking for and compiles that English into a real traffic filter — the same filter syntax you'd write by hand, just generated 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 search 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: search 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. Search 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 that knows both the platform and your account. Every AI tool call lands in an activity ledger, so "what did the AI read on my account?" 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.