Security
Isolated tenant data stores, AES-256-GCM encrypted secrets, scoped credentials, and auditable operations. This page distinguishes implemented controls from provider settings and operational work that still requires verification.
Current as of July 14, 2026. Security changes over time; request current evidence before relying on a control for a regulated or high-risk workload.
The eight pillars
Isolated tenant data stores
Newly provisioned tenants store Tables and records in a logically separate Turso database. Legacy layouts can reuse an authorized tenant database, and Turso is shared managed infrastructure at the provider level. A separate system database stores account, routing, usage, and audit metadata. Every request is still authenticated and scoped; database separation is defense in depth, not a claim that bugs are impossible.
AES-256-GCM encryption at rest for secrets
Source request headers and webhook secrets, API account auth headers, environment variables, and per-tenant database tokens are AES-256-GCM encrypted in storage. The encryption key is configured as a Cloudflare Worker secret and is not committed to source; launch checks and logging policy are designed to prevent secret output.
Distributed rate limiting
Plan-tier request limits are coordinated through a Cloudflare Durable Object. Usage limits are enforced separately from request-rate limits. Published plan limits are product controls, not a guarantee against every abuse pattern.
Security and activity audit records
Key lifecycle actions, MCP tool calls, authentication failures, and selected account and workspace events produce audit records with actor, action, target, time, and available request context. Coverage is expanded as new operations are added.
Verified browser and API authentication
Browser sessions use Supabase. Current asymmetric tokens are verified against Supabase JWKS, including signature, issuer, audience, subject, and expiry checks. Workspace API keys are hashed at rest and can be scoped and revoked.
Authenticated realtime connections
Realtime connections are authenticated and authorized before joining a Table or workspace room. Clients must reconnect after credential or authorization changes; Hypertab does not publish an instant-revocation SLA for an already-open connection.
No user-deployed JavaScript
Hypertab does not expose a user-deployed Functions product. Formula columns use the application formula engine; network work is performed by configured HTTP or integration columns under product controls.
Browser security headers
The app and marketing origins set HSTS, CSP, frame denial, content-type protection, referrer policy, permissions policy, and cross-origin policy headers such as COOP and CORP. The app CSP permits only the API, Supabase authentication, and configured error-reporting connections it needs.
Current assurance status
- SOC 2 / ISO 27001
- Not certified
- Independent penetration test
- Not completed
- Data-subject requests
- Handled by verified email request
- DPA / security questionnaire
- Review current availability with us
- HIPAA BAA
- Not available; do not store PHI
Reporting a vulnerability
Email [email protected] with reproducible details and the minimum data needed. Response timing is not guaranteed; public launch requires this inbox and an accountable incident owner to be monitored. Coordinate disclosure and avoid accessing data that is not yours. Hypertab does not currently operate a guaranteed paid bug-bounty program.
Acknowledgments
No public researcher acknowledgments are listed yet. With the reporter's permission, validated coordinated disclosures may be credited here.
FAQ
- Is Hypertab SOC 2 compliant? +
- No. Hypertab has not completed a SOC 2, ISO 27001, HIPAA, or independent penetration-test certification. Do not treat this page as an audit report. Contact [email protected] for the current control summary and verified evidence available at that time.
- Where is data hosted? +
- Table and record data is stored in Turso. Edge compute and file/queue services use Cloudflare. Browser authentication uses Supabase. When you configure an HTTP column, the selected external API receives the inputs needed for that request under its own terms. Ask us before signup if you require a specific residency commitment.
- Who can access my data? +
- Public-beta workspaces are single-user and do not provide teammate access. The service operator retains the technical access needed to provision databases, investigate incidents, restore service, and answer an authorized support request. Operator access should be minimized and recorded; we do not promise that every provider-side access produces a Hypertab alert.
- How do I rotate or revoke API keys? +
- Open workspace Settings → API Keys and revoke the key, then issue a replacement where needed. New authenticated requests reject the revoked key after cache invalidation. Disconnect and reconnect long-lived clients during rotation; no five-second global revocation SLA is offered.
- What happens if there is a breach? +
- We investigate, contain, preserve evidence, and notify affected customers and regulators when applicable law requires it. The audience and timing depend on the incident and legal obligations. Credentials are revoked or rotated when the investigation shows that action is required; this is not an automatic guarantee for every incident.
- Can I delete my data? +
- Yes. The current account-closure path is a verified request to [email protected]; self-service account deletion is not yet available in Settings. We confirm the scope and identity of the requester, then remove active workspace data and expire retained backups according to the published retention policy. We do not currently issue automated deletion certificates.