The credibility of a safety product is the product.
Most tools in this category ask you to trust a slide. We'd rather show you the mechanism: the two gates every change passes through, the floor no policy can lower, and an honest accounting of exactly what's proven on hardware today versus what's still in beta.
The governed-write pipeline
Every change — on any tier — passes through the same fixed sequence. Nothing skips a step.
Gate 1 — the write policy
Per-vendor, deny-by-default. A statement is applied only if it matches an explicit
write_allowed rule and clears the immutable dangerous-verb floor. The
policy engine is statement-aware, not a naive prefix match — a change set is evaluated
atomically, so one disallowed line sinks the entire proposal, and the attempt is still logged.
Gate 2 — the human
The operator approves a rendered before→after diff against the named target device, plus an expandable "exact commands" panel. The AI cannot construct the internal approval token that authorizes an apply — only a human click can. This is un-dismissable: there is no "always allow everything" switch that removes the diff review itself.
The dangerous-verb floor. reload, write erase,
erase startup-config, format, factory-reset, and shell/scripting
escapes (run bash, python, guestshell, tclsh)
are hard-blocked at the policy layer, on every tier, with no override. Command-separator
smuggling — a stray ;, &&, or newline meant to slip a
second statement past the reviewer — is rejected as a multi-statement write, not silently
truncated. No customer policy, no support override, and no pricing tier can weaken this floor;
Bring-Your-Own-Policy can only add allowed read commands, never remove a block.
Who the gates defend against
The AI model itself
Treated as the least-trusted party in the system. It only ever receives redacted text and can
only invoke four fixed tools (list, read, propose,
ask) — an exhaustiveness-checked enum in CI, so a fifth verb can't be
smuggled in by a clever prompt.
Credential isolation
The "agent firewall": the AI/provider code has no dependency edge to the credentials or
transport crates — checked structurally by cargo-deny in CI, not just by
convention. The AI subtree literally cannot link a socket or a secret.
A malicious or compromised device
Device output is treated as untrusted input: rendered as text (never dangerouslySetInnerHTML),
redacted before the model sees it, and secrets are stripped to stable
[REDACTED:kind#N] placeholders before export.
Where the guarantee stops — on purpose, and stated plainly. The read-only property belongs to the AI, not to the terminal: your own raw keystrokes are always unrestricted, by design, because the human is trusted. And an optional external agent integration (NetClaw) reaches devices with its own credentials, outside these two gates entirely — it is always presented as a distinct, separately opted-in surface, never folded into the gated AI's claims.
What's proven live vs. what's still beta
Read is a solved problem across every listed vendor. Governed write is a hardware-proven claim, made vendor by vendor, never all at once. Today that's one vendor; the rest are labeled honestly.
| Vendor | Read (AI) | Governed write | Rollback anchor | Rollback mechanism |
|---|---|---|---|---|
| Cisco NX-OS | Live-proven | Live-proven | Named checkpoint | rollback running-config checkpoint <name> |
| Cisco IOS / IOS-XE | Live-proven | Write-beta | copy running-config flash:<anchor> | configure replace flash:<anchor> force |
| Arista EOS | Live-proven | Write-beta | Running-config backup | configure replace |
| Juniper Junos | Live-proven | Write-beta | Automatic candidate history | rollback 1 + commit (native, transactional) |
| Palo Alto PAN-OS | Live-proven | Write-beta | Last committed config | candidate revert config |
Built in public, including the mistakes
Pre-launch, an internal red-team pass found that a bare newline in a proposed change could slip a second statement past the per-vendor gate into configuration mode — a real, critical finding in the write-policy engine. It was fixed before this ever ran against a customer's gear, and the policy engine is now statement-aware specifically because of it. We'd rather tell you that story than pretend it never happened.
Report a vulnerability
How to report
Email security@ainetshell.com privately — please don't open a public issue for a suspected vulnerability. Include the affected component and version, reproduction steps, impact, and a proof-of-concept where possible.
What to expect
- Acknowledgement within 2 business days
- Triage decision within 5 business days
- Status updates at least every 2 weeks until resolution
- Default 90-day coordinated disclosure window
Good-faith research conducted in line with this policy is authorized; there is no paid bug bounty
at this time. Full scope and researcher guidelines live in the app's SECURITY.md.