Kindred
Back to Trust

Security at Kindred

A platform that asks you to trust its analysis must earn that trust through how it handles your data. This page tells you, honestly, what is live in the product today and what we are still building. We do not claim controls we do not have.

Live today

What is in place now.

Each item below is implemented in the codebase and verifiable against the source. For the technical detail behind each control, see the public architecture page linked at the bottom of this page.

  • Authenticated by default

    Every request to the backend carries a Supabase-issued JWT and is signature-verified against the project's JWKS (ES256). Admin endpoints additionally require an admin role claim. There is no anonymous path to user data.

  • Row-level security in the database

    Every Supabase table that holds user data enables row-level security with explicit policies tied to auth.uid(). User A cannot read, update, or delete User B's analyses, tags, links, preferences, or feedback. This is enforced by Postgres, not by application code.

  • Encryption in transit and at rest

    All traffic uses HTTPS; HSTS is enabled for one year with subdomain coverage. Supabase encrypts the underlying database volumes at rest. There is no plain-text data path between the browser and the database.

  • AI provider key isolation

    The Anthropic API key lives only in the backend runtime. The frontend has no path to call Claude directly and no environment variable exposes the key to the browser bundle.

  • Input sanitization on the analysis path

    Every analysis query is stripped of ASCII control characters, length-bounded, and (for URL inputs) format-validated before it reaches the AI engine or the database.

  • Per-user rate limiting on analyses

    The analysis endpoint is bounded with a per-user sliding window. The limit protects both the platform and other users from abuse and cost runaway.

  • True hard delete on request

    Account deletion from Settings is a real hard delete, scoped strictly to your account. There is no soft flag, no tombstone, no shadow copy.

  • Secrets stay out of version control

    The repository's .gitignore excludes every .env variant by default and permits only .env.example. The Anthropic API key and the Supabase service-role key live only in production secret stores.

  • Hardening headers and locked CORS

    The frontend ships strict security headers (Content-Security-Policy, X-Frame-Options DENY, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, HSTS). The backend's CORS allow list is restricted to known origins, with no wildcards.

On our roadmap

What we are building next.

These items are not in place today. We present them as planned because that is what they are. We will move them out of this section when they are real.

  • SOC 2 Type II readiness

    No audit has been performed. The architecture is designed to support a SOC 2 audit when the company is ready to engage one. We will say so plainly when an engagement begins.

  • Third-party penetration testing

    No third-party penetration test has been performed yet. Planned before public launch and at least annually thereafter.

  • Automated dependency and secrets scanning in CI

    We rely on a strict gitignore and human review today. Dependabot or Snyk for dependency scanning, and gitleaks or equivalent for secrets scanning, are planned for the next security hardening sub-phase.

  • Production observability hardening

    Structured logs and trace ids are in place, but there is no error tracking, uptime monitoring, or alerting in production yet. Sentry (or equivalent), an uptime monitor, and log aggregation with alerting are planned.

AI-specific security

AI introduces unique risks.

An AI-powered platform introduces concerns that traditional applications do not face. Each item below is implemented today.

  • Prompt injection defense

    User inputs are sanitized and length-bounded before reaching the AI engine. Phase prompts are versioned files; the user query is bound to a labeled slot rather than concatenated into the system prompt.

  • Output validation

    Each phase's structured output is parsed and shape-checked before being persisted or returned. Malformed phase output is surfaced as a phase error rather than silently passing through.

  • API key isolation

    The Anthropic API key never reaches the frontend. All AI calls route through the backend. The key is read at startup from the backend's secret store.

  • Cost visibility

    Token counts and per-call cost are recorded on every phase output and every audit-trail row. A hard spending cutoff is on the roadmap; cost is visible to operators today, not auto-enforced.

Application & infrastructure

Built defensively.

Application security

  • Input validation and sanitization on the analysis path
  • Per-user rate limiting on the analysis endpoint
  • Authorization required on every state-changing endpoint
  • Content Security Policy, HSTS, X-Frame-Options, Referrer-Policy, and Permissions-Policy headers configured
  • CORS locked to known origins only
  • Authenticated state-changing requests carry a bearer token rather than cookies, limiting CSRF surface

Infrastructure

  • Frontend hosted on Vercel with DDoS protection, CDN, and edge caching
  • Backend runs as a managed service with no public SSH access
  • Database (Supabase Postgres) with network access controlled at the platform layer
  • Environment separation between local development and production with distinct credentials
  • Backups managed by Supabase per the subscribed plan
Privacy principles

Your data, on your terms.

  • Data minimization

    We collect only what is needed to provide the service. Analysis inputs and outputs are stored for your benefit. We do not collect browsing behavior or sell data to third parties.

  • Designed for GDPR and CCPA

    The platform is designed to support the strictest applicable data protection regulations, including GDPR and CCPA. We have not been audited for compliance; the design choices (hard delete, data minimization, no behavioral tracking) reflect those regimes from the start.

We do not use third-party analytics services that track individual user behavior or leak personally identifiable information. The same show-the-work principle that governs every analysis governs how we handle your data.

Incident response

If something goes wrong.

Kindred maintains an internal incident response plan covering detection, containment, assessment, notification, recovery, and post-incident review. If a security incident affects user data, we will notify affected users without undue delay, explain what happened and what data was involved, and act in accordance with applicable breach notification laws, including GDPR's 72-hour regulator notification requirement and the applicable US state breach notification obligations. The full plan is internal and is shared with paying customers on request. You can review your data and delete your account at any time from Settings.

Security questions

Common security questions.

How does Kindred handle my analysis data?
Your analysis queries, phase outputs, tags, links, and feedback are stored in your personal library inside our Supabase Postgres database. Postgres encrypts the underlying volumes at rest. Row-level security ensures only you can read or modify your own rows. Your content is used exclusively to deliver the service to you. We do not share your analysis content with third parties.
Is my data used to train AI models?
No. Your analysis inputs and outputs are not used to train or fine-tune AI models without your explicit, informed, opt-in consent. This is a foundational commitment, not a feature that can be quietly changed.
Can I delete all my data, and how does that work?
Yes. Open Settings, scroll to "Delete Account" at the bottom of the page, type DELETE in the confirmation input, and click the destructive button. The backend then runs a true hard delete: your preferences, tags, analyses (with their phase outputs and links), and AI audit log entries are removed, and your Supabase auth user is deleted. The delete is scoped strictly to your account, so no other user is affected. The flow lives at /settings on a signed-in account.
Where is my data stored?
Your data is stored in a Supabase-managed Postgres database with encryption at rest and in transit. The frontend is hosted on Vercel. The Anthropic API key, which is required for AI calls, is held only in the backend runtime environment.
How does Kindred protect against prompt injection?
User inputs are sanitized and length-bounded before being passed to the AI engine. Phase prompts are versioned files, and the user query is bound to a labeled slot in each phase prompt rather than concatenated into the system prompt. AI output is parsed and shape-checked before persistence.
What happens if there is a security incident?
Kindred maintains an internal incident response plan that defines categories, severity levels, containment, assessment, recovery, and notification procedures. If a security incident affects user data, we will notify affected users without undue delay, explain what happened and what data was involved, and act in accordance with applicable breach notification laws (including GDPR's 72-hour regulator notification requirement and applicable US state breach notification obligations). The full plan is internal and is shared with paying customers on request.
Who has access to my data?
Your data is protected by row-level security at the database level. Only you can access your analyses, preferences, and account data through authenticated requests. Administrative access uses a separate service-role credential held only by the backend; it is used for operational tasks like writing audit logs, running admin dashboards, and processing account deletions. It is not used to browse user content.
Has Kindred completed a SOC 2 audit or a penetration test?
No. Neither has been performed yet. We will say so plainly until they have been. The architecture is designed to support both when the company is ready to engage them; until that work happens, we will not imply otherwise.