Security

1. What this document is

Every claim below describes the system as it runs today. Where a practice also appears in our legal documents, this page links there rather than restating the commitment, so there is exactly one place where each promise is made. If this page and a linked document ever disagree, tell us: the linked document governs, and the discrepancy gets fixed the same day.

The short version, for the reader who has thirty seconds: secrets are stripped in the browser before any request is made, everything is encrypted in transit and at rest, workspace data is isolated by deny-by-default database policy, conversations are never used to train models, and we hold no certifications so we claim none.

2. Where the service runs

The application is hosted on Vercel’s platform and edge network. The primary database and storage run on Supabase, in a single configured region. Dashboard authentication runs on Clerk. All three are named in our subprocessor register alongside what each one touches.

We deliberately do not operate servers of our own. Fewer things running means fewer things patched, monitored and explained, and it puts physical and infrastructure security in the hands of teams who do it at greater scale than we could.

3. Encryption

• In transit: TLS 1.3 for traffic between your browser or SDK and the service.
• Between our services: TLS for connections between application components and to third-party providers.
• At rest: AES-256 encryption of stored data, provided by our database and storage providers.

4. Redaction before storage

The strongest control in the product happens before data is ours to protect. The browser SDK scrubs obvious secrets, passwords and patterns that look like payment cards out of error payloads in the page itself, so no request carrying them is ever sent. The server then redacts again on ingest, independently of the SDK, because we do not assume the client did its job.

An end user’s email address reaches us only if they decide to hand it to the recovery agent during a conversation. The agent asks; it does not read contact details off forms.

What this means practically: an error report pasted in by a developer with a token still in it arrives already masked, and the masked form is what is stored and what any model sees.

5. Access control

5.1 Your team

Dashboard access runs through Clerk with passwordless sign-in and expiring session tokens. Team seats are scoped to your workspace, and removing a seat removes the access.

5.2 Our team

Internal access to production data follows least privilege: people have the access their work requires and nothing broader. There is no standing habit of browsing customer data, and the circumstances in which we would look inside your workspace are described in the privacy policy.

6. Isolation between customers

Project data is isolated per workspace at the database layer. Access policies are deny by default: a query must be explicitly permitted to see a workspace’s rows, rather than permitted globally and told to filter. The isolation boundary is enforced where the data lives, not only in application code, so a bug in one code path does not become a leak across customers.

7. The AI agent

The recovery agent is powered by a third-party language model. When a conversation happens, the error context and the conversation messages are sent to the model provider to generate replies; the details of what is and is not sent are set out in privacy policy section 6.

Two commitments matter most here, and both live in the privacy policy in full: your conversations are never used to train models, ours or anyone else’s, and the agent operates within fixed instructions about what it may say and ask for.

8. Retention and deletion

Conversation and incident data is retained on short windows by plan, currently seven days on the free plan, ninety on Pro and 365 on Scale, after which it is deleted. You can request access to your data or its deletion at any time under privacy policy section 12. The full retention table, including categories that fall outside these windows, is in section 8.

9. Incident response

If data we hold is exposed, we will notify affected customers within 72 hours of confirming the breach, with what happened, what data was involved, and what we have done about it. That commitment is stated in privacy policy section 10, and it is timed to fit inside the regulatory clocks many of our customers are themselves bound by.

Because the service runs entirely on managed platforms, the incidents we handle directly are application-level ones. Provider-side failures follow each provider’s own incident process, and where a provider notifies us of anything that touches your data, the 72-hour clock starts when they do.

10. Vulnerability disclosure

Good-faith security research is welcome. If you find a vulnerability, write to hello@cluebase.dev with enough detail to reproduce it. We will acknowledge receipt, investigate, and keep you informed through to a fix. We will not pursue legal action over good-faith research that respects the rules below.

• report to us first; give us a reasonable window to fix before any public disclosure;
• use test accounts and your own workspaces, never another customer’s data;
• no denial-of-service testing, spam, or social engineering of our team or users.

Automated scanning aimed at endpoints you do not have an account with is prohibited under section 5 of the acceptable use policy; coordinated testing against your own workspace is not what that rule is for.

11. Certifications and compliance

We hold no security certifications and claim none. There is no SOC 2 badge on this page because no auditor has issued us one, and we think a page that implies otherwise is lying by typography. When that changes, this section will change with it.

On privacy regimes: the service is built to be GDPR and CCPA ready, meaning the tooling a customer needs exists: data processing terms in the terms, a published subprocessor register, retention limits, export and deletion on request, and breach notification. We are careful to say ready rather than compliant, because compliance is something a controller achieves in its own use of a tool, not something a tool can be.

12. Contact

Security questions, review questionnaires, and reports all go to hello@cluebase.dev. A person who worked on the system answers, not a form.