SECURITY
Where the guardrails are.
Last updated September 4, 2026 · applies to the preview release
1. Accounts and sign-in
Authentication is handled by Supabase Auth. We never see or store your password in plain text — Supabase stores a securely hashed value on our behalf. Signing in sets a session cookie scoped to our domain; traffic between your browser and our servers is encrypted in transit.
2. Data storage and access
Your content lives in a Postgres database. Every table has row-level security switched on, and application tables are reachable only from our server using a privileged key — never a key exposed to the browser. The realtime layer that carries live cursors, presence and collaboration state has its own row-level security policies, which check that your account actually has access to a canvas before letting it join that canvas's channel.
3. Personal access tokens
Tokens that let an AI client act as you over the MCP endpoint are shown once, at creation. We store only a one-way SHA-256 hash of the token, never the token itself, so a database compromise wouldn't reveal a usable token. Revoke a token any time from the profile panel — it stops working immediately.
4. Share links and presentations
Public share links and live presentation links are long, unguessable random tokens, not sequential ids — a valid link can't be found by trying nearby values. Revoking a share link or ending a presentation kills access immediately.
5. Health probes
A health probe you configure runs from our servers, not your browser: we send a plain request with a short timeout to the URL you gave us and record whether it answered. The URL and its response are never exposed to another visitor's browser. Probes only go to public addresses: anything that resolves to a private, loopback, link-local or cloud-metadata range is refused, the connection is pinned to the address that was checked, redirects are not followed, and each account has a probe budget.
6. Version history
Every save keeps a version, so you or a collaborator can review or restore an earlier state of a canvas.
7. Backups
Database backups are handled by Supabase, our database provider — we don't run a separate backup process of our own.
8. No tracking scripts
We don't run third-party analytics, advertising or session-recording scripts on C4Stage. See the privacy policy for the cookies and local storage we do use.
9. Reporting a security issue
If you believe you've found a security issue, please report it privately rather than filing a public issue — reach the team through your workspace administrator or the channel that came with your invitation, with enough detail for us to reproduce it. We'll acknowledge genuine reports, and won't take action against anyone who reports one in good faith and gives us a reasonable chance to fix it before disclosing it publicly.