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.
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 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.
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
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.
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.