Bun Protocol is pre-release. Every operation is stability: BETA, no commercial provider in the catalogue is verified, and the protocol is not yet deployable.

Tenants, membership, permissions and subscription

Routed from skills/SKILL.md. The authoritative operation list is api-reference.md.

What is served

bun.tenant.create, bun.tenant.current
bun.membership.invite, bun.membership.accept, bun.membership.revoke
bun.permission.check
bun.subscription.require_active

What is not served

Lines below are marked NOT-SERVED: — the guard test asserts each named operation is genuinely absent from the registry, so this list cannot go stale by quietly naming something that later gets implemented.

NOT-SERVED: bun.tenant.delete bun.tenant.list bun.tenant.update NOT-SERVED: bun.permission.grant bun.permission.revoke bun.permission.list NOT-SERVED: bun.membership.list bun.subscription.create bun.subscription.cancel

Permission assignment is not an operation. A sibling family having a verb is not evidence that this family has it.

Isolation is enforced below the operation layer

Tenant isolation is not an application-code check that an operation performs and could forget. It is PostgreSQL FORCE row-level security with policies, and it is exercised under a dedicated non-owner NOBYPASSRLS role — a superuser connection is refused at connect time. Four databases carry tenant-scoped tables (bun_backend, bun_connector, bun_workflow, bun_context), and every tenant-scoped table is enumerated from the PostgreSQL catalogue, so a newly added table cannot slip through unprotected.

Two consequences for anyone writing against this:

A write path that stores a NULL tenant_id breaks isolation even though the policy is correct. Cross-tenant tests here now assert both halves — the other tenant is denied and the owning tenant still succeeds. Ten tests once asserted only the first half, which a USING (false) policy passes while breaking the product for everyone.
SQLite is never evidence for any of this. A green test on SQLite says nothing about RLS.

Operations that declare requires_tenant: yes fail closed when tenant context cannot be derived. Consult the tenant column in api-reference.md rather than guessing — several families (deploy, credential, webhook) deliberately do not require it.

Same content for machines: tenants.md · llms.txt