◈ Security
Security
How Hyperdrive approaches security during the private alpha, and how to report a vulnerability. This is a high-level summary, not a compliance attestation — we do not claim SOC 2, ISO 27001, or similar certifications we do not hold.
Last updated 2026-07-30
Report a vulnerability
Email support@kaminocorp.com with [SECURITY] at the start of the subject — one inbox during the alpha, and the tag is what routes it. The button below does that for you.
Open a disclosure draft ↗Where to report
Email support@kaminocorp.com and start the subject line with [SECURITY] — during the private alpha we run a single monitored inbox, and that tag is what lifts a report out of general support triage. The button above opens a draft already tagged and structured. Please do not disclose publicly until we have had a reasonable chance to investigate and fix.
What we commit to
Private alpha, small team: we read every report. We aim to acknowledge within a few business days, tell you when a fix has shipped, and credit you if you want it. There is no formal SLA until general availability.
Scope
What is in and out of bounds for good-faith research against Hyperdrive:
- In scope: the Hyperdrive web application, the Hyperdrive API, and the workspace sandbox runtime once it is deployed.
- Out of scope: third-party infrastructure (report issues in Supabase, Fly.io, or Vercel to those providers directly).
- Out of scope: social engineering of Kamino or Hyperdrive staff, physical attacks, and denial-of-service or resource-exhaustion tests.
- Out of scope: automated scanner output with no demonstrated path to a real vulnerability.
Safe harbour
If you research Hyperdrive in good faith, stay within the scope above, and report findings privately without accessing other customers' data or going beyond what is needed to demonstrate an issue, we will not pursue legal action against you for that research. This is not a waiver of other rights, and it does not authorize testing of third-party systems or services we do not operate.
No bounty
We do not currently run a paid bug bounty. We still want the reports, and we will acknowledge researchers who ask for credit.
What we do on our side
Claims limited to what is true and checkable in the running platform today:
- Tenant data is isolated with database row-level security, and the application runtime uses a role that cannot bypass RLS.
- Each product area owns its own database schema; cross-tenant reads are denied at the policy layer, not only in application code.
- Secrets you give us (repository tokens, model-provider API keys) are encrypted at rest. If the encryption key is missing, secret operations fail closed rather than writing plaintext.
- Authenticated API calls validate JWTs (ES256). Session tokens for workspace sandboxes are scoped to a single workspace.
- Migrations and the application runtime use separate database roles with least privilege.
Subprocessors
Infrastructure and model processing we rely on today:
- Supabase — database and authentication.
- Fly.io — application hosting (API).
- Vercel — web application hosting.
- Anthropic — model provider for documentation, analysis, changelog and progress generation (unless you configure your own provider key).