[FRD] Hostile multi-tenant isolation primitives for OpenClaw

Status: Draft (ByteDesk-internal). Ready to file at openclaw/openclaw issues. Not yet filed. Author: ByteDesk Platform team (companion to ADR-0087 in bytedesk-platform). Reference: docs/gateway/operator-scopes.md — operator scopes are explicitly NOT hostile-tenant isolation.

Problem

docs/gateway/operator-scopes.md is clear: every scope-holder is trusted at operator level by construction. There is no gateway-level concept of a hostile tenant — a party reachable through the same gateway who must not be able to observe or affect another party's runs.

Downstream platforms that multiplex many customers onto a single OpenClaw gateway (ByteDesk among them) must therefore enforce hostile-tenant isolation entirely above the gateway. That works for ByteDesk because nothing but the ByteDesk Office adapter reaches the gateway — but it pushes a security-critical boundary into the downstream platform layer, and platforms that don't get it right would have a cross-tenant data leak with no upstream guardrail.

We are filing this FRD to scope an upstream hostile-tenant model so downstream boundaries become a hardening layer, not the only layer.

Requested upstream primitives

1. Tenant claim on session / run / approval

A first-class tenantId (opaque string) attached to each session, run, approval grant, and emitted event. Gateway-internal stores key on it. Sessions / runs created under tenant X cannot be observed or mutated by a caller authenticated as tenant Y.

2. Tenant-scoped operator scopes

Today an operator scope is global. We propose an additional scope axis: each scope can be global (today's behavior) or tenant-scoped (only valid for runs whose tenantId matches the scope's tenant). An approval signed by a tenant-scoped role validates only against runs of that tenant.

3. Tenant-aware audit

Audit events get a tenantId attribute. Cross-tenant operations that bypass the boundary (e.g. operator overrides) are logged with both the caller's effective tenant and the target tenant, so audit trails are intelligible after the fact.

4. Fail-closed defaults

When a request hits the gateway without a tenantId claim, the gateway rejects it. Today's API surface remains backwards-compatible by treating unmarked sessions as a single default tenant; only when tenancy is enabled on a gateway does the fail-closed rule activate.

Out of scope for this FRD

• DB-per-tenant — that's a downstream data-layer concern, not a gateway concern.
• Resource quota per tenant — separate FRD if needed.
• Federation (see the companion cross-gateway federation FRD). Tenancy and federation compose but are independent surfaces.

Downstream mitigation we're shipping in parallel

ByteDesk is shipping a path-B Office-side boundary now (see ADR-0087 in bytedesk-platform). The Office API layer validates tenantId(claim) == tenantId(run) on every workflow API hit before forwarding to OpenClaw. This protects ByteDesk customers regardless of upstream timing.

When upstream lands the primitives above, ByteDesk would migrate to a hybrid model: Office still validates at the API layer (defense in depth), and the gateway enforces the same boundary at the gateway layer (defense in depth from the other side). The migration is additive — no breaking change for downstream consumers.

Asked of upstream

• Confirm appetite for hostile-tenant isolation as an explicit goal, separate from operator scopes.
• If yes: scope the four primitives above into discrete sub-issues.
• If no: state that explicitly so downstream platforms can plan around a permanent "boundary above gateway" model.

Companion ByteDesk artifacts

• ADR-0087 — bytedesk-platform path-B decision.
• docs/research/workflow-multi-tenant-isolation-status.md — research log.
• docs/research/workflow-multi-tenant-implementation-plan.md — Office-side implementation plan.