Trust.

Every tenant has a dedicated Qdrant collection named qlv_tenant_<uuid>. The collection name is derived deterministically from the tenant identifier and is not stored anywhere a query can construct from user input. Every retrieval call passes a payload-level filter pinned to the tenant ID; the retrieval layer refuses to issue a query without one.

Soft-delete state is masked at query time, so a deletion that has not yet run through the maintenance cron is invisible to retrieval. When a connector enforces source-side ACLs — Google Drive permission emails, Confluence space restrictions, Slack channel membership — those ACLs are stored on the chunk and filtered at the same layer as tenant identity.

Cross-tenant data leakage is enforced by tests in CI. The retrieval suite includes adversarial cases that attempt to query tenant A while authenticated as tenant B; a passing build requires zero leakage across the suite.

Quelvio supports three credential types. Humans authenticate via OAuth 2.1 device flow. Headless workloads use Personal Access Tokens prefixed qlv_pat_; CI/CD pipelines use Service Account keys prefixed qlv_svc_ with admin-defined scopes.

All opaque tokens are stored only as a SHA-256 hex digest with an indexed column for O(1) lookup. Entropy is sourced from secrets.token_urlsafe(32). The plaintext is shown to the user exactly once at issuance and is never written to logs, traces, or audit metadata — a property verified by dedicated tests in the auth test suite.

Per-user authority scoring shapes what content the system surfaces to a given identity, so two employees with different roles in the same tenant see retrieval results filtered to the documents they had standing access to at the source.

Tenant administrators configure a per-tenant policy bundle: maximum active session age, maximum idle session age, IP allowlists, maximum PATs per user, and maximum Service Accounts per tenant. Policies are isolated per tenant; there is no cross-tenant inheritance or default fall-through.

Violations are fail-closed. An expired session denies the request and emits session.expired_by_policy. A request from outside the IP allowlist emits access.denied_by_ip_policy. PAT and Service Account creation that would exceed configured caps emits pat.limit_reached or sa.limit_reached respectively and denies the create. Every denial is paired with an audit event the admin can inspect.

When a person leaves the company, every credential they hold must be revoked together — or none of them should be revoked, so the admin can retry. Quelvio implements offboarding as a single atomic operation that revokes every OAuth session, every Personal Access Token, and every Service Account associated with the user in one transaction.

Offboarding is triggered either by an HRIS webhook — signed HMAC-SHA-256, with a timestamp replay window — or manually by an admin in the dashboard. The operation is idempotent: a retry after a partial failure rolls back to zero partial state and re-runs cleanly. Each revoked credential emits a credential.revoked_by_offboarding audit event so the trail of every removal is visible to the admin and to procurement reviewers.

Every authentication event, configuration change, credential issuance and revocation, query, and offboarding action is recorded in an append-only audit log. The application layer enforces append-only semantics; there is no UI or API path that mutates or deletes an audit record.

Query attribution is recorded per answer: the source chunk references that informed a given response are stored so that, when a right-to-be-forgotten request lands, the team can verify exactly which queries surfaced that content and which downstream answers cited it.

Customer administrators access the audit trail directly from the dashboard. Export is available for procurement reviewers and compliance teams who need an offline copy.

Secrets at rest are encrypted with Fernet — AES-128 in CBC mode authenticated by HMAC-SHA-256. The Key Encryption Keys (KEKs) are tenant-level and stored in AWS Secrets Manager; rotation is operationally supported and the application reads the current KEK on every decrypt path.

Fine-grained tenant-derived keys protect per-purpose secrets like offboarding webhook signing keys, so a compromise of one tenant's secret material cannot be used to decrypt another tenant's. All API traffic is served over TLS 1.3, and database connections from application services to RDS run over TLS.

Tenants select a region at creation: Global, Europe, or Americas. Tenants on the Europe region are pinned to EU infrastructure — content storage, embeddings, audit logs — and are never processed on non-EU infrastructure for the components Quelvio controls. Cross-border processing that runs through third-party AI providers is documented separately in the privacy policy and the data residency policy.

Region cannot change once a tenant is created. Migration between regions requires a full re-ingestion, which prevents accidental data movement from operator error or a misconfigured deployment. The detailed mechanics are described in the data residency policy.

Deletion follows the source. When a document is deleted in Google Drive, Confluence, Slack, or any other connected source, the connector emits a soft-delete signal. The signal masks every chunk derived from that document at query time, so the content disappears from retrieval immediately — before any background job runs.

A maintenance cron then runs a full purge across Postgres and Qdrant — typically within 24 hours of the soft-delete. Customers can request an immediate purge through support; the on-call rotation has a documented runbook for the manual run.