Tenant isolation

How the hosted platform separates what different wallets can see and edit — a layer strictly on top of, never a substitute for, covenant authority.

On a hosted multi-user PolicyVault deployment, tenancy is the layer that decides which wallet may see or edit which hosted object — a question that is entirely separate from, and strictly less powerful than, covenant authority.

#Three independent layers, never conflated

1. Hosted authentication — "which wallet is this session?" A challenge/response proof using the wallet's own signature.
2. Hosted tenancy authorization — "may this wallet see or edit this hosted object?" Enforced only when hosted authentication is enabled; with it disabled (the self-hosted single-operator product) every check simply allows, because there is only one trusted operator.
3. Kaspa covenant authority — "did the right wallet sign the exact transaction?" This layer is completely unaffected by the other two. A hosted session never implies covenant authority, and neither does any organization role.

#Vault access derives from the covenant, not from a separate database column

A vault's participants — owner, agents, approvers — are exactly the wallets the covenant itself already binds. There is no separate hosted "ownership" record that could disagree with the covenant, and hosted vault visibility cannot be widened by editing application metadata: it exactly tracks on-chain participation.

#Default deny, and existence hidden on denial

Tenant identity is authoritative by public key — a human-readable display name never grants access. An ambiguous rule denies. A request for an object outside the caller's tenancy comes back as an ordinary "not found" rather than "forbidden," specifically so a denial never confirms that some other tenant's object exists.

#Organization metadata is not a tenancy bypass

Organization roles and vault-to-organization assignments (see Owner/agent/approver authority boundaries) are themselves tenant-scoped application metadata in hosted mode — one tenant's routes can never read or mutate another tenant's organization records — but, as with every other use of organization metadata, none of it ever grants Kaspa covenant authority regardless of tenancy.

#What a tenancy bug can and cannot do

A defect in the tenancy layer is a real, serious bug class — it can expose or hide hosted-application data (like which vaults a wallet can see) incorrectly. It cannot, by itself, grant covenant spending authority, because tenancy is not consulted anywhere in the covenant signature-verification path. A real example of this bug class, and its honest resolution, is documented in Approval not visible: a hosted-tenancy defect briefly prevented an external approver's own wallet from seeing its own vault and pending request — a fail-closed availability defect with no funds, authority, or cross-tenant exposure, fixed and regression-tested.

See also: What the hosted server can and cannot do, Owner/agent/approver authority boundaries.