Enterprise features
What Mesa provides for running more than one team on one deployment, and — because the difference matters when you are evaluating it — which of those things are on by default and which have to be switched on.
| Feature | |
|---|---|
| Multi-tenant architecture | Isolated workspaces, and how the isolation is actually enforced |
| Data export & erasure | Handling a data-subject request — what is built, what is manual, what "done" means |
| SSO & identity | What comes from the identity provider, and what Mesa itself implements |
| Authorization | Relationship- and attribute-based access control, in-process |
| Admin console | The management interface |
Shape of the system
One deployment, many tenants, sharing infrastructure:
Admin console
┌───────────────┬───────────────┬───────────────┐
│ Tenant A │ Tenant B │ Tenant C │
│ bots │ bots │ bots │
│ keys │ keys │ keys │
│ channels │ channels │ channels │
└───────────────┴───────────────┴───────────────┘
database │ cache │ object storage
(shared, tenant-scoped)
A tenant owns its bots, its provider keys, its authorized channels, its conversation history and its apps. Nothing is shared between tenants by default.
What isolation means here, precisely
This is the claim worth reading carefully, because "complete isolation" can mean several different things and only one of them is true here.
Tenants share database tables. There are no per-tenant databases, schemas or partitions. Every tenant-owned row carries a tenant id, and isolation is enforced by the queries — reads that are required to be tenant-scoped, checked in the application.
A second, independent layer exists — database row-level security, so that a query which forgot its tenant filter would still return nothing. It is dormant unless a deployment turns it on, and turning it on has two conditions rather than one. See Multi-tenant architecture.
Encryption is per tenant. Archived content is encrypted under a key belonging to the tenant, so destroying that key makes that tenant's archives unreadable without hunting down every copy.
Usage and quota are per tenant. Token and cost consumption are recorded per tenant against a monthly allowance, and the allowance is enforced before a model is called rather than discovered on the invoice.
Where to go next
If you are evaluating Mesa for a regulated environment, read Multi-tenant architecture first — it sets out which guarantees are active by default and which are configuration — then SSO & identity, which is the area where Mesa relies most heavily on its identity provider rather than implementing something itself.