Multi-tenant
An architecture where each organization or department operates in an isolated space (organization), with data, keys, budgets and permissions that never mix.
Why it matters
Multi-tenant is the architecture in which a single platform serves several organizations while keeping each in an isolated space: one organization's data, keys, budgets, and permissions never touch another's. It matters because, without that isolation, sharing infrastructure becomes a contamination risk — one customer's data appearing to another, one department's spend landing in the neighbor's budget, a permission leaking across boundaries that were supposed to be airtight.
In the context of AI governance, isolation is the foundation everything else rests on. Per-organization model allowlist, per-cost-center budget, per-identity audit trail — none of it makes sense if the boundaries between organizations aren't real. The question that defines a good multi-tenant architecture is simple and unforgiving: is it possible, from inside one organization, to reach another's data? The answer has to be no, and it has to be provable.
How it works
Each call carries the identity of the organization it belongs to, and that identity follows the request through the entire layer. Data queries are filtered by that organization marker, so a read never returns what belongs to another. Keys, budgets, and permissions are equally scoped: a team's virtual key only reaches that team's resources, the budget is accounted for within the organization, and a permission granted in one has no effect in another.
The delicate point is scoping at the edge: the organization's identity must not be forgeable by the client. That's why it's injected by a trusted point — the gateway — which overrides any attempt by the client to pose as another organization. Without that, isolation would be just a convention; with it, it's a boundary the client doesn't control.
How Horse Labs handles it
At Horse Labs, each organization operates in an isolated organization: the BFF's queries are filtered by the organization identity, which arrives signed from the gateway and can't be forged by the client. Allowlist, budgets, and secrets are scoped per organization, and an attempt to reach another's resources results in a refusal, not a leak. The isolation isn't just intent — it's covered by integration tests that verify, case by case, that one organization can't see what belongs to another.
Common mistakes
The most common mistake is trusting the organization filter coming from the client: letting the application accept the identity the request declares instead of injecting it at a trusted point. Then all a malicious client has to do is change a header to cross the boundary. The second mistake is treating isolation as an untested truth — assuming the filter is on every query without proving it. In multi-tenant architecture, isolation not proven by a test is isolation that doesn't yet exist: the only guarantee is the one you verify.