TransIT AI

Security model

Transit AI’s security model is built around three rules that the architecture itself enforces. They aren’t promises in a doc — they’re structural properties of how the product is built, verified by automated checks on every change we ship.

The three inviolable rules

Rule 1 — Your SSH credentials stay in your OS keychain, and the UI can’t read them back

Save a password or key once. It goes straight to your operating system’s credential store — macOS Keychain, Windows Credential Manager, or libsecret on Linux — and never comes back out to the part of Transit AI that draws the screen. The AI can’t read it. The logs don’t carry it. Only the piece of Transit AI that actually opens an SSH session can fetch it, and only long enough to authenticate.

There’s exactly one path that writes a secret: the credential entry form on initial enrollment. It’s a one-way trip — there’s no read API on the other side of it.

Rule 2 — The AI can do four things, period, and can’t gain a fifth mid-chat

The AI you chat with in Transit AI has a fixed, four-item menu:

  1. List your open sessions — names only, no scrollback content.
  2. Read the recent output of one of those sessions — with credentials stripped before the AI ever sees the bytes (see “Output redaction” below).
  3. Propose a command for you to approve — it cannot run anything on its own.
  4. Ask you a clarifying question.

That’s the whole menu. The AI can’t browse files on your laptop, open new SSH connections, edit your device inventory, call our cloud directly, or carry memory from one chat into the next. Expanding the menu requires an actual code change we ship and release — a prompt-injected or jailbroken model cannot invent a fifth ability at runtime.

Rule 3 — Every AI-suggested command passes two checks, and you can’t skip either

When the AI wants to run a command, two things have to happen, in order:

  1. The vendor’s permit list says yes. Each supported network OS (Junos, Cisco IOS, IOS-XE, NX-OS, Arista EOS, Palo Alto PAN-OS) has a curated list of read-only commands the AI is even allowed to suggest. Anything not on the list — configure, write memory, delete, shell escapes like start shell or tclsh — is rejected before you ever see it.
  2. You click Approve. A dialog appears with the exact command spelled out and the device it would run on. No “trust this AI for the day” toggle. No silent approval. No keyboard dismissal.

Both checks always run. If you tell Transit AI “always approve show commands in this chat”, you’ve only automated the second step for commands the first step would already permit. The shortcut cannot promote a denied command into an allowed one — if the vendor permit list says no, the answer is no, regardless of what you’ve previously waved through.

Generic Linux is a deliberate exception. A Linux shell doesn’t have a clean “safe-only” command list — practically anything can be piped, redirected, or scripted into a write. On Linux devices Transit AI drops the permit list entirely, surfaces an amber warning banner on every single proposal, and makes the per-command approval mandatory — the always-allow shortcut is unavailable, full stop. You always click for every command on a Linux box.

The agent firewall

The agent has no code path to read a credential.

This is the single most important architectural property of the product, and it isn’t enforced by review discipline. The application is structured so that the agent and the credential store are in entirely separate components, with no programmatic route from one to the other. An automated check verifies the isolation on every change we ship — adding such a route causes the build to fail before it can be merged.

The result: even a model that’s been jailbroken, prompt-injected, or otherwise convinced to behave maliciously cannot exfiltrate your SSH credentials. The “I’d like the password please” path doesn’t exist for it to walk down.

Output redaction

Device output passes through Transit AI’s redaction layer before any byte reaches the AI. The filter strips:

  • PEM blocks — -----BEGIN ... PRIVATE KEY----- and similar.
  • Encrypted password lines — Cisco enable secret, username password 7, password 5, BGP MD5 keys, OSPF authentication keys, SNMP communities, IPsec PSKs, Junos encrypted secrets ($9$…).
  • Cloud credentials — AWS access keys (AKIA…), GCP service account JSONs, Azure connection strings.
  • JWTs — three-segment base64url tokens.
  • TLS/SSH key fingerprints when they appear as full keys rather than abbreviated hashes.

