AI-Native Tauri Apps

Tauri is a strong fit for local AI desktop tools because it can combine a web UI, a Rust authority boundary, and local sidecars. That same combination is risky if the app grants broad shell or localhost authority.

Common Shape

Vite UI
  -> typed IPC wrapper
  -> Rust command
  -> sidecar manager
  -> local model server, MCP server, CLI, or worker process
  -> app data directory, logs, model files, or user-selected files

Authority Boundaries

Boundary	Risk	Safer pattern
User prompt to sidecar args	Command injection or secret leak	Pass structured input over stdin or local API
Webview to localhost	Localhost pivot or cross-origin confusion	Bind loopback only, require per-install token, narrow CSP
Model files	Arbitrary file reads/writes	Use app data directories and explicit user file pickers
MCP tools	Tool execution beyond user intent	Broker through Rust, confirm dangerous actions
Logs	Prompt, token, or file leakage	Redact and rotate logs
Updates	Sidecar supply chain	Sign artifacts and tie sidecar version to app release

Sidecar Guardrails

No free-form shell strings.
No user-controlled binary paths.
No broad `allow-spawn` without argument validators.
No public network bind by default.
No secrets in process args.
No release claim until sidecar packaging is smoke-tested.

Approval UX

If an AI feature can read files, run tools, start servers, call MCP tools, or mutate local state, add user-visible approval flows. The Rust core should enforce the approval state. The frontend should not be the only guard.

Good First AI App

Start with a local-first desktop utility that:

Uses a Rust command to read app-owned data.
Uses one local model or service sidecar with fixed args.
Stores credentials in OS/secure storage, not the renderer.
Tests IPC mocks, sidecar start failure, and app exit cleanup.
Ships without mobile until the desktop release path is stable.