Cancel Cultr — Access Control Policy
1. Purpose & Scope
This policy governs how access to Cancel Cultr's production systems and sensitive data is granted, controlled, authenticated, and removed. It applies to all production assets (all cloud/serverless — there are no physical or on-premise assets): the API (Cloudflare Workers), the database (Supabase / PostgreSQL), third-party processor consoles (Plaid, Twilio, Anthropic), and source control.
2. Guiding Principles
- Least privilege: identities receive only the access required to perform their function.
- Deny by default: access to data is denied unless explicitly granted.
- Need to know: access to sensitive data (bank tokens, transactions, PII) is restricted to the components that require it.
3. Access to Production Systems
- Administrative and deployment access is limited to the sole operator's individual accounts for Cloudflare, Supabase, and Plaid.
- Multi-factor authentication (MFA) is required on all of these administrative accounts.
- Production runs in a dedicated Cloudflare account isolated from unrelated projects.
- Deployment requires authenticated CLI access tied to the production account; there is no shared or password-only administrative access.
4. Access to Sensitive Data (Role-Based, Deny-by-Default)
- Role-Based Access Control (RBAC) is enforced at the data layer through PostgreSQL roles: the anon and authenticated client roles versus the privileged service_role.
- Row-Level Security is enabled on every table with zero access policies, so the client roles cannot read or write any record directly. This makes data access deny-by-default by construction.
- All data access flows through the API using the service_role credential, which is held server-side only and never exposed to client applications.
- Plaid access tokens are stored server-side and are unreachable from any client.
- End users can access only their own records: every request is authenticated and scoped to the authenticated user's ID. Client apps hold no direct database connection.
5. Authentication
- Human access: individual accounts protected by MFA (see §3).
- End-user access: Supabase-issued JWTs (bearer tokens), verified on every API request.
- Non-human / service authentication: service-to-service access uses signed token credentials (the service-role JWT and provider API keys) transmitted over TLS — not shared passwords. Internal job endpoints require a timing-safe shared secret.
6. Secrets Management
- Secrets (service-role key, Plaid secret, provider API keys) are stored in Cloudflare's encrypted secret store and in git-ignored local environment files.
- Secrets are never committed to source control; this is verified before every push.
- Secrets are rotated on any suspected exposure and on operator credential changes.
7. Provisioning & De-Provisioning
Cancel Cultr is currently operated by a single individual, so standing access is limited to one identity. Any future personnel will be granted least-privilege, role-based access with MFA required, and their access will be removed promptly upon role change or departure.
8. Access Reviews
The operator will review account access, active credentials, and third-party integrations on a quarterly basis and upon any material change, revoking access that is no longer required.
9. Revocation & Deletion
Account deletion revokes all Plaid items (removing our access to bank data) and cascades a full deletion of the user's data. Data is retained only while an account is active.
10. Scope Statement
Cancel Cultr is a single-operator, early-stage business. This policy documents access controls that are genuinely implemented and procedures the operator commits to following. It does not claim controls not yet in place (for example, centralized SSO/IAM tooling, a formal zero-trust architecture, or automated employee de-provisioning), which are not applicable at current scale and will be adopted as the business grows.