Qirava DMS docs
Security & governance architecture
Qirava DMS is the core runtime: governance, database, workers/app runtime, and planned KMS live behind one rule — every untrusted read or mutation must cross L1 before-auth, L2 function scope, and L3 planner RBAC before it can touch data.
The access model before mutation#
Request
│
▼
Worker before-chain L1: authenticate (session/API key/signed key)
│
▼
execute(function) L2: function scope (public/internal/scoped/private)
│
▼
QQL planner L3: table RBAC = app-scope ∩ principal-grant
│
▼
Tables + WAL read/mutate only after the planner allows it- L1 before-auth
- Runs before the handler and writes the caller identity into shared request context. The caller does not get to claim its own role in the request body.
- L2 function scope
- The executor rejects calls to functions outside the root call's allowed scope. Storage helpers are internal-scoped to the QQL handler.
- L3 planner RBAC
- The only door to table reads and mutations. Non-admin callers need the right per-table grant; unknown or unparseable targets fail closed.
Governance catalogs and roles#
Governance power is not granted by being invited; it is granted by role and table/function grants. Onboarding is custodian-gated and starts closed. The role order is custodian > admin > user > guest.
| Surface | Built status | Rule |
|---|---|---|
| sessions | BUILT | Human sessions re-read the live user role/enabled state every request, so demotion/disable takes effect immediately. |
| API keys | BUILT | Keys carry scope and table grants; L3 intersects requested tables with those grants. |
| governance catalogs | BUILT | _sys_users/_sys_sessions/_sys_roles/_sys_api_keys are not writable through QQL, even by admin API keys. |
| invite flow | PLANNED | Custodian-gated single-use invite with default guest onboarding is the target model. |
KMS and worker secrets#
KMS is the planned secret boundary for the DMS. The current KMS work ships safe status/lock, a custodian-only ephemeral unlock for dev/test, protected _sys_kms_* catalogs, and encrypted _sys_kms_secrets rows with AAD-bound app/worker/name scope. Production worker env plumbing, durable seed unlock, DEKs, rotation, M-of-N, and table encryption are still planned. Frontend Quill islands must never receive secrets, DEKs, signing keys, or cross-tenant values.
| Capability | Status | Honest meaning |
|---|---|---|
| KMS status/lock skeleton | BUILT | `kms.status` and `kms.lock` return safe non-secret state including AEAD algorithm `qchacha20-hmac-sha256-v1` / available; `_sys_kms_*` catalogs are reserved and raw QQL writes are denied. |
| TablePolicy.encryption flag | PARTIAL | The policy bit exists; the real KMS-derived cipher backend is not implemented. |
| auth.signed HMAC | BUILT | Signed requests and replay protection exist; the symmetric signing secret is currently stored as-is until KMS lands. |
| encrypted secret catalog | PARTIAL | `kms.put_secret` / `kms.get_secret` encrypt rows with AAD-bound app/worker/name scope after `kms.unlock_ephemeral`; production worker env plumbing is not wired. |
| master seed + DEKs | PLANNED | KMS will derive and protect data-encryption keys from a durable custodian-unlocked master seed. |
| worker secret/env reads | PLANNED | Workers will read scoped values through KMS context once production plumbing lands; values must not leak into client props. |
Compliance mode#
Compliance mode is a DMS deployment posture, not a separate product. It packages existing and planned controls into one auditable mode.
- BUILT building blocks: L1/L2/L3 funnel, role hierarchy, API/session auth, WORM and retention gates, WAL durability, audit-friendly function routing.
- PARTIAL building blocks: encryption policy flag without a KMS-backed cipher implementation.
- BUILT/PARTIAL building blocks now include KMS status/lock skeleton plus reserved KMS catalogs; PLANNED package remains master seed, M-of-N unlock, KMS-derived encryption-at-rest, worker secret/env scope, audit evidence bundle, and clear compliance-mode docs.