What multi-tenant means
A tenant is a customer organization with its own users, data, settings, limits and encryption context. Tenants share the platform’s code and infrastructure but not each other’s information.
The risk with shared infrastructure is a single missed filter. EAIBAP reduces that risk with layered controls so no single check carries the whole burden.
Isolation layers
| Layer | Control |
|---|---|
| API | The tenant is resolved from the authenticated identity, never trusted from a client-supplied value alone |
| Authorization | Server-side, deny-by-default, with object-level checks and explicit permissions |
| Database | A tenant identifier on every tenant-owned row, leading every index; tenant-consistent foreign keys; database-level row security recommended as a second layer |
| Cache | Tenant-namespaced keys; no shared entries for tenant data |
| Files | Tenant-scoped storage prefixes, per-tenant encryption context, short-lived signed URLs |
| Search and retrieval | Mandatory tenant and document-permission filters applied at query time |
| Queues and workers | Tenant identifier in every message; workers run under scoped service identities |
| Telemetry | Tenant-safe references only; redaction before export |
How isolation is tested
Isolation is not assumed. Tests cover cross-tenant reads, writes, search, exports, cache keys, vector retrieval and background jobs, and they run on every change. Security testing also covers insecure direct object reference, privilege escalation, server-side request forgery, injection, webhook spoofing and prompt injection.
Noisy neighbors and limits
Per-tenant quotas, rate limits and usage caps keep one tenant’s workload from degrading others. Plans can include stronger isolation tiers for customers with stricter requirements.
Staff access
Platform staff manage plans, limits and health. They do not see customer content by default. Any access requires a ticket, a documented reason, approval, an expiry and an audit trail visible to you.