Most cross-tenant leaks in multi-tenant software are not exotic attacks. They are a missing WHERE clause, a cache key without a tenant prefix, or a queue name that collides. So Heidi does not treat isolation as a convention that every feature must remember. It is an enforced property of the platform itself.
The rule: no tenant context, no operation
Every substrate operation requires tenant identity as a non-optional parameter. Omitting it is not a runtime default to some shared scope. It is a failure, at build or startup where possible, loud and closed everywhere else. There is one tenant context type threaded through the platform, which means there is one place to audit.
What is tenant-scoped
The scope covers every surface a job or an agent can touch: the runners agents execute in and their own identity, persistent and scratch storage, input and output queues, checkpoints, the Cortex memory and entity resolution, Ledger entries and receipts, model credentials and usage records, egress rules, and caches at every layer. Caches matter more than they sound: a semantic cache keyed on prompt content without tenant scope would leak one company’s content to another, so tenant scope in cache keys is verified by test.
What that means concretely
A runner belonging to your company cannot resolve, address, or read any resource belonging to another company, across all of those surfaces. Your API tokens are tenant-scoped: a token from one company presented in another company’s context is rejected. And when a tenant is deleted, the platform removes that tenant’s substrate state, including logs, checkpoints, and volumes, with retention exceptions documented rather than silent.
The honest boundary
Isolation claims on this page describe implemented, tested behavior, not aspiration. Where a decision is still open, for example offering fully dedicated infrastructure per tenant as a paid tier, it is not claimed here.