SECURITY
What the AI can and cannot do on your network.
AI NetShell runs on your PC, over your own SSH, serial and API paths. The AI can read what you allow. It drafts changes, and nothing on a device changes until a person approves the exact commands. These guardrails are built into the application's code, not written as instructions to the model.
HUMAN IN THE LOOP
A person approves every change. The app enforces it.
Many AI tools ask the model to be careful. Here the model can read, and it can propose changes; every proposed change stops at a screen only you can approve.
Reads
Permitted read commands run on their own by default. Turn on confirmation for every read if you want to approve each one.
Changes
Configuration changes are disabled by default. When they are on, each change is checked against the vendor-specific write policy, previewed, and applied only after you click Approve. Then the app reads the device again.
Record
Every command the AI runs and every change is written to an audit log that cannot be quietly edited: who asked, who approved, what ran, and what the check found. Refusals are logged too.
COMMAND LIMITS
Four kinds of command, four rules.
These rules apply to everything the AI runs or proposes. Commands you type yourself in the terminal are yours; the app never blocks them.
- Never allowed
Blocked on every plan. No approval, setting or plan unlocks them, and a proposal that contains one stops as a whole.
reload · erase · format · factory reset · shell escapes
- Always asks first
Commands that change a device's state without changing its configuration never run on their own, even with automatic reads on.
terminal monitor · diagnose sys session filter
- Needs your approval
Configuration changes on Resolve, after you switch them on: the vendor-specific write policy, a preview with a rollback point, your Approve, then the app checks the device again to confirm the change worked.
interface, access-list, VLAN and other config lines the vendor policy allows
- Runs on its own
Permitted read commands, unless you turn on confirmation for every read.
show · get
WHAT THE AI CANNOT DO
No capture, no claim.
No evidence, no answer
Lina answers from your devices' own output and shows where each fact came from.
No change without your click
The AI can only propose. A change reaches a device after it clears the vendor-specific write policy and you approve the exact before-and-after view. There is no switch that removes that review.
Your configs stay on your PC
Nothing is uploaded in the background, and we keep no copy of your configurations. An AI request carries only your question and the device output you chose to share, with recognized secrets removed first. With Your own AI, it goes straight from your PC to Anthropic or ChatGPT and never reaches our servers. With Included AI, it passes through our AI service to Anthropic and is not saved to any database.
show access-lists VPN-USERS → 40 deny ip 10.8.0.0 0.0.0.255 host 10.2.5.20
Every finding carries the capture that produced it, like this one.
These limits are enforced by the application, not requested of the model. Instructions tell a model how it should behave. The application enforces these limits in code. The model cannot bypass the command policy or approval pause. Destructive operations and shell escapes are blocked outright on every plan, and no custom policy, support request, or pricing tier can unblock them.
STRAIGHT ANSWERS
The questions your security team will ask first.
Where does it run?
On the engineer's workstation, over your existing SSH and serial paths. There is no AI NetShell server between you and your gear, and no fleet of agents to deploy.
Whose model, whose key?
Included AI uses AI NetShell credits. On Investigate and up, Your own AI lets you connect an Anthropic API key or sign in with your ChatGPT account. Those requests go directly from the desktop app to Anthropic or ChatGPT and use no AI credits. Resolve adds governed changes.
What can the model actually reach?
Only session output you permitted, with known secret formats redacted before the request leaves the machine. Configuration changes are never inside the model's reach. They are on the other side of two-phase approval: a per-vendor permit list, then your explicit click.
What if it is wrong?
Decline the proposal before it runs. After an approved change, use the verified result and snapshot-backed rollback path when supported. Rollback can fail, so keep an independent recovery path for production work.
ARCHITECTURE
The governed change pipeline
Every change applied through Resolve passes through this sequence. Nothing skips a step.
- AI PROPOSESa change
- PHASE 1write policy: deny by default; reload, wipe, and shell escapes are blocked
- SNAPSHOTa recovery point, prepared with that vendor's method
- PHASE 2human approves the exact before-and-after change
- APPLYon the live shell
- AUDITa record that cannot be edited without detection
- ROLLBACK PATHavailable when the recovery method supports it
Phase 1: the write policy
Each vendor has a deny-by-default write policy. A proposed change is evaluated as a whole: if any line is not explicitly allowed, the entire proposal stops, and the attempt is still logged.
Phase 2: you
The approval happens in the app on your own workstation, in the change panel beside the session. Only the person signed in at that machine can grant it. You review the named device, the exact commands, and the exact before-and-after view before you click.
Every write leaves a record
Each governed change is written to an append-only log: who asked for it, who approved it, the exact commands that ran, and what the app found when it checked afterwards. A proposal blocked by the write policy is also logged, so a refusal is as visible as an approval.
Done means checked
A command finishing is not proof that the work is correct. After an approved change the app reads the device again and reports what it found, and when it cannot confirm the result it says so instead of calling the job done.
Rollback can fail if the device becomes unreachable or rejects recovery. A snapshot and a rollback path reduce risk. They do not guarantee recovery from every failure a live network can produce. AI NetShell never blocks commands you type yourself. Its AI cannot send configuration commands until you approve the exact command set. The change safety guide spells out those limits.
GO DEEPER
Credentials, model access, and change safety
Security guide
How credentials are stored, what reaches an AI model, redaction, and the enforcement model, in plain English.
Threat model
What the system defends against, including misuse by the model, and exactly where each defense is enforced.
Change safety
The approval flow, snapshots, verification, rollback limits, and how to make a first change.
VENDOR MATRIX
What's proven live
We mark governed write live-proven only after an end-to-end run on physical hardware for that vendor. Read-only means the vendor ships with reads only and no write path.
| Vendor | Read (AI) | Governed write | Rollback anchor | Rollback mechanism |
|---|---|---|---|---|
| Cisco IOS | Live-proven | Live-proven | copy running-config flash:<anchor> | configure replace flash:<anchor> force |
| Cisco NX-OS | Live-proven | Live-proven | Named checkpoint | rollback running-config checkpoint <name> |
| Cisco IOS XE | Live-proven | Live-proven | copy running-config flash:<anchor> | configure replace flash:<anchor> force |
| Arista EOS | Live-proven | Live-proven | Running-config backup | configure replace |
| Juniper Junos | Live-proven | Live-proven | Automatic candidate history | rollback 1 + commit (native, transactional) |
| Palo Alto PAN-OS | Live-proven | Live-proven | Saved config snapshot (save config to <anchor>.xml) | load config from <anchor>.xml + commit |
| Fortinet FortiOS | Live-proven | Live-proven | None needed (targeted inverse) | Reboot-free inverse: delete the object that was added |
| Cisco FTD | Live-proven | Read-only | No write path | No write path |
WHO BUILT THIS
Why it works this way
AI NetShell was built by network engineers who wanted AI help on live gear without giving the model direct write access. It is built and run by PACKET 365 LLC.
DISCLOSURE
Report a vulnerability
How to report
Email [email protected]. Do not 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.
GET STARTED
Try it on your own gear.
The terminal is free. Paid plans add AI investigation and governed changes.