Design: multi-tenant isolation model

[imkp1]

What

Design spec for hosting Dexiask as a central multi-tenant cloud, while keeping self-hosting a first-class single-tenant mode on one codebase. This is a design for review — no implementation. It's the foundation the other cloud subsystems (onboarding, billing, ops) will build on, so it's worth agreeing on the boundaries before any code.

Spec: docs/superpowers/specs/2026-07-06-multi-tenant-isolation-design.md

Key decisions (please weigh in)

• One flag, DEXIASK_TENANCY_MODE = single | multi — self-hosted single keeps today's exact zero-config behavior; cloud runs multi. No forked repo.
• Org = the physical isolation boundary (volume, Qdrant partition, memory tree, DEK, compute mount); cross-org is never permitted. Solo self-serve users get an implicit personal org, so there's one tenancy code path.
• Workspace = logical sub-scope (a named project of 1+ repos); an org can cross-workspace search within itself.
• Compute: one shared, bounded worker pool + per-turn org-scoped mount. Cost scales with active turns, not tenant count; idle tenants cost zero. Enabled by the fact that the agent is already read-only (no Bash/Write), so no micro-VM sandbox is needed — the invariant is "no worker process ever has two orgs' data in view at once."
• Data at rest (per-store hybrid): Postgres shared + org_id chokepoint + RLS; Qdrant shared with a mandatory indexed org_id partition; memory + code/session physically per-org.
• Web egress stripped in multi (main exfil vector for a read-only agent); allowlist-proxy deferred.
• Secrets: per-org DEK envelope encryption → per-org blast radius + crypto-shredding on org deletion.

Out of scope (deferred to their own specs)

Onboarding/workspace lifecycle, billing/metering, audit logging, egress-proxy build, RBAC beyond admin/member.

Ask

Review the boundaries and enforcement invariants (§8). Once the design is approved, the implementation plan follows as a separate PR.

🤖 Generated with Claude Code