PlatformDelivery BoardAutomation & RunbooksOutcome ReceiptsJust-in-Time ElevationCredential VaultGoverned SessionsDevices & DiscoveryPatch ManagementReporting & ExportsRoles & Multi-Tenancy
Verified AI OperationsThe Operation LoopCommanded AutonomyCompare the operating modelThe Verified Operation Spec
SolutionsFor MSPsFor Enterprise & Internal ITHealthcareLegalFinancial servicesMunicipal & Education
ProofOperation walkthroughSecurity & architectureVerified Operation SpecFive questions for your RMM's AIChangelog
CompanyAboutFounder's noteContact
PricingBuy 1–20 technician licenses onlinePlans — from $499 per monthCustom requirementsFoundation Circle
Log in

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.

How scope resolves for one request
signed-in seatThe licensed technician. This never changes shape.
active contextWhich tenant's walls apply right now.
selected identityThe account the work runs as. Additive — it never replaces the seat.
grantPresent, or the privileged call is refused.
the recordAll four land in the operation record, together.

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.

The direction of trustsub tenants
PERMITTED MSP PRIMARY your own workspace your technicians, your agents SUB TENANT A a client of yours its own records SUB TENANT B another client its own records ✓ MSP PRIMARY → ITS OWN SUB TENANTS ✓ ANY TENANT → WITHIN ITSELF Mapping in is request-driven: time-boxed, approved, and audited. NEVER — FOR AGENTS EXACTLY AS FOR PEOPLE MSP PRIMARY your own workspace out of reach from below SUB TENANT A a client of yours cannot look outward SUB TENANT B another client never sees a sibling ✕ SUB TENANT → THE MSP PRIMARY ✕ SUB TENANT → ANOTHER SUB TENANT No request unlocks these. There is no approval that turns them on.
Privileged work inside a client's tenant needs an active grant, or the call is refused outright — standing access across your book of clients is not the default and cannot be configured back in. An AI agent gets no wider door than the person who commanded it.
  • 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.

Roles against reachidentity × customer
ROLE MSP PRIMARY SUB TENANT A SUB TENANT B MSP administrator owns the walls FULL your own workspace ON REQUEST time-boxed, approved, audited ON REQUEST asked for separately Technician does the work ASSIGNED WORK what the board hands them UNDER A GRANT and only while it lasts NONE not their client Client approver says yes on their side NONE never sees your workspace AUTHORIZES ITS OWN and reads its own records NONE a different company Auditor · read only reads, never runs RECORDS no execution path at all RECORDS WHERE MAPPED the same door, read only NONE not in scope AI agent a principal, not an exception AS COMMANDED never wider than its commander AS COMMANDED and it files its own request NONE same wall, same answer SCOPE IS IDENTITY × CUSTOMER — AN OPERATOR CAN HOLD MORE THAN ONE LIVE CONTEXT Switching context starts a new session. Work already running keeps running, and keeps accruing its own tracked time.
The row that matters is the last one. An agent is a principal with a role and a scope like any other, which is why "the AI did it" is never an answer here. It reaches what its commander reaches, and no further.

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 an operator sees holding two contexts
the boardSeparate lanes per client. An operation never drifts between them.
targetsOnly the machines in the context you are in. There is no global machine list.
credentialsOnly that tenant's vault references are selectable.
tracked timeAttributed to the client whose operation it belongs to, not to whoever you are looking at.
recordsWritten into the tenant that owns the work, always.

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.