> ## Documentation Index
> Fetch the complete documentation index at: https://quintsecurity.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

```sql theme={null}
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](/cloud/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

```mermaid theme={null}
flowchart LR
    A["`API Request`"] --> B["`Auth Middleware`"]
    B --> C["`Extract tenant_id`"]
    C --> D["`SET LOCAL app.current_tenant_id`"]
    D --> E["`Postgres RLS`"]
    E --> F["`Response`"]
```

## 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

<Steps>
  <Step title="Create Tenant">
    A new tenant record is created in the `tenants` table with organization metadata.
  </Step>

  <Step title="Generate API Key">
    An API key (`qk_...`) is issued for the tenant, scoped to their `tenant_id`.
  </Step>

  <Step title="Generate Deploy Token">
    A deploy token is generated for installing the Quint daemon on devices.
  </Step>

  <Step title="Install Daemon">
    The daemon is installed on the target device using the deploy token.
  </Step>

  <Step title="Daemon Registers">
    The daemon presents the deploy token to the API, which verifies it and registers the device under the tenant.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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.