Ngris ships with a confirm-first AI. Iris reads your account, drafts firewall and rate-limit rules, and shows a diff before anything changes — but it never touches your config without a click. That default is deliberate, and for almost everyone it's where you should stay. This post is about the one narrow exception: ai autonomous security that lets Iris apply a firewall block and revert it on its own, without waiting for you. It's opt-in, top-tier only, firewall-only, and it only fires after a check passes. Everything about it is designed to be reversible and small. If you want the full picture of what Iris is and how it's gated, start at the Iris hub — this post assumes you know the basics and drills into the hands-off path.
The confirm gate is the default — hands-off is one narrow opt-in
Out of the box, every write Iris proposes stops at a confirmation card. Create a firewall policy, update a rate-limit rule, delete a routing entry — each one shows a field-level before-to-after diff, and firewall, rate-limit, and traffic-policy writes additionally get a blast-radius dry-run that replays the change against your real recent traffic before you approve. You read it, you click, it applies. That's true whether you're chatting in the widget or the full-page view.
Hands-off mode does not remove that gate for most of what Iris does. It narrows a single category — reversible firewall changes — and says: for these, and only these, you can let a passing dry-run stand in for your click. Nothing else changes. Updating billing, editing a routing rule, creating a traffic policy, deleting an endpoint — all of it still stops and waits for you.
Firewall-only, reversible-only
Auto-apply is scoped to firewall POST and DELETE — adding a block or removing one. That's the whole surface. It's picked because a firewall rule is self-contained and trivially reversible: the inverse of "block this IP" is "delete that block," and Iris can compute and execute the inverse deterministically.
Rate-limit rules, traffic policies, routing, certificates, members, billing — none of them are eligible, even on the top tier, even opted in. If Iris wants to change any of those, you get the normal confirmation card. The same hard denials that apply everywhere else still apply here: admin and internal APIs, deleting or transferring the account, and — critically — widening Iris's own autonomy are denied forever, prompt-independent. Iris cannot expand this leash from inside a chat.
Only after a passing dry-run
No auto-apply happens until the blast-radius check passes. Before a firewall change goes live unattended, Iris replays it against your real recent traffic and measures what it would have matched. If the dry-run shows the block would hit legitimate traffic — not just the abusive pattern Iris flagged — the change does not auto-apply. It falls back to a confirmation card and waits for you, exactly like every other write.
This is the same dry-run you already see on manual firewall approvals, run first instead of last. It's the reason the hands-off path is defensible: Iris is not guessing. It's acting on a measured replay against traffic that actually hit your endpoints. If you want to understand how that replay works on its own, the traffic inspection and replay post covers the mechanism.
Auto-revert
A passing dry-run is a prediction, and predictions can be wrong — a pattern that looked purely abusive in the last hour can turn out to overlap with real users. So the hands-off path doesn't just apply and walk away. After an unattended block goes live, Iris watches the traffic it affects. If the change starts hurting legitimate requests, Iris executes the inverse — the deterministic DELETE of the block it just created — and rolls back automatically.
This is why the scope is firewall-only. Auto-revert is only honest when the inverse of an action is exact and side-effect-free. Deleting a firewall block you added a minute ago restores the prior state exactly. That guarantee doesn't hold for a traffic-policy edit or a routing change, so those never qualify for hands-off, full stop.
The limits
To be precise about the boundaries of this feature:
- Opt-in. It's off by default. You explicitly enable it; the platform default is "confirm."
- Top-tier only. Unattended autonomy is available only on the top plan. On every other plan, firewall writes stop at the confirmation card like everything else.
- Firewall-only, POST/DELETE. Adding or removing a block. No rate-limit, traffic-policy, routing, certificate, member, or billing change is ever eligible.
- Dry-run gated. Nothing auto-applies unless the blast-radius replay passes first; a failing check falls back to a click.
- Iris can't widen its own leash. Expanding autonomy is a hard-denied action, prompt-independent. You can't ask Iris to grant itself more, and neither can an attacker who gets into a chat.
- Everything else still needs a click. Every non-firewall write, and every firewall write where the dry-run doesn't pass, shows the diff and waits for you.
And every one of these actions is auditable. The AI-activity ledger answers "what has the AI done on my account?" with every tool call Iris made, unattended blocks included — so a hands-off apply is never a silent one. If you're thinking about wiring Iris into your actions and alerts more broadly, the generate firewall rules with AI post is the natural next step: same rules, but you stay in the loop on the apply.
If you're on the top tier and you want to try it, the setup is the same as everything else in Ngris — get an endpoint up first, then turn the mode on.
# install and expose a local service
brew install ngris
ngris http 3000
# or pin it to your own hostname
ngris http 3000 --url app.ngris.comStart with the confirm gate on — it's the default for a reason — watch Iris draft and dry-run a few firewall rules, and only flip on hands-off once you trust the shape of what it proposes. When you do, it stays inside the leash described here: firewall-only, dry-run-gated, auto-reverting, and fully logged. Open a chat and ask Iris to show you a firewall rule for your live traffic.