Multi-Tenancy

Enterprise tenant isolation with Postgres Row Level Security

Multi-Tenancy

Quint uses a shared infrastructure, logical isolation model. Every database table includes a tenant_id column, and Postgres Row Level Security (RLS) enforces isolation at the database level. Application code never constructs WHERE tenant_id = $1 clauses — the database handles it transparently.

Isolation Model

Database: Row Level Security

All tenant isolation is enforced by Postgres RLS. Before any query, the application sets the current tenant context:

SET LOCAL app.current_tenant_id = 'tenant_abc123';

RLS policies on every table automatically filter rows to the current tenant. The application never constructs manual WHERE tenant_id = $1 clauses — this eliminates an entire class of data-leak bugs.

SNS + SQS: Per-Tenant org_id Stamping

All event streaming uses AWS SNS FIFO → SQS fan-out. The ingest service stamps every event with org_id from the authenticated deploy token before publishing, and MessageGroupId = session_id preserves per-session FIFO ordering. Isolation is enforced downstream by Postgres RLS, not by per-tenant topics.

See Ingestion for the fan-out diagram.

Redis: Per-Tenant Key Prefix

All cached data uses a per-tenant key prefix:

tenant:{id}:*

This ensures cache isolation and allows per-tenant cache invalidation without affecting other tenants.

API: Middleware-Based Context

Tenant context is extracted from the authenticated token in API middleware, before any database query executes:

1. Request arrives with auth token
2. Middleware extracts tenant_id from the token claims
3. SET LOCAL app.current_tenant_id is called on the database connection
4. All subsequent queries in the request are automatically scoped to the tenant

Request Flow

Postgres Tables with RLS

All security-critical tables have RLS policies enabled:

Table	Description	Notes
tenants	Tenant registry	Root table for tenant metadata
agents	Registered AI agents	Per-tenant agent inventory
actions	Intercepted agent actions	Partitioned by month for performance
policies	Enforcement policies	Per-tenant policy rules
alerts	Security alerts	Triggered by policy violations
deploy_tokens	Daemon deployment tokens	Used for on-device daemon registration

The actions table is partitioned by month to maintain query performance as event volume grows.

Tenant Onboarding Flow

1. Create Tenant

   A new tenant record is created in the tenants table with organization metadata.

2. Generate API Key

   An API key (qk_...) is issued for the tenant, scoped to their tenant_id.

3. Generate Deploy Token

   A deploy token is generated for installing the Quint daemon on devices.

4. Install Daemon

   The daemon is installed on the target device using the deploy token.

5. Daemon Registers

   The daemon presents the deploy token to the API, which verifies it and registers the device under the tenant.

6. Events Flow

   The daemon begins intercepting agent actions and pushing events to the Cloud API, which stamps org_id on each event and publishes to the shared SNS FIFO topic for fan-out.

Data Residency

Quint follows a cloud metadata, on-device secrets model:

• On-device: All security-critical data (source code, credentials, file contents) stays on the device. The daemon never transmits raw secrets.
• Cloud: Receives structured metadata only — action types, risk scores, tool names, timestamps, and policy verdicts.

This ensures that even in a multi-tenant cloud environment, no tenant’s sensitive data leaves their infrastructure.