Security and Multi-Tenancy

Enforce isolation where the data is

Embeddings are derived from your documents and can leak information about them, so vectors and payloads deserve the same protection as the source data. Use TLS in transit and encryption at rest; authenticate every client and give least-privilege roles (the ingestion service can write, the search service can only read); keep the database on a private network, never open to the internet; and keep API keys in a secrets manager. For multi-tenancy, enforce the tenant boundary where the data lives: row-level security or a mandatory tenant predicate in PostgreSQL, a collection or namespace per tenant, or an engine feature for tenant isolation; do not rely on application prompts or UI. Test isolation with automated checks that a tenant-A query never returns tenant-B rows. Log queries and administrative actions, and apply retention and deletion rules (deleting a document must delete its vectors and any caches).

Protect it, keep it, pick it

Vectors are as sensitive as their sources; plan backups and migrations, then choose with evidence.

Row-level security in PostgreSQL (illustrative)

Every query on the table is automatically restricted to the tenant set for the session. Standard PostgreSQL feature; shown as a pattern, not run here.

ALTER TABLE docs ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON docs
  USING (tenant = current_setting('app.tenant'));

-- in each request, after authenticating the user:
--   SET LOCAL app.tenant = 'acme';
--   SELECT id, body FROM docs ORDER BY embedding <=> :q LIMIT 5;   -- can only see acme's rows

Write a tenant-isolation test

Automatically check that a query as tenant A never returns a row of tenant B, and run it in CI.

Quick check: Where should tenant isolation be enforced?

• Only in the UI
• Only in the prompt
• In the database (row-level security, collections or namespaces), tested automatically
• Nowhere