Skip to main content
The platform has two isolation boundaries, not one:
  1. A customer can only ever read their own tenant.
  2. An operator can only ever read their own datacenter.

​
How it is enforced

Every metric and log line is attributed to its tenant and its operator by the platform itself — never by anything the agent or the browser sends. Every query has its scope injected from the session: a customer’s to their tenant, an operator’s to their operator. Nobody — including you, the operator — can hand the platform a raw query to widen it. There is no API surface that accepts a tenant or operator id from the caller and trusts it.
This is why a node can never leave your operator: there is no destination outside it to name.

​
How it is proven

Two automated leak tests run in CI on every change:
  • One proves a customer cannot read another customer.
  • One proves an operator cannot read another operator.
They are required checks. A change that breaks either one does not merge.

​
What each side can see

Within a single operator there is no narrower role yet. Anyone you add as an operator admin sees all of your tenants’ machines and telemetry, your whole capacity pool, and can reassign nodes, issue and revoke enrollment tokens, and create tenants.

​
Things that deliberately do not cross the line

  • Profile photos are served only to signed-in people on the same tenant, and to that provider’s operator accounts. Anyone else gets the same “not found” as an account with no photo.
  • Console logos are served behind your session and scoped to your operator. Another operator asking for them gets the same answer as for a logo that does not exist.
  • Historical telemetry keeps its original tenant when a node is reassigned. History is documented and never rewritten.