Architecture Center
Multi-tenant controlled workflow
Show how a tenant is bootstrapped, scoped, and isolated so that work, workers, and artifacts never cross tenant boundaries.
previewreferenceContract >=0.8 <1.0Reviewed 2026-07-20
Problem statement
You are building operational software for many tenants, and isolation and authority cannot be left to the interface. The kernel isolates records and enforces policy per tenant.
When to use
- You serve multiple tenants from one platform.
- Isolation and authority must be enforced by the backend, not the client.
- Each tenant needs its own roles, policies, and audit trail.
When not to use
- Single-tenant internal tools with no isolation requirement.
- Cases where all users share one authority domain.
Flow
Tenant bootstrapRole and policy resolutionBlueprint selectionIsolated sessionScoped worker executionTenant-bound artifactsAudit projection
Resource inventory
- Tenant
- The isolation boundary that owns every resource.
- Roles + policy
- Resolve the legal actions for each actor per tenant.
- Session + artifacts
- Tenant-scoped work, never visible across tenants.
- Worker
- Executes within the tenant's policy and authority ceiling.
Failure modes
- Tenant scope violation
- Cross-tenant references are refused at the data layer.
- Unauthorized action
- Policy denies the command; the denial is auditable.
- Environment mismatch
- Commands must target the resource's environment.
Security controls
- Data-layer tenant isolation on every record.
- Authority and policy resolved per tenant, enforced on every write.
- Host-only sessions; internal services never exposed to the browser.
- Per-tenant audit projection.
Deployment checklist
- Tenant bootstrap and role assignment defined.
- Policy bundle set per tenant class.
- Environment scoping confirmed.
- Audit projection monitored per tenant.
Related quickstart: Create your first governed session →