Trust Boundaries: Privacy, Teams, and Operations

ai-memory's continuity benefit changes with its deployment boundary. A loopback service on one laptop, an authenticated homelab server, and a shared team instance expose different data and failure surfaces. This chapter compares those shapes, then connects authentication, project scope, backups, capacity, and uneven agent support so you can choose the least complicated arrangement that still protects the history being recorded.

Three deployment shapes, three threat models

For a solo user on one machine, the safest default is also the simplest: bind the service to loopback. A process outside that machine cannot reach a loopback-only listener, so a single user can operate without configuring authentication for local calls. The absence of a bearer token is not an abstract security virtue; it is acceptable here because the network boundary supplies the first control and the service is not being offered to a neighbor or a teammate.

That reasoning changes as soon as the listener is reachable beyond the machine. A LAN-bound service with no authentication would allow anyone who can reach the port to call memory APIs, inject observations, consume provider budget, or invoke destructive operations. ai-memory therefore fails closed for unauthenticated non-loopback HTTP unless an operator explicitly enables a dangerous exception. The normal next step is a bearer token for machine APIs and clients, together with an allowed-host policy that reduces DNS-rebinding risk.

A bearer token is authentication, not encryption. On plain HTTP across a LAN or remote connection, a packet observer could read the credential and the project history it protects. The project deliberately leaves TLS termination to a reverse proxy such as Caddy or a tunnel rather than implementing its own certificate machinery. This makes the deployment rule conditional rather than ceremonial: loopback and local stdio may not need TLS, while a remote or multi-user server should put encrypted transport between clients and the bearer-protected service.

The third shape is a shared server. Human users can sign in through web sessions, machine clients can use root or user API credentials, and writes can carry actor attribution into the audit log and page metadata. Handoffs and open sessions can be owner-scoped, so one operator does not accidentally consume another's unfinished work. Administrative endpoints remain root-only once the deployment distinguishes operators.

But multi-user mode is not per-page authorization. The wiki remains a single-tenant knowledge space for the project: authenticated operators can generally read the same pages, and attribution records who changed a page without deciding who may read it. Handoff ownership protects a baton, not the entire project history. If users need hard data isolation, the documented answer is separate servers or data directories behind an appropriate gateway, not a hidden assumption that an aim_ credential creates a private wiki.

The capture boundary is part of this threat model. A marker file can drop recognized private file-tool events before they reach the spool or network, and allowlist mode can require explicit repository opt-in.