Isolation guarantees and limits
The shared-tenancy composition provides logical confidentiality and integrity across the audited Cheetah data-plane components. It is not a complete hosted-service control plane. A production claim must separate what Cheetah scopes from what the host, product database, optional services, and operational environment still own.
What the audited boundary protects
With the dedicated shared constructor, accepted components, and correctly integrated hosts:
- WebSocket registration and heartbeat are scoped to the authenticated tenant and user;
- logical client presence and replacement remain inside that effective principal;
- command routing, delivery admission, acknowledgement fencing, and correlation cannot select another principal through message-body text;
- HTTP return derives its principal independently and prefixes stream suffixes server-side;
- history, notification, deduplication, context, and supported window-topology operations use tenant-aware keys;
- application command and history access begins from typed authenticated tenant proof rather than a caller-supplied combined identity;
- unknown or uncertified component implementations are rejected during composition.
Focused cross-tenant tests cover users with the same inner user ID under different tenants. The tenant portion of the effective principal keeps their clients, messages, and application access separate.
What it does not provide
The shared composition does not create tenant provisioning, subscription or billing logic, organization membership, per-tenant administrator roles, support-access policy, application- database row isolation, legal retention, or compliance deletion. It also does not make an external target—such as a browser account, website, filesystem, or SaaS API—tenant-aware.
Those boundaries belong to the product and its platform. A handler that receives a correctly scoped Cheetah command can still access the wrong product record if the application's own query omits its tenant condition. Cheetah routing isolation cannot repair that product-level mistake.
The current shared baseline also excludes active tracing, payload offload, central policy, the built-in parser registry, and Derived Views. Do not advertise a single shared-tenancy claim that silently includes one of those facilities. Either keep it outside the shared deployment or design, implement, and verify a tenant-aware replacement before use.
Availability is a separate concern
Tenant scoping does not guarantee equal capacity. Delivery admission has bounded reservations, including tenant-aware limits in shared mode, but the framework does not provide universal per-tenant CPU, Redis memory, connection, history, network, or external-service quotas. A noisy tenant can still affect shared availability unless the hosting platform adds resource controls.
Plan capacity and backpressure at the HTTP edge, WebSocket fleet, Redis, payload and product stores, client environments, and downstream systems. Where stronger availability isolation is required, use product quotas, separate worker pools, or separate deployments.
Administration and observability
Platform diagnostics may enumerate identities, pending commands, history, or topology across tenants. The platform administrator is therefore outside the tenant data-plane boundary. Use strong operator authentication, restricted network access, audit, and redaction. A no-op admin provider is not accepted by the shared constructor.
Because active tracing is excluded from the current baseline, shared-tenancy certification does not include exported traces or a dedicated tenant audit trail. Product audit records must be designed as their own immutable, tenant-scoped facility if they are required.
Retention, offboarding, and erasure
Revoking a credential or closing current sockets does not remove retained history, deduplication state, context records, application data, caches, backups, or telemetry already exported by surrounding services. History implementations expire data according to configured retention; there is no universal “purge tenant everywhere” operation.
An offboarding workflow should inventory each store keyed directly or indirectly by the principal, stop new authentication, close live routes, reconcile pending work, and apply the product's deletion and legal-retention policy. Test this workflow on the actual deployed stores, not only the in-memory development family.
Verification before a production claim
Test the complete host integration with at least two tenants, including the same inner user and logical client IDs in both. Cover:
- allowed and denied WebSocket authentication, including tenantless and malformed claims;
- independent HTTP authentication and rejection of a body-selected tenant;
- presence, command delivery, ACK, progress, result, history, and state reports in both scopes;
- reconnect, runtime replacement, stale return, timeout, and late result behavior;
- enumeration, cleanup, expiry, and diagnostic access for every enabled component;
- product-database and external-target authorization outside Cheetah;
- capacity pressure and operator access across tenants;
- offboarding and retention across all persistent services.
State the guarantee at the level demonstrated by that exercise. Passing the Cheetah component audit establishes an important data-plane boundary; it does not certify the surrounding application or infrastructure automatically.