One store, no shared reads

Tenant isolation

The owner key is a hash of the caller's key. Every query filters on it. There is no cross-tenant code path.

How the owner is derived

The platform gateway forwards the caller's X-API-Key. The service computes owner = sha256(key)[:32] inside the request context; the raw key is never stored. In the public free preview there is no customer key, so the visitor identity is a hash supplied in X-CAIN-Visitor (or derived from the client address), and it plays exactly the same role.

What isolation means here

• Every row carries owner in its primary key.
• Every read, search, delete, release, count and audit filters on owner. There is no method that takes a memory id without an owner.
• The hash chain is per-owner, and owner is inside the hash input, so entries cannot be spliced across tenants.
• Invariants A33-01 and A33-02 test cross-tenant read and cross-tenant search on every run.

What isolation does not give you

Tenants share one SQLite file. A party with filesystem access sees every tenant's rows. Isolation here is a logical and API property, not encryption at rest and not separate databases. For physical separation you run one AETHER-33 instance per tenant with its own data directory — which is supported, because the store is a single file path.