Security

Salut is designed for trusted local networks — your home, office, or lab. All security mechanisms work automatically without configuration.

Identity

Every Salut instance generates a unique Ed25519 keypair on first launch. This keypair is stored in the Salut data directory and persists across restarts.

The keypair serves two purposes:

  • Identity — the certificate fingerprint uniquely identifies this machine to peers.

  • Signing — peer requests are signed to prove they came from the paired identity.

The fingerprint is shared during discovery. The certificate itself is presented during TLS handshakes so peers can pin it to that fingerprint.

Trust Model: TOFU

Salut uses Trust-On-First-Use (TOFU), the same model used by SSH. The first time you encounter a peer, you decide whether to trust it based on context (you recognize the machine name, you’re on your home network, etc.). Once trusted, the fingerprint is remembered.

If a peer’s fingerprint changes (which could indicate a different machine impersonating the original), the trust is invalidated and you’ll need to re-pair.

This model is pragmatic for local networks:

  • No certificate authority to set up or manage

  • No tokens to distribute (unless you want them — see Cluster Tokens)

  • Trust decisions are explicit and visible in the UI

Encryption

Salut separates local client traffic from peer traffic:

  • The OpenAI-compatible API and chat playground listen on local HTTP, defaulting to http://localhost:7258.

  • Peer-to-peer inference traffic uses HTTPS on a separate peer transport port, defaulting to 17258.

Before sending peer traffic, Salut connects to the peer’s TLS listener, verifies that the presented certificate matches the fingerprint learned during discovery/pairing, pins that certificate locally, and then uses the pinned certificate for future requests. Guarded peer endpoints also require an Ed25519 request signature from the paired identity.

Local browser and SDK clients do not need to trust Salut’s self-signed peer certificate, because they use the local HTTP API. Peer-to-peer trust does not depend on the operating system trust store; it uses pairing, certificate pinning, and request signatures.

This ensures:

  • Confidentiality — activations and inference data are encrypted in transit.

  • Integrity — data cannot be tampered with between peers.

  • Authentication — the TLS certificate and request signature are bound to the paired peer identity.

Since Salut peers verify each other by fingerprint (not by certificate chain), self-signed certificates provide the same security guarantees as CA-signed ones for this use case.

Pairing Handshake

When two peers pair:

  1. Peer A is discovered via mDNS, including its fingerprint and TLS port.

  2. Peer B opens a TLS connection and verifies that the certificate matches the discovered fingerprint.

  3. The user accepts the pairing request.

  4. The trust relationship is recorded in the local database.

  5. Future guarded peer requests must arrive over TLS and include a valid Ed25519 signature from the paired certificate.

This ensures both peers are who they claim to be before any inference data flows.

Data Flow

Understanding what data moves where:

On your local network:

  • mDNS advertisements (display name, ports, GPU info, fingerprint) — visible to all devices on the network

  • Inference requests and responses between paired peers — encrypted via TLS

  • Model activations during distributed inference — encrypted via TLS

To the internet:

  • Model downloads from Hugging Face (first use only, cached locally after)

  • Nothing else — no telemetry, no analytics, no phone-home

Stored locally:

  • Ed25519 identity keypair

  • Peer trust database (fingerprints and trust states)

  • Settings and peer records (SQLite database)

  • Cached model weights (in Hugging Face cache directory)

API Key

The optional API key (configured in Settings) protects the OpenAI-compatible HTTP API from unauthorized clients. It does not affect peer-to-peer communication, which is secured by TLS, certificate pinning, request signatures, and the pairing database.

When set, all API requests must include:

Authorization: Bearer your-api-key

This is useful when you want to restrict which applications can query the inference API. Without an API key, any process on the machine, or any network client that can reach the HTTP port, can send requests.

Threat Model

Salut is designed for trusted local networks. It assumes:

  • Your local network is not hostile (you trust the devices on it, or at least can identify them)

  • Physical access to the machine implies full access (no attempt to protect against local root)

  • The mDNS advertisement is inherently visible to all network participants

Salut does not protect against:

  • Malicious devices on the same network that you accidentally pair with (but the pairing flow makes this a deliberate action)

  • Network-level attacks from outside your LAN (don’t expose the HTTP or peer TLS ports to the internet)

  • Compromise of the identity key (stored in plaintext in the data directory)

For multi-site or internet-facing deployments, consider running Salut behind a VPN or firewall.