Security model

LokaDB promises one thing: the rows of the chosen tables of a moved organization are stored only in that organization's database.

• The proxy is the boundary. Routing is done by the proxy; the row-level security policies LokaDB installs are routing, not a security barrier. A connection to the cloud database that bypasses the proxy sees every organization's rows, as without LokaDB. Close direct access to the cloud database: only the proxy, the relay and administrators may connect (lokadb check -proxy-hosts verifies pg_hba). Roles that bypass RLS are refused by the proxy.
• Narrow, never widen. The proxy only takes the organization from the statement itself. A wrong guess yields an empty or partial answer, never another organization's rows; a statement with no organization is refused by default; a statement in which the proxy sees no LokaDB table runs under "no organization" rather than "all organizations".
• Not an authorization layer. If the application asks for another organization's document by id, the proxy routes the query to where that document lives. Who may read what is still the application's job.
• The cloud never reaches into the customer network. The agent opens the only connection, outbound, with mutual TLS; tokens are single-use; the agent's private key never leaves its machine; certificates renew themselves and can be revoked. TLS can run end to end from the cloud to the customer database so that the relay sees only ciphertext.
• What LokaDB does not isolate: your application's caches, queues, search indexes, files, logs and error reports; backups and replicas made before the move; and, on the fdw profile, the moved rows in transit through the cloud Postgres (memory, temporary files, logs if log_statement is on). The full list is in docs/limits.md; promise customers isolation only together with that list.

Report vulnerabilities as described in SECURITY.md.