How CSHUBB protects your data, layer by layer.

CSHUBB uses Supabase Auth with three sign-in methods: Google OAuth, email and password, and Magic Link (a one-time link sent by email). Passwords are never stored in plain text, they are bcrypt-hashed. Magic links are single-use and expire after a short window.

Supabase Auth verifies you and issues a signed JWT session, stored securely in your browser and used for every API call. The JWT contains your email and org association, never sensitive account data. Every API request validates it on the server.

CSHUBB supports Google OAuth, email and password, and Magic Link. SSO through SAML or OIDC is on the roadmap for an Enterprise plan. Email support@cshubb.com to discuss custom identity provider requirements.

Sessions are signed JWTs with automatic expiry and refresh managed by Supabase Auth, and logging out invalidates the session on the server. CSHUBB does not use long-lived cookies that could be stolen through CSRF.

Every workspace is scoped to an org_slug, a unique identifier provisioned at workspace creation. All database tables are partitioned by it.

Supabase Row-Level Security (RLS) policies are enforced at the database engine level. Every SELECT, INSERT, UPDATE and DELETE is filtered to the authenticated user's org, so a query from one workspace cannot return data from another.

Row-Level Security is a PostgreSQL feature that enforces access policies at the storage layer. Even if an application bug left out a filter or passed a wrong parameter, the database would still return zero rows from another org. RLS works independently of application code and is your last line of defence.

All persistent data is stored in Supabase (PostgreSQL) on AWS. Supabase provides AES-256 encryption at rest and TLS 1.2+ for all connections in transit.

New users need a valid invite code to join a workspace on first login. Codes are generated and distributed by workspace admins. Without one, first-time login is rejected, so no self-service signup is possible. Codes are never publicly listable and admins can revoke them instantly.

Admin has full access: all modules, the Admin panel, invite codes, user management, feature flag overrides, the org-wide AI key policy, webhook management, billing and bulk delete.

User (Member) has access to plan-enabled modules. A member cannot open the Admin panel, delete accounts or manage invite codes.

Role changes, user blocking and user removal are enforced in the database and are limited to workspace admins. New accounts get their role and workspace on the server, from an invite or an approved email domain.

Admins revoke access from Admin, Users. Revoked users see a blocked screen on their next login. The is_suspended flag is set in the database and RLS policies deny all further data access, even with a valid JWT.

By default each email address belongs to a single workspace. An admin can enable the allow_multi_org flag for consultants or users who legitimately need more than one.

By default, AI requests go straight from your browser to the provider you chose, using your own key. They do not pass through CSHUBB servers.

• Groq: sent to Groq's API, under Groq's data processing terms.
• Claude: sent to Anthropic's API with your own key.
• Gemini: sent to Google AI Studio with your own key, or through the hosted gateway if your workspace has switched that on.
• LM Studio: runs 100% on your machine. No data leaves your device.

Individual mode: keys live only in your browser's localStorage. They are never sent to CSHUBB servers, never logged and never stored in the database.

Org-wide key mode: the admin-configured key is stored in Supabase, encrypted at rest, scoped by org_slug and protected by RLS. CSHUBB never logs or reads your keys.

Hosted AI is optional. Requests go through the CSHUBB gateway to Google Gemini instead of directly from your browser. It is off by default and only the workspace owner can switch it on.

When it is on, CSHUBB stores a daily request count for the workspace, not your prompts or replies. LM Studio never uses the gateway.

Use LM Studio, available on the Growth plan and during the trial. It runs on your device with no internet connection and no API key, and no data leaves your machine.

Yes. Every MCP tool is read-only, enforced at the database level. Claude can query your data but cannot create, update or delete a record. The restriction is a set of database RLS policies, not application logic, so a bug or misconfiguration cannot turn it into write access.

Before any data is returned through an MCP tool call, CSHUBB records a timestamped consent entry: who connected, from which device, and which tools were authorised. Admins can see this log. You can revoke your own consent from profile settings, and admins can force-disconnect any user or the whole workspace.

Yes. Admins can view the consent log and the tool call audit trail (which tools were called, when and by whom), and can revoke access for any user or switch AI client access off for the workspace from Settings, Integrations.

CSHUBB does not send your workspace data to Anthropic. The MCP server runs on CSHUBB infrastructure and returns data directly to the MCP client. When Claude uses that data in a conversation, Anthropic's standard conversation privacy policy applies.

Basic webhooks use HTTP POST with a unique secret token per endpoint. Pass the token in the Authorization header to verify the source.

HMAC-signed webhooks (Growth plan) sign payloads with HMAC-SHA256. The signature is in the X-CSHUBB-Signature header, so your receiving system can verify authenticity and detect tampering.

Account-level data only: name, CSM, tier, ARR, health score, status and custom fields. Payloads never include user credentials, API keys, authentication tokens or other sensitive system data.

CSHUBB keeps audit logs, available to org admins, covering:

• User logins and session starts
• Account create, edit, bulk edit and delete operations
• AI tool runs (tool name, provider, timestamp, user)
• Admin actions: invite codes, role changes, feature flags
• Webhook creation, updates and deletions
• Account deletion requests

• Supabase: PostgreSQL with built-in RLS, real-time subscriptions and Auth, hosted on AWS with automatic backups and point-in-time recovery.
• Cloudflare: CDN, DDoS mitigation and TLS termination, with HTTPS enforced on all traffic.
• Edge Functions: server-side operations. The service role key is never exposed to clients.
• Resend: email delivery from mail.cshubb.com with full SPF, DKIM and DMARC.

No. The Supabase service role key, which bypasses RLS, is used only in Edge Functions running server-side. The client app uses only the anon key, which is subject to every RLS policy, and privileged operations validate the caller's JWT first.

Two layers: automated daily backups through Supabase, and an independent weekly export encrypted in the client with AES-256-GCM and stored in a separate Cloudflare R2 bucket outside Supabase. New tables are included automatically.

By default data is hosted on Supabase on AWS in ap-southeast-1 (Singapore), which is SOC 2 Type II certified. EU data residency is available as a dedicated option. Email security@cshubb.com to discuss.

• SOC 2: access controls, audit logging, encryption at rest and in transit
• GDPR: data minimisation, purpose limitation, right to deletion (account deletion flow built in)
• ISO 27001: ISMS through RBAC, encryption and multi-tenant isolation

Infrastructure providers (Supabase, Cloudflare) maintain their own certifications. CSHUBB is in active private beta and governance capabilities keep evolving with customer feedback.

Email security@cshubb.com. We aim to respond within 48 hours. Please do not disclose the issue publicly until we have had a chance to fix it, so we can protect users before details are public.