Security

Isolation enforced where it can't be bypassed.

QueryLlama is pre-launch, so this page does two things: states plainly what's already built into the data layer, and what's still being hardened before general availability.

01Already built

One organization can never see another's documents.

Every table carries an organization ID, and Postgres Row-Level Security policies enforce that a query can only return rows belonging to the requesting user's organization — at the database layer. An application bug can't leak across tenants, because the database itself won't return the rows.

What's in place today

The data-layer guarantees.

Row-Level Security on every multi-tenant table

Organizations, users, files, document chunks and audit logs all carry an organization ID, and Postgres RLS policies restrict every query to the caller's own organization — at the database, not the application.

Five enforced roles

super_admin, org_admin, group_admin, member, viewer. These aren't just UI labels — the same RLS policies that enforce org isolation also gate what each role can read and write.

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.

What's still being hardened

Said plainly, for your security review.

QueryLlama has not yet had a third-party security audit, and several capabilities described on this site are still in development (see below). If you're evaluating QueryLlama for a regulated environment, talk to us directly about your specific requirements and timeline.

03Built in the open

What's running today, and what's next.

QueryLlama is pre-launch. Rather than blur the line, every capability on this site is labeled by build status — so a design partner or security reviewer knows exactly what they're evaluating today.

Multi-tenant isolation (Postgres RLS)

Every table scoped by organization; enforced at the database layer.

Live in the MVP build

Document ingestion: chunking + embeddings

Upload to R2, chunk on a sliding window, embed via Cloudflare Workers AI, store in pgvector.

Live in the MVP build

Keyword search (Postgres full-text)

Full-text search over indexed document chunks.

In active development

Semantic + hybrid search (RRF)

Vector similarity search and a reciprocal-rank-fusion blend of keyword and semantic results.

In active development

RAG question-answering with citations

Ask a question, get an answer grounded in retrieved chunks with a link back to source.

In active development

Bring-your-own-LLM (enterprise)

Point the answering step at your own OpenAI-compatible endpoint.

In active development

Audit-log event writes

The append-only table exists; wiring every action through to it is in progress.

In active development

Group-level permissions & tier billing

Finer-grained access rules within an org, and metered plan enforcement.

Designed, on the roadmap

Read the full technical reference.

Data model, RLS policy structure, and the architecture behind every claim on this page.

Talk to the team that actually builds the software.

Pilot deployments, volume licensing, product demos, security questionnaires — all handled by engineers and product leads, not a routing layer. We respond within one business day.

Schedule a discovery call
Half-hour walkthrough with someone who built the product — no sales script.
Run a pilot deployment
Full-feature evaluation with guided install, configured for your environment.
Email us directly
sales@royalsoftworks.com — we respond within one business day.

Send us a message

Leave your details and we'll follow up within one business day.