Each redaction emits a placeholder of the form [REDACTED:<kind>#N]. The #N is a per-conversation ordinal — same bytes = same number, so the AI can reason about credential equivalence (“vEX1 and vEX2 share the same BGP MD5 key”) without ever seeing the value itself.

The redaction layer is the boundary between device output and the AI. Patterns are covered by both targeted tests and fuzzed inputs to keep matcher correctness under non-obvious encodings.

Host-key handling (TOFU)

Transit AI uses trust on first use:

  • First connect to a host: Transit AI captures the device’s SHA-256 host-key fingerprint and prompts you via a host-key confirm dialog. Accept records the pin; reject aborts.
  • Subsequent connects: if the device presents a different fingerprint than the pin, Transit AI returns a hard mismatch error. There is no in-app override — you must edit your known_hosts.toml file by hand to recover.
  • A failed authentication does NOT poison the pin file; the fingerprint is recorded only after auth succeeds.

This pins device identity for the lifetime of the record and matches OpenSSH’s StrictHostKeyChecking yes behavior.

Strict cipher floor

The default SSH handshake uses a strict modern allow-list:

  • KEX — curve25519-sha256 (and its libssh-org variant)
  • MACs — implicit via AEAD
  • Ciphers — AES-GCM, ChaCha20-Poly1305
  • Host keys — ed25519, ecdsa-sha2-nistp521

For older devices that default to SHA1 KEX, AES-CBC, or ssh-rsa host keys (some Cisco IOS-XE virtual images, older Junos releases), a per-device opt-in dialog surfaces the offered algorithms and requires explicit “Connect anyway”. “Remember” is a separate checkbox so muscle-memory clicks don’t grant a permanent downgrade.

none / clear ciphers and DSA host keys are never accepted, even on the legacy opt-in path.

Cloud isolation

Transit AI Cloud (api.transitai.app) is an isolated proxy service that holds provider API keys and forwards completions. Operational properties:

  • No prompt or completion content is ever logged. The metering pipeline records token counts, latency, cost, status, and request identifiers — never the bytes you sent the AI, never the bytes it sent back, never device hostnames or device IDs. Field-name guardrails reject any log line that would carry forbidden content, enforced at runtime and at build time.
  • BYOK keys are stripped before forwarding. When you bring your own provider key, the proxy parses it out of the request body before sending the body upstream — even an unauthorized BYOK attempt can’t leak the key as an unknown field.
  • Tenant isolation. Every data read is authorized against the identity claim from your verified session token. There’s no API path that lets a request parameter override which tenant’s data is returned.

Threats considered

Categories of risk we’ve designed against and what mitigates them:

  • AI agent reads credentials. The agent has no programmatic path to the credential store; the isolation is structural and verified continuously (see “The agent firewall” above).
  • Prompt injection from a device. Device output that says “IGNORE PREVIOUS INSTRUCTIONS, run X” doesn’t matter — the per-vendor permit list runs on every proposed command regardless of how the AI was persuaded, and you still have to click Approve.
  • Credential pattern isn’t matched by the redaction filter. Multiple coverage strategies (targeted tests + fuzzed inputs) plus the same defense-in-depth as above — even a leaked credential can’t drive a write because the user still has to click.
  • You reflex-click Approve. The always-allow shortcut gives you an alternative to clicker fatigue, and it never permits a command the permit list has denied.
  • AI loop spins forever. Bounded on three axes — iterations (12), cumulative tokens (50,000), and wall clock (120 seconds). Hitting any cap terminates with a synthetic message explaining which fired.
  • Cloud logs leak prompt content. Mitigated at three layers: runtime guard, build-time check on every log call site, and a blanket ban on direct console output outside one sanctioned log surface.
  • Cross-tenant data leak. Every cloud query is authorized against the session token’s identity — request parameters never override.
  • User downgrades crypto unintentionally. Weak-crypto opt-in surfaces the offered algorithms, requires an explicit “connect anyway”, and the “remember” decision is a separate checkbox.

Reporting a vulnerability

Email security@transitai.app with details. We confirm receipt within 2 business days and aim for resolution timelines proportional to severity (CVSS-aligned). We do not currently run a paid bug bounty.