Reference
Security model
Bastion is local-first by design. The product decisions below are not features. They are constraints that shape every other piece of the workspace. This page is the long form; the marketing version is the short form.
Threat model
What Bastion defends against
- Accidental password persistence. Passwords are memory-only.
- Local SQLite exfiltration without OS access. There is no network sync by default.
- Tampered updates. Version 1.1.0 checks a signed latest.json on downloads.bastion.hexifytech.com.
- Host key impersonation after a server reinstall. Fingerprint mismatches require explicit confirmation.
- AI context passes through a redaction step before a provider call. That step was not independently audited.
What it does not defend against
- A compromised local OS or a user-level attacker who already has your session.
- The absence of full-disk encryption, a hardware token, or your own operational hygiene.
- Sending a question to an AI provider. Submitting a question sends the attached context to the provider you configured. Approval applies to proposed commands, not to the question itself.
Storage model
| Data | Storage | Notes |
|---|---|---|
| Host metadata, groups, snippets, settings | Local SQLite (bastion.db) | Stays on this device |
| Private keys | OS keychain | Credential Manager / Keychain / Secret Service |
| Passwords | Memory only (active connect) | Never persisted to disk |
| Terminal scrollback | In-memory | Not synced, not backed up |
| Update checks | Tauri updater | latest.json on downloads.bastion.hexifytech.com |
Hard guarantees
- No cloud sync of host metadata.
- SSH private key bytes are not returned to the interface. They are loaded from the OS keychain for the SSH service.
- Passwords are held in memory for the active connection and are not written into SQLite.
- Host-key mismatches require explicit confirmation.
- AI provider calls leave the device. Version 1.1.0 builds a redacted context pack first. API keys for those providers are stored in the keychain and are sent to the provider you chose.
Fingerprint verification flow
Every SSH connect compares the server-presented host key against the trusted entry for that host.
- Trusted and matches: connect silently.
- New key: accept once, then store the fingerprint in
bastion.db. - Mismatch: block until you explicitly replace the trusted fingerprint.
Updatability and signing
The 1.1.0 build checks https://downloads.bastion.hexifytech.com/latest.json and embeds the updater public key. Checksums are in SHA256SUMS.txt on that same host.
Reporting a vulnerability
Please reach out through one of the channels below before filing a public issue. We aim to acknowledge within two business days and ship a fix or mitigation on a coordinated disclosure schedule.
- Contact form: send a security report. Messages go to hello@bastionterminal.com.
- A public source repository is not published, so this page does not offer a GitHub advisory link.