Security built into the database, not added on top.

CSHUBB uses Supabase Auth and supports three sign-in methods: Google OAuth, email + password, and Magic Link (a one-click email link with no password required). All three are available on every plan. Passwords are never stored in plain text, Supabase Auth hashes them with bcrypt. Magic links are single-use and expire after a short window.

Supabase Auth verifies the token and issues a cryptographically signed JWT session stored in your browser. The JWT contains your email and org association only, never sensitive account data. Every API request validates this JWT server-side on every single call.

CSHUBB supports three sign-in methods: Google OAuth (Continue with Google), Password (email + password with Forgot Password flow), and Magic Link (one-click email link, no password needed). SSO via SAML/OIDC is on the roadmap for an Enterprise plan. Contact support@cshubb.com to discuss custom identity provider requirements.

Sessions are cryptographically signed JWTs with automatic expiry and refresh managed by Supabase Auth. CSHUBB does not use long-lived cookies that could be stolen via CSRF. Logging out invalidates the session server-side immediately.

Sessions refresh automatically and silently in the background, so you're not forced to re-authenticate constantly, but stale sessions still expire and forced re-auth is rate-limited to avoid disrupting normal use. Refresh tokens are protected by replay-attack detection, an industry-standard safeguard that flags and blocks reuse of a token that's already been redeemed.

Every workspace is scoped to a unique org_slug. Supabase Row-Level Security (RLS) policies are enforced at the PostgreSQL engine level, not in application code. Even an application-level bug cannot return another org's data. The database itself enforces isolation on every SELECT, INSERT, UPDATE, and DELETE.

RLS is a PostgreSQL feature that enforces data access policies at the storage layer, independent of the application. In CSHUBB, every authenticated JWT can only see rows where org_slug matches its own session. This is your last line of defence, it operates independently of application code and cannot be bypassed by software bugs.

All data is stored in Supabase (PostgreSQL) on AWS with AES-256 encryption at rest and TLS 1.2+ in transit via Cloudflare. Automatic backups and point-in-time recovery are provided by Supabase infrastructure.

CSHUBB has admin-level database access for maintenance purposes only. We do not actively monitor, read, or analyse individual workspace data. The service role key (which bypasses RLS) is stored exclusively in server-side Edge Functions and is never exposed to clients or logged.

New users require a valid invite code to join a workspace on first login. Invite codes are generated by workspace admins only. Without a valid code, first-time login is rejected, no self-service signup is possible. Admins can revoke codes instantly from Admin → Invite Codes.

No. Invite codes are never publicly listable: there is no endpoint that returns a list of active codes. Verification happens through a narrow, single-purpose check on one code at a time, which eliminates any path to harvesting or enumerating active invite codes by guessing or scanning.

Admin: full access: all modules, Admin panel, invite codes, user management, feature flags, org-wide AI key policy, webhook management, and bulk delete. The first user to create a workspace is automatically admin.

User (Member): access to plan-enabled modules only. Cannot access Admin panel, delete accounts, or manage invite codes.

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

Invite redemption and billing operations run through dedicated, narrowly-scoped server functions: not broad, reusable database credentials. Each function can do exactly one thing and nothing more, so a compromised credential or a bug in one operation can't cascade into unrelated capabilities.

No, by design. When a seat or account is removed, the action is logged and final: not a soft state that could be quietly reversed or repurposed. This keeps billing and access records auditable: that exact seat or account can't be silently reactivated. Bringing on a new person afterward goes through a fresh seat-assignment flow.

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. Subject to Groq's data processing terms.
• Claude: sent to Anthropic's API using your own key.
• Gemini: sent to Google AI Studio API using your own key, or via the hosted gateway if your workspace has switched that on.
• LM Studio: runs 100% on your local machine. No data ever leaves your device.

Individual mode: Keys stored only in browser localStorage, never sent to CSHUBB servers, never logged, never stored in the database.

Org-wide key mode: Admin-configured key stored in Supabase, encrypted at rest, scoped to your org, protected by RLS. CSHUBB never logs or reads your keys.

Hosted AI is an optional service where requests go through the CSHUBB gateway to Google Gemini instead of directly from your browser. It is off by default and can only be switched on per workspace by the owner.

When hosted AI is on, CSHUBB stores a daily request count for the workspace. It does not store your prompts or replies. LM Studio never uses the gateway, with LM Studio nothing leaves your device regardless of this setting.

Use LM Studio: available on the Growth plan and during the 7-day trial. Runs AI 100% on your local device, no internet connection required, no API key, no data leaves your machine under any circumstances. Zero external exposure.

When connecting Gmail for the Emails module, CSHUBB requests the minimum OAuth 2.0 scopes required to read your inbox and send email on your behalf. CSHUBB does not request access to Google Drive, Google Calendar beyond meeting sync, Contacts, Docs, or any other Google service.

You can review and revoke CSHUBB's access at any time from myaccount.google.com → Security → Third-party apps with account access.

No. Email content is fetched from Gmail at read time and held in your browser's memory for the current session only. CSHUBB does not copy, cache, or store the body of your emails on CSHUBB servers or in the CSHUBB database. Only metadata needed to link an email to an account (sender, recipient, subject, timestamp, account match) is stored.

Yes. CSHUBB's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. CSHUBB uses Google data only to provide and improve the in-product email feature, it is never used for advertising, profiling, or shared with third parties.

