Tenant isolation in a multi-strategy platform
- Severity
- High
- Status
- Published
- Affected area
- Isolation
- Published
- Last reviewed

A platform that runs many strategies for many clients on shared infrastructure is efficient — and, if built carelessly, a single point of catastrophic coupling. Isolation between tenants is not a nice-to-have feature; it is the boundary that stops one client’s mistake, bug, or breach from spilling into another’s positions, data, or credentials. On a multi-tenant execution platform, isolation is a first-class security control.
§01Isolate the blast radius
The starting point is that no tenant should be able to consume resources another tenant depends on. A runaway strategy that floods the order path, exhausts memory, or saturates a market-data feed must be contained so its neighbours keep running. That means resource quotas, separate execution contexts, and independent risk budgets — a limit breach in one tenant trips only that tenant’s controls, never the whole platform’s.
§02Separate secrets and state
Each tenant’s exchange credentials, strategy parameters, and positions must be invisible to every other tenant. Shared strategy state is a leak waiting to happen: one client’s intentions become another’s signal. Scoped credentials, per-tenant encryption, and least-privilege access ensure that even a compromised strategy cannot read across the boundary. The design assumption is that any single tenant might be hostile, and the platform holds regardless.
§03Fairness and attribution
Isolation is also about fairness under contention. When two tenants compete for the same shared resource — a gateway session, a rate-limited endpoint — the platform must arbitrate deterministically rather than letting the noisiest strategy win. Every order, fill, and limit check must be attributable to exactly one tenant, so that risk, cost, and blame are never smeared across accounts. Clean attribution is what makes reconciliation and post-incident review possible at all.
§04The multi-tenant mindset
Building for isolation means treating the boundary between tenants with the same seriousness as the boundary between your system and the public internet. Contain the blast radius, separate the secrets, attribute everything, and assume any tenant could be the one that goes wrong. This advisory is educational and illustrative and is not security advice for any specific platform.