Architecting Bastion AI's trust model

Status: planning complete. The first wave (A0) lands the orchestrator, providers, and the trust shell described here. This post is the design rationale.

The hardest problem in building an AI for infrastructure is not prompts, context size, or model choice. It is trust.

A model that can read your terminal output and propose commands is, by construction, a tool that can break things. The right design does not hide that. The right design leans into it, and gives the user the leverage to stay in control.

This post explains how Bastion AI’s trust model is being designed, and why we believe it has to be the product rather than a feature.

The problem with “AI in a terminal”

The standard “AI in a terminal” pattern is: paste a command, get a response, run it. That gives the model three powers the user does not control:

1. It decides what context to read. Output, scrollback, host metadata, whatever the model can grab.
2. It decides what to suggest. Whatever the model thinks is the next step.
3. It decides how confident it is. You see a string; you don’t see the alternatives.

If the user pastes an error, gets a command, and runs it, they have delegated all three decisions to a system they can’t audit.

That is not what we want to ship.

The plan card, in one screen

Every AI-proposed mutation goes through a Plan Card. The card has exactly five things on it, every time:

1. What it will do: one line per step, written for the user, not the model.
2. What the risks are: elevated risk, destructive, requires sudo, touches production. Plain language, no hedging.
3. What the targets are: host:tag, session id, full paths. Nothing ambiguous.
4. The exact commands: the user can read them, edit them, copy them.
5. The action: Approve, Edit, Reject. Plus Approve all and Step-by-step for higher-risk cases.

There is no “press enter to run” affordance. There is no “trust the model” option. The card is the contract.

Secret redaction, by default

A model that reads scrollback will see secrets unless we stop it. Bastion AI’s pre-prompt redaction runs in the context builder, before anything leaves the device. The redaction covers:

• Passwords (any line matching common auth patterns).
• Private keys (lines that look like OpenSSH key bodies).
• Passphrases (anything entered at an obvious prompt).
• Redacted env values (anything flagged as sensitive by the user).

Redacted values are replaced with [REDACTED:type] in the prompt and a warning is shown in the response: “I saw 2 redacted values; tell me if you want me to use them.”

The redaction list is open and documented. The full trust policy lives in the docs.

Three operating modes

The first wave of Bastion AI ships three operating modes that don’t mutate anything. They are read-only by construction.

• Ask AI: natural language question; the model reads the active session and answers.
• Explain: explain a selection, an error, a stack trace.
• Fix: propose a fix as a plan. The user has to approve to run it.

These are useful on their own, and they let us ship a real product without ever mutating a host without consent. The trust pipeline gets used, hardened, and audited before we add execution.

The next wave (A2) adds single-session, approved command execution through the same Plan Card. Multi-host automation lands in A3 with stronger gates for production.

Providers: cloud, self-hosted, BYOK

Local-first is the design center, not a marketing line. That means the AI has to work without our cloud. From A0:

• Cloud: OpenAI, Anthropic, Google, OpenRouter. Useful, but opt-in.
• Self-hosted: Ollama, LM Studio, vLLM. OpenAI-compatible path first, more later.
• BYOK: your own API key, stored in the OS keychain alongside your SSH keys.

The default provider is whichever one you configure. If you don’t configure one, the AI is disabled. The terminal is still the full product. We do not have a “Bastion-hosted” option. That is a deliberate choice, not a roadmap gap.

What we will not ship

The non-goals are as important as the goals:

• Silent multi-host execution. Production deploys will always require step-by-step approval.
• Sending full scrollback to a cloud model by default. Only the redacted context leaves the device, and only if you opted into a cloud provider.
• Replacing the terminal with a chat-only interface. The terminal stays a first-class surface. The AI is one panel among several.
• Bastion-hosted cloud as a first-class path. Local and BYOK users are first-class, not second-class to a cloud we operate.

Where to read the design

• Bastion AI feature page. The marketing version.
• Bastion AI docs. The long-form reference, with the architecture diagram, the wave plan, and the full trust policy.
• Roadmap. Where A0–A5 sit relative to the rest of the product.

Ask, Fix, and Plan are in 1.1.0. Download Linux from the download page.