Data confidentiality

Only the customer can read or manage their data. This table is the same one our engineers work from.

Threat	Control
Another customer reads my data	Namespace per instance, default-deny NetworkPolicy, per-instance credentials, the gateway routes only to the owning Service, a volume per instance and a backup prefix per instance with prefix-scoped credentials. Cross-tenant access is tested in CI with a hostile-neighbour suite.
Another org manages my instance via the API	Every handler resolves the resource through the caller’s org, never by bare id. Ids are ULIDs but are never treated as secrets. The role matrix is tested exhaustively: viewer cannot see credentials, developer cannot delete, billing sees no instances.
Databasezy staff read my data	The operator and provisioner have no pods/exec and no volume read path. Staff kubeconfigs do not exist outside break-glass, which needs a ticket and a second approver, is time-boxed and session-recorded, and notifies you. Support tooling shows metadata only. Statement logging is off by default.
Staff need to look at my database to help me	Support access grant: you create a grant in the portal (scope metadata, read-only query or full; duration 1 to 72 hours). It issues a temporary credential to the named staff member, is logged, revocable and expires by itself. Without a grant, no path exists.
Credentials leak through your systems	Generated inside the cell by the operator; the control plane stores only a secret reference. Reveal is a one-time, signed, short-lived fetch straight from the cell. Rotation has a dual-valid window. API keys are hashed with argon2id.
Data at rest exposed by a disk or bucket leak	Per-tier KMS keys for volumes and backups. Per-org customer-managed key on secure placement, or a customer-held key via a KMS grant we cannot use without your key policy.
Data in transit observed	TLS 1.2+/1.3 at the gateway, re-encrypted to the pod with a per-cell private CA. Optional mTLS.
My data lingers after I delete it	Delete keeps data for the plan’s retention window (shown up front), then purges volumes, backups and secrets. Full erasure purges immediately, including the last backup, and writes an erasure certificate to the audit log.
My data is used by you	Never. No analytics on customer data; metering sees bytes and sizes only. Written into the Terms and the BAA.

Creating a support access grant

shell

zb api POST /v1/orgs/{org}/support-grants -d '{
  "staff_id": "[email protected]", "instance_id": "pg-prod", "scope": "read_only",
  "duration_hours": 4, "reason": "ticket ZB-1234"
}'
zb api GET /v1/orgs/{org}/support-grants
zb api DELETE /v1/orgs/{org}/support-grants/grt_01J9...

The grant, every query run under it (on read_only and full scopes) and its expiry are in your audit log.