Why the Confirm button is the whole product

Every demo of AI in a terminal shows the same trick: someone types a sentence, and a command runs. It looks like magic for about four seconds, until you imagine it happening on a core switch at a site you cannot drive to.

The failure mode nobody demos

Network devices do not have undo. There is no dry run on most platforms worth the name, no transaction you can roll back once the interface you were reaching the box through goes down. The cost of a wrong command is not a stack trace — it is a drive.

So the interesting question was never "can a model write Cisco config". It obviously can. The question is what sits between the model and the wire.

What NTerm does instead

You type the change in English. NTerm resolves it against the vendor dialect of the session you are actually in — IOS is not PAN-OS is not FortiOS — and then it stops. It shows you the exact commands, the dialect it chose, and a risk rating. Nothing has happened yet.

You press Confirm, or you press Edit and fix it, or you press Discard. The decision is recorded either way, which means the AI track in the sidebar is an audit trail of what was proposed and what a human actually allowed.

The one exception, and why

Read-only status commands rated low risk run directly. show ip interface brief does not change anything, and making you confirm it teaches you to confirm reflexively — which is exactly how a confirmation dialog stops working. A prompt you always click through is not a safety mechanism, it is a habit.

That is the line: if it cannot change state, it can run. If it can, it waits.

Why this is a design constraint, not a feature

It would be easy to add an autonomous mode. Plenty of tools have. We are not going to, because the moment NTerm can make a change you did not see, every other guarantee on this site becomes marketing.

If you find a path that gets a write onto a device without a human keystroke, that is a security bug and we want to know: security@nterm.ai.

← Back to the blog