Home/Platform/Roles & Multi-Tenancy
One workspace
Serve every customer. Keep each environment distinct.
You run one workspace and your clients sit inside it as sub tenants. Records, storage, policy and branding are separated per tenant. The trust between them runs in exactly one direction, and no setting, role or request reverses it.
The direction of trust
Down into your own sub tenants. Never back up, never sideways.
An MSP primary tenant may map into the sub tenants it owns, and any tenant may work within itself. A sub tenant reaching into the primary, or into a sibling, is not a permission you have failed to grant — it is a thing the platform does not do.
- Your primary tenant may map into a sub tenant it owns, on request, for a bounded period, with the approval recorded.
- Any tenant may work within itself without asking anybody.
- Read-only browsing of your own book stays open — the wall is around privileged work, not around knowing your clients exist.
Roles and reach
Scope is identity times customer, not a checkbox on a user.
A role does not mean the same thing everywhere. What someone can do depends on the role they hold and the tenant they are holding it in — and an operator can be live in more than one context at a time.
What the wall is made of
Separation you can point at, not a filter on a shared table.
Records and storage
Each tenant's operations, receipts and evidence live in that tenant's own isolated storage. Retention is set per client, so a client with a five-year obligation is not held to your default.
Reporting & exports →Policy and branding
Approval rules, maintenance windows and what may run unattended are set per client, because one of your clients will insist on authorizing everything and another will not want to be asked. Exports carry that client's branding, not ours.
People and agents
Seats are yours; the accounts the work runs as are the client's. Your technician keeps their own identity across every context — you never end up with one shared admin account that everybody knows.
Credential vault →The full sub-tenant identity chain runs from your client's own identity provider through to an account mapped to a seat or an agent. Two links in that chain are still being built: bringing your client's own identity provider, and mapping one of its accounts to a seat. Everything after them — checkout, elevation, dual-identity evidence — is in place. If your onboarding leans on those two, ask about them directly on a call and we will show you exactly where they stand.
The thing you do forty times a day
Switching client is an operation, so we treat it like one.
A technician moves between clients constantly. If that costs four clicks and a spinner each time, it is not an inconvenience — it is a tax on every ticket you close. Click count and time-to-usable are product qualities here, not polish.
- Switching starts a new session. The new context is clean, and nothing from the last client is quietly still in scope.
- Work you left running keeps running. An operation started under the previous context continues, keeps accruing its own tracked time, and lands in that client's record — not this one's.
- You can hold more than one live context. Two clients, two boards, no confusion about which target you are about to touch.
- Every switch is recorded. Who moved into which tenant and when is part of the same audit trail as the work itself.
What people check before they trust this with a client list.
Can one of my clients see another one?
No, and there is no configuration that changes it. A sub tenant cannot reach a sibling and cannot reach your primary tenant. Those two paths are not permissions we withhold — they are directions the platform does not travel, for an AI agent exactly as for a person.
Do my technicians get standing access to every client?
No. Privileged work inside a client's tenant requires an active grant; without one the call is refused. Read-only browsing of your own book stays available, so your team can see their clients without holding rights over them. How a grant works →
What identity does the work actually run as?
Two identities travel with every request and neither replaces the other. The seat is your licensed technician, and the selected identity is the account the work runs as inside the client's environment. Both are in the record, which is what lets an auditor tell "Marcus, using the service account" apart from "the service account, by itself".
Where does the evidence live?
In the tenant that owns the work, in that tenant's isolated storage, for the life of the workspace with retention set per client. Exports leave under that client's branding. See Reporting & Exports and the trust center.
What happens to a machine that moves from one client to another?
The machine moves; its history does not follow it. Evidence is a point-in-time record of what happened on a device, not a property the device carries around. The old tenant keeps its records and the new tenant starts a clean one. See Devices & Discovery.
Test the wall
Ask us to reach from a sub tenant into your primary. Live.
It is a five-second demonstration and it tells you more about an architecture than an hour of slides.