Operator stays in control

iPilot never executes a command without your approval — either a click, or an explicit Autopilot setting you control. Nothing runs silently.


How Plans Work

When you send a message, iPilot replies with one of:

  1. A clarifying question — if your goal is ambiguous.
  2. An execution plan — a numbered list of commands, each with:
    • The exact command to run
    • A one-line explanation of why
    • A risk badge: safe · caution · destructive

You can:

  • Run steps one at a time (click Run on each step)
  • Run all safe steps at once
  • Accept the plan and let it build on Autopilot — safe and caution steps auto-run, while destructive steps still pause for approval

After each step runs, iPilot reads the output and refines the next step automatically.


Risk Levels

Risk Meaning Examples
🟢 safe Read-only, no state changes show, print, display, get, monitor-traffic
🟡 caution Changes config but easily reverted /interface set, /ip address add, /queue simple add
🔴 destructive Wipes, reboots, or deletes critical config system reset, erase startup-config, format flash, halt
Destructive commands always pause

A server-side denylist automatically re-classifies dangerous patterns as destructive and marks them blocked — even if the AI under-reports the risk. Blocked steps require an explicit CONFIRM before they run.


Autopilot

The Autopilot toggle controls how much automation you allow:

Setting Behavior
Off (default) Every step needs an explicit click
On safe and caution steps auto-run; destructive steps always pause for a click

Autopilot status is shown by a yellow indicator in the panel header.


Context & Memory

iPilot maintains a rolling conversation history with a configurable context window:

  • Use /compact to condense older messages while preserving key findings
  • Use /context to see current token usage
  • Use /clear to start a fresh conversation

The system automatically retains the last 20 messages minimum, so recent context is never lost during compaction.


Safety Guarantees

  • Server-side denylist — hard-blocked patterns include system reset, reload, erase startup-config, format flash, halt, shutdown, and equivalent destructive commands across vendors.
  • Rate limits — capped tool iterations per request and requests per minute, per user.
  • Full audit trail — every action is logged with the operator, target device, and risk level for accountability.
  • Outbound request guard — the web search tool blocks requests to internal or private network addresses.