--- title: "Built so one organisation never sees another's documents · QueryLlama" description: "Separation at the data layer: row-level security, roles, an audit log and per-organisation credentials." url: "https://royalsoftworks.com/products/queryllama/security/isolation/" source: "https://royalsoftworks.com" format: "markdown" note: "Markdown rendering of the HTML page at `url`. Same content, same canonical URL." --- Security · 1 of 2 # Built so one organisation never sees another's documents. Separation at the data layer: row-level security, roles, an audit log and per-organisation credentials. In the schema ## Built so one organization never sees another's documents. Every document table carries an organization ID, and the schema's Postgres Row-Level Security policies scope a query to the requesting user's organization — at the database layer, so an application bug can't widen it. The policies are written; they are still being hardened and tested before launch. For your IT team - **Isolation** — Postgres Row-Level Security on organizations, users, files, chunks and audit logs, scoped to org membership; the AI-configuration tables are still to be covered - **Roles** — super\_admin, org\_admin, group\_admin, member, viewer — defined in the schema; per-role database rules are still being built - **Audit log** — Append-only table; a database trigger blocks UPDATE/DELETE outright What's in place today ## The data-layer guarantees. ### Row-Level Security on the core tables Organizations, users, files, document chunks and audit logs all carry an organization ID, and Postgres RLS policies restrict queries to the caller's own organization — at the database, not the application. The per-organization AI-configuration table is still to be covered. ### Five roles, rules in progress super\_admin, org\_admin, group\_admin, member, viewer are defined in the schema. Today the RLS policies check organization membership only; the rules that gate what each role can read and write are being built. ### Tamper-resistant audit log table The audit\_logs table has a database trigger that blocks UPDATE and DELETE outright, so a written entry can't be quietly edited or removed after the fact. ### Per-organization credential storage Where credentials need to be stored — like a future bring-your-own-LLM endpoint and API key — the design scopes them per organization, not in a shared pool. [Previous Security: all 2 pages](https://royalsoftworks.com/products/queryllama/security/) [Next Said plainly, for your security review.](https://royalsoftworks.com/products/queryllama/security/said-plainly/) [All of QueryLlama security](https://royalsoftworks.com/products/queryllama/security/)