The Meetings module requests read/write access to Google Calendar to create, edit, and cancel calendar events on behalf of the signed-in user. CSHUBB creates real Google Calendar events with a Google Meet link when a meeting is booked. It does not read calendar events that were not created through CSHUBB, and does not access other calendars shared with the user.

Basic webhooks (Starter add-on / Growth included): HTTP POST with a unique secret token per endpoint. Pass in Authorization header to verify source.

HMAC-signed webhooks (Growth plan): Payloads signed with HMAC-SHA256. Signature included in X-CSHUBB-Signature header, verifiable by your receiving system to guarantee authenticity and detect tampering.

Webhook payloads contain account-level data only (name, CSM, tier, ARR, health score, status, custom fields). They never include user credentials, API keys, authentication tokens, or any sensitive system data.

Integration documentation for HubSpot, Freshdesk, Sprinto, and other connected tools shows the exact allowed values for every dropdown/picklist custom field, not just the field name. This removes the guesswork when mapping an external system's pipeline stage or status into CSHUBB's exact-match strings.

Yes. Outgoing webhook deliveries include an HMAC-SHA256 signature, so receiving endpoints can cryptographically verify the payload genuinely came from CSHUBB. Delivery is automatically retried on failure, and any custom field you've created is included in the payload automatically, no extra mapping required.

• Supabase: PostgreSQL with built-in RLS, real-time subscriptions, and Auth on AWS with automatic backups.
• Cloudflare: CDN, DDoS mitigation, TLS termination. HTTPS enforced on all traffic.
• Edge Functions: Privileged server-side operations. Service role key never exposed to clients.
• Resend: Email delivery via custom domain mail.cshubb.com with full SPF, DKIM, and DMARC.

No. The Supabase service role key (which bypasses RLS) is used exclusively in Edge Functions running server-side. The client-facing app uses only the Supabase anon key, which is fully subject to all RLS policies.

By default, all customer data is hosted on Supabase running on AWS infrastructure in ap-southeast-1 (Singapore), which is SOC 2 Type II certified with encryption enforced at rest and in transit. This is a performance/cost decision, not a security gap, region choice doesn't change the security posture.

EU data residency is available as a dedicated option for customers who require it contractually. Email security@cshubb.com to discuss.

No. Core rendering paths (like the account list) are wrapped in defensive error boundaries: a single unexpected error degrades gracefully with a clear message instead of blanking the screen. Automated background workflows, like playbook triggers, use concurrency locking to prevent duplicate records from overlapping processes racing each other.

CSHUBB runs a two-layer backup strategy:

• Platform-level backups: automated daily backups via Supabase, retention per plan tier.
• Independent, encrypted offsite backups: a weekly export of all production data, encrypted client-side (AES-256-GCM) before upload, stored in a separate, access-isolated Cloudflare R2 bucket entirely outside Supabase's infrastructure. This protects against platform-level incidents, not just accidental data loss.

Yes. Table coverage for the offsite backup is automatically discovered at runtime, any new data table is included in the very next scheduled backup with no manual configuration needed. The export is also pagination-safe, verified to capture full table contents regardless of size, so large tables are never silently truncated.

• SOC 2: access controls, audit logging, encryption at rest and in transit
• GDPR: data minimization, purpose limitation, right to erasure (user self-serve via Help & Feedback; org admins via Admin → Data & Privacy; all requests processed within 5 business days)
• ISO 27001: ISMS through RBAC, encryption, and multi-tenant isolation

Found a security issue? Email security@cshubb.com. We aim to respond within 48 hours. Please don't publicly disclose until we've had a chance to fix it, coordinated disclosure lets us protect users before details are public. Full policy at cshubb.com/security.

For users: Profile drawer → Account Actions → ⚠ Request Account Deletion, or Help & Feedback → Request Account Deletion.

For org admins: Full workspace erasure can be triggered directly from Admin Panel → Data & Privacy: no email required.

All erasure requests are processed within 5 business days. You can also email support@cshubb.com directly.

Request User Erasure removes a single departing team member's personal data and access, useful when someone leaves your org and you want their footprint cleaned up without disturbing the rest of the workspace.

Request Full Workspace Erasure permanently removes the entire org's data, accounts, activity logs, AI history, settings, everything, typically used when an organisation offboards from CSHUBB entirely.

Both are submitted from Admin → Data & Privacy, routed directly to the CSHUBB team, and processed within 5 business days under the same encryption and audit-trail guarantees as every other request.

Yes, every MCP tool is read-only, enforced at the database level. Claude can query your data but cannot create, update, or delete any record. The restriction is implemented as database-level RLS policies, not application-code logic, so it cannot be bypassed by a bug or misconfiguration.

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. This log is visible to workspace admins. You can revoke your own consent at any time from profile settings, and admins can force-disconnect any user or the entire workspace instantly.

No. The MCP server runs on CSHUBB infrastructure and returns data directly to the MCP client (Claude Desktop or compatible tool). CSHUBB does not send your workspace data to Anthropic. When Claude uses the data in a conversation, Anthropic's standard conversation privacy policy applies, the same as any Claude conversation.

Yes. Workspace admins can view the consent log (connected users, device, timestamp) and the tool call audit trail (which tools were called, when, by whom). They can revoke access for any individual user or disable AI client access for the entire workspace from Settings → Integrations.