TransIT AI
Sign up

Blog · June 8, 2026 · Knox Hutchinson

Why We Made the AI Read-Only — and How We Enforce It

Most AI network automation tools have a trust problem. Not because the AI is malicious, but because the blast radius of a wrong command on a production device is real, immediate, and yours to explain.

We built Transit AI around a single constraint: the AI cannot change anything. Ever. This post explains exactly what that means, how it’s enforced at the code level, and why we think the constraint itself is the most important feature we ship.

The Problem With “AI on Production”

When network engineers hear “AI automation,” the mental model that forms is usually an agent that can SSH into a device, run whatever it decides is appropriate, and make changes. That’s a reasonable assumption. It’s also why most engineers won’t let an AI tool near a production firewall.

One wrong no in front of a routing policy, one misread interface name, one hallucinated command on a Cisco NX-OS switch — and you’re writing an incident report at 2 a.m.

The standard industry response to this concern is a policy: “The AI will only run safe commands.” Policies are promises. Promises break. We wanted something that couldn’t break.

Four Abilities. No More.

The AI in Transit AI has exactly four abilities at runtime:

  1. List — enumerate sessions, devices, or context it can see
  2. Read — retrieve the output of a read-only command from a device
  3. Propose — suggest a command for you to approve
  4. Ask — request clarification or more context from you

That’s it. The AI cannot execute a command on its own. It cannot write to a device config. It cannot open a new connection. It cannot gain a fifth ability at runtime — not through a prompt, not through a jailbreak, not through a model update.

This isn’t a setting you can toggle. It’s the architecture.

The Per-Vendor Permit List

The four-ability constraint tells you what the AI can do. The permit list tells you what it’s allowed to propose.

Every vendor in Transit AI has its own default-deny regex allowlist:

  • Cisco IOS / IOS-XE / NX-OS — only show, display, and equivalent read commands pass
  • Juniper Junos — only show and get commands pass
  • Arista EOS — only show commands pass
  • Palo Alto PAN-OS — only show and get commands pass

Any command the AI proposes gets checked against the relevant vendor’s allowlist before it ever reaches your screen. If the command doesn’t match, it’s rejected. The AI never sees a path to configure terminal, edit, set, or any shell-escape sequence.

The lists are default-deny. Anything not explicitly permitted is blocked. That’s the correct direction for a security boundary.

The Automated Build Check

Here’s where it stops being a policy and becomes an engineering fact.

Transit AI has an automated check that runs on every build. If any code path is added that would give the AI component access to SSH credentials, the build fails. Not a code review comment. Not a lint warning. A hard build failure.

The AI has no programmatic path to your credentials — not because we decided not to add one, but because the build system prevents it from existing. Your SSH credentials live in your OS keychain: macOS Keychain, Windows Credential Manager, or Linux Secret Service depending on your platform. The AI component cannot read from any of those stores.

Even a jailbroken model can’t ask for your password. There’s no path to give.

What Happens to Command Output

The AI needs to see device output to be useful. That creates a second surface: what if sensitive data appears in a show command response?

Before any scrollback reaches the LLM, Transit AI runs an output redaction pass. It strips:

  • PEM certificate blocks
  • AWS access keys and secret keys
  • JWTs
  • Encrypted password hashes (Cisco $1$, $9$, Junos $9$ format, etc.)

Redacted values are replaced with ordinal placeholders — [REDACTED-1], [REDACTED-2] — so the AI can still reason about structure (“there are two encrypted passwords in this config”) without seeing the actual values.

This runs automatically. You don’t configure it. It’s not an option you can accidentally turn off.

Your Click Is Always Required

The permit list filters what the AI can propose. Your explicit click is still required before anything runs.

Every command the AI proposes passes the vendor permit list AND your explicit click. Always both, never either.

This is the human-in-the-loop model. The AI investigates, reasons, and proposes. You decide what executes. Nothing runs in the background. Nothing queues up while you’re looking at another tab. The session is interactive by design, not by default.

Why Not Just Use a General-Purpose LLM?

A fair question. You can paste show bgp summary output into Claude or ChatGPT and get useful analysis back. That works, up to a point.

