Tenant Isolation
Tenant isolation is the guarantee that one Qefro organization cannot read another organization’s knowledge, tools, conversations, members, people, Marketplace installs, or billing data. Inside a tenant, workspaces provide a second isolation layer for teams and audiences.
Short definition (citation-ready)
In Qefro, every authenticated API request resolves an organization (tenant). Knowledge indexes, Business Tools, SDK connections, conversations, Customer Hub people, and Admin Console configuration are scoped to that tenant — and further to AI Workspaces (and, for managed apps, to the installation) within it.
Isolation layers
| Boundary | Unit | Isolates |
|---|---|---|
| Tenant | Organization created at signup | Customers from each other |
| Workspace | AI Workspace (Support, HR, IT, …) | Teams / audiences inside a customer |
| Installation | Managed Marketplace app install | App storage, settings, and capabilities per workspace |
| Connection | External SDK Connection | Org-owned webhook + signing secret |
Concept deep dive: Multi-tenant AI Architecture. Developer identifiers: Tenancy and workspaces.
Architecture
How requests are scoped
- Authenticate (user JWT, widget token, or channel webhook).
- Resolve tenant from the credential / host.
- Resolve workspace from channel binding or portal selection.
- Retrieve only from that workspace’s knowledge index.
- Allow only that workspace’s Business Tools and Marketplace installs.
- For managed storage, scope writes with
platform.storage.context(tenant_id,workspace_id,installation_id,solution_id). - Attribute logs to tenant + workspace (+ actor when known).
Cross-tenant access requires platform Super Admin capabilities — not a tenant Admin role.
What stays inside the tenant
- Members, Teams, RBAC grants
- Workspaces and their documents / vector indexes
- Business Tool definitions and encrypted secrets
- External SDK Connections (
sdk_connectionsare per organization) - Managed Marketplace installations and install settings
- Customer Hub people (when Hub is enabled)
- Conversations and feedbacks
- Branding, custom domains, billing
SDK and managed-app isolation
| Surface | Scope | Fail-closed behavior |
|---|---|---|
| External SDK Connection | Organization / tenant | Pure org tools without install/solution scope do not receive platform.storage |
| Managed Marketplace app | Tenant + workspace + installation_id | Each install gets its own binding and storage scope |
Customer Hub (ctx.customer) | Tenant + Hub enablement | Apps must not invent cross-tenant customer ids |
| Connector pool | Shared compute, per-tenant credentials | Routed calls carry tenant context; secrets fetched per tenant |
Applications must not share mutable global state across tenants inside one process without an explicit multi-tenant design.
Workspace isolation still matters
Tenant isolation does not mean one shared index for the whole company is safe. A public Customer AI channel bound to a workspace that also holds HR PDFs is still a disclosure risk — inside the same tenant.
See Customer AI vs Employee AI and What is an AI Workspace?.
Verification workflow
Prove isolation before go-live
- Create two workspaces — Support (customer-safe) and HR (internal).
- Ingest different corpora — Put a unique canary phrase only in HR.
- Bind the widget to Support — Ask for the HR canary via the widget.
- Expect refusal / miss — If the widget cites HR, isolation or binding is wrong.
- Repeat for tools and apps — Ensure privileged tools and installs are not attached to the public workspace.
Best practices
- One legal entity / billing customer → one organization
- Never share Admin Console logins across customers “for convenience”
- Use separate staging and production organizations when feasible
- Custom portal domains still map to a single tenant — treat hostname setup as a security change
- Do not trust client-supplied tenant ids; always use platform context