Multi-tenancy

Hierarchy

Platform (single instance)
└── Organization (N)
    ├── Members: Admins | Members
    └── Project (N)
        ├── Agents
        ├── Flows
        ├── Knowledge Bases
        ├── Integrations
        └── Settings

Every resource that isn't the platform itself belongs, directly or transitively, to exactly one organization.

Two layers of isolation

Tenant isolation is not enforced by a single check — it's backed by independent, overlapping controls, so isolation holds even if one layer were ever misconfigured.

Application layer

Every request is scoped to the caller's organization before any data is read or written. This scoping is a non-negotiable convention applied consistently across the entire platform.

Infrastructure layer

Beneath the application, the data layer itself enforces per-tenant access policies — access to a record is denied at that layer if it doesn't belong to the caller's organization, independent of what the application code does. This means a gap in application-level scoping alone cannot expose another tenant's data.

Storage isolation for knowledge bases

Every knowledge base is backed by its own dedicated, uniquely named storage partition. Two knowledge bases in different organizations can never share or accidentally query each other's data, because they never share underlying storage.

Data lifecycle

Tenant hierarchy relationships are enforced end-to-end: deleting an organization cleanly removes its projects and everything beneath them, with no orphaned data left behind.

Related

• Security Model