What it doesn’t give you is live device access with a safety boundary. A general-purpose LLM has no connection to your devices, no vendor-specific command knowledge enforced at the tool level, and no way to run follow-up commands against actual device state. You’re doing the copy-paste loop manually, and you’re deciding what to paste — which means you’re already doing the investigation yourself.

Transit AI’s AI agent has session-native context. It sees the actual device state during an active SSH session. It can run a sequence of read-only commands, reason across the output, and surface what’s relevant — without you manually ferrying output back and forth.

The constraint isn’t a downgrade from a general-purpose LLM. It’s what makes the tool safe to use on a production device in the first place.

What This Looks Like in Practice

You SSH into a Cisco IOS-XE router through Transit AI. You ask: “Why is BGP neighbor 10.1.1.2 down?”

The AI proposes show bgp neighbors 10.1.1.2. You click to run it. The AI reads the output, sees the session state and hold-time expiry, proposes show ip interface brief to check the underlay. You click. It reads that too. It comes back with a plain-English summary: the interface is up but the MTU on the path is likely causing keepalive drops, here’s the relevant output.

You didn’t type a single command. Nothing was changed. The AI touched nothing. You now have a diagnosis.

That’s the product.

The Security Review Argument

If you need to get this approved by a security team, the architecture gives you specifics to point to:

  • Default-deny regex allowlists per vendor — no write commands can pass
  • Automated build check prevents any credential access path from being added
  • Output redaction strips secrets before data reaches the LLM
  • Session export re-runs the redaction filter and supports age encryption for the transcript
  • Provider API keys (Anthropic, OpenAI) live in isolated proxy infrastructure, never written to disk inside the app

These aren’t promises in a data processing agreement. They’re properties of the build.

Read-Only Isn’t a Limitation

It’s the architecture.

Every other AI network automation tool in 2026 is either locked to a single vendor, requires weeks of integration work, or gives the AI write access with no hard guardrail. None of those options are useful to a network engineer who needs to investigate a production incident right now, safely.

The read-only constraint is what makes Transit AI usable on Monday morning against a real device. Not in a lab. Not after a six-month deployment project. Now.

Start a session at transitai.app →

Frequently Asked Questions

What does “read-only AI agent” actually mean in practice? The AI can only propose commands that appear on the vendor-specific allowlist — show and equivalent read commands only. It cannot propose configuration changes, shell commands, or any destructive operation. Every proposed command still requires your explicit click before it runs.

How does Transit AI prevent the AI from accessing my SSH credentials? SSH credentials are stored in your OS keychain (macOS Keychain, Windows Credential Manager, or Linux Secret Service). An automated build check runs on every release and fails the build if any code path is added that would give the AI component access to those stores. The isolation is enforced at build time, not by policy.

What vendors does the permit list cover? Transit AI currently enforces per-vendor allowlists for Cisco IOS, IOS-XE, and NX-OS; Juniper Junos; Arista EOS; and Palo Alto PAN-OS. Each list is default-deny — anything not explicitly permitted is blocked.

What happens if sensitive data appears in a show command output? Before any device output reaches the LLM, Transit AI runs an automatic redaction pass. PEM blocks, AWS keys, JWTs, and encrypted password hashes are stripped and replaced with ordinal placeholders. The AI can still reason about the structure of the output without seeing the actual secret values.

Can the AI run commands without my approval? No. Every command the AI proposes must pass the vendor permit list and receive your explicit click before it executes. There is no background execution, no queuing, and no autonomous operation. The human-in-the-loop requirement is not a setting — it’s how the product works.

How is this different from pasting show command output into ChatGPT? A general-purpose LLM has no live connection to your devices. You manually copy output, paste it in, and repeat for every follow-up question. Transit AI’s agent has session-native context — it can run a sequence of read-only commands against the actual device state during an active SSH session, reason across the results, and return a plain-English answer without you doing the copy-paste loop.

Can the AI be jailbroken into running a write command? No. The permit list check happens at the tool level, not inside the LLM. Even if a model were manipulated into generating a configuration command, that command would fail the allowlist check before it ever reached your approval prompt. The safety boundary is outside the model.