> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Run Compute for your own customers
description: >-
  Separate each of your customers into its own tenant, delegate administration safely, and
  keep result reads inside one tenant. Test the separation with two tenants before you
  onboard anyone.
route: /docs/compute/configure/platform-subaccounts
page_id: docs-compute-configure-platform-subaccounts
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Platforms and agencies running Compute on behalf of their own customers
voice: D
reader_question: How do I run Compute on behalf of my own customers without leaking data between them?
primary_action: Test two tenants in the sandbox
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-configure-platform-subaccounts-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

You need an organization, an administrator, and a clear answer to one question: who is the customer of record for each tenant.

Decide that before you create anything. It determines who receives the invoice, who approves spend, and who may read a result.

## Give each customer its own tenant

Model each of your customers as its own subaccount. One subaccount holds that customer's keys, sources, destinations, ceilings and cost allocation.

Do not share one subaccount across two of your customers and separate them by a label in the input. A label is a convention. A subaccount is the boundary Compute enforces.

## Cross-tenant result reads are never a default

A key issued in one tenant reads results in that tenant only. There is no default that lets one tenant read another's output, and you should not build one by reusing a key.

If your own operations team needs a view across tenants, do it with your platform's administration credential, not with a customer's work key.

Work submission and administration stay separate. A work key carries work scopes only, and management scopes are never mintable on it.

## Delegate administration deliberately

Decide per tenant whether your customer administers it, you administer it, or both.

1. Plan the membership and the role for each administrator.
2. Apply, then read back the membership before you tell anyone it is ready.
3. Record which side may change the ceiling, because two parties raising a limit is how budgets get lost.

An invitation you send is not undone by a configuration rollback. Removing a member is its own forward action, and the audit record keeps both events.

## Test with two tenants before you onboard

Open the sandbox and create two tenants in it. Do this before a real customer exists.

1. Create tenant A and tenant B with separate keys and separate ceilings.
2. Run one small job in tenant A.
3. Try to read that result with tenant B's key, and confirm the read is refused.
4. Confirm tenant B's usage shows nothing from tenant A's run.
5. Reset the sandbox when the check is done.

Step three is the whole test. A separation you have not tried to break is a separation you have not tested.

## Confirm success

Each tenant reads back as `VERIFIED`, holds its own ceiling, and reports usage separately.

Your refusal check produced an actual refusal with a reason and a next action, not an empty result that merely looked safe.

## When a tenant refuses a change

`REFUSED` names why, and the next action tells you what to change. `CONFLICT` means the tenant moved since your plan, so inspect and replan.

Verified tenants stay verified when a later one refuses. Resume the change rather than rebuilding every tenant.

[Test two tenants in the sandbox](/docs/compute/sandbox/reset-and-isolation)