Trust Boundaries in a Local-First AI Assistant
Design notes from K.A.L.K.I.: why a desktop assistant needs an authenticated localhost API, guarded system actions and an explicit model of what it is allowed to do.
- Published
- Nov 2026
- Reading
- 5 min
- Topics
- local-first, AI assistant, security, localhost API
The risk nobody demos
A voice assistant that can open apps, run workflows and read the screen is, by design, a bridge into the host machine. If that bridge is a localhost server, any web page the user visits can try to talk to it. Convenience and attack surface grow together.
Making the boundary explicit
K.A.L.K.I. treats its local server as untrusted territory: a per-installation token protects every route, origin checks reject cross-site requests, and host code execution is disabled by default. Privileged actions sit behind explicit safeguards rather than being one prompt away.
Local data, locally
Memory, preferences and credentials live in a dedicated user-data location with safe storage, not beside the application code. Model providers are configurable, with a local fallback, so sensitive context doesn't have to leave the machine.
The design lesson
The interesting decision isn't a feature — it's making the trust model visible. Users should be able to tell what the assistant can do, where it can be reached from, and what it will refuse.