| Owner | Jonny Allum (Security Lead) |
| Version | 1.0 · Effective 13/07/2026 · Review annually (July) |
| Applies to | Product roles inside BizOS, and operational access to infrastructure |
1. Product access model (what the platform enforces)
BizOS roles are fixed and enforced at page, action and database level:
| Role | Reach |
|---|---|
| Owner | Everything in their workspace: user management, settings, Section Builder, billing |
| Member | All enabled modules in their workspace |
| Contractor / Tenant / Client | Portal-only: their own jobs and compliance docs / maintenance requests / published reports — nothing else |
Rules:
- Tenants manage their own users (C02); JonnyAI never adds users to a tenant workspace except during agreed onboarding (SOP-01) or a logged support action (SOP-07).
- Every role check has a database-level twin (RLS). UI gating alone is never sufficient — a route without matching RLS is a defect.
- AI actions execute under the calling user's tenant binding with a mandatory confirm step; plan caps meter AI actions per tenant (POL-05).
2. Operational access (who can touch the machinery)
| System | Access | Standard |
|---|---|---|
| GCP VM | SSH, key-based only, operator's key | No password auth; static IP; Caddy terminates TLS |
| Supabase | Dashboard (MFA) + service-role key | Service key lives only in VM env + password manager |
| GitHub | jonnyallum (MFA) | Clean remotes — no tokens embedded in URLs |
| Stripe / Resend / Anthropic / registrar | Dashboard (MFA) | Restricted API keys where the provider supports them |
- Admin/service-role paths in the app (
adminSupabase client, seed routes, cron routes) must be unreachable from the public internet without a secret: cron endpoints requireBIZOS_CRON_SECRET; seed/admin routes are removed or guarded before go-live of any new deployment. - Joiners/leavers (future): access is granted per-system with the least role that works, recorded in a simple access register (a row per grant: who, what, why, when revoked). Revocation on the day collaboration ends, and always ahead of any disputed departure.
3. Reviews
Quarterly (or after any incident): review Supabase dashboard members, GitHub collaborators and deploy keys, Stripe team, VM authorized_keys, and API keys across providers. Anything unrecognised is revoked first and investigated second (SOP-05). Key rotation cadence lives in SOP-09.