Security

01Security posture

Findry is a small, opinionated product. The security posture reflects that: we don't over-engineer, but we don't cut corners on the things that matter. Your workspace content — hypotheses, bets, outcomes, and everything you write — is encrypted at rest and in transit, access-controlled at the row level, and never used to train models. This page describes how.

We are a pre-Series-A product. We won't pretend to have the security programme of a hundred-person company. What we do have: sensible defaults from day one, a hosted stack (Vercel + Supabase) that handles the heavy lifting, and a commitment to transparency about what we have and what we don't yet.

02Infrastructure

Hosting

The application runs on Vercel (compute) and Supabase (database, auth, storage). Both are SOC 2 Type II certified. We inherit their physical security, network isolation, and availability guarantees.

Regions

EU workspaces are stored and processed in the EU (Frankfurt). US workspaces default to us-east-1. You choose your region at workspace creation; it cannot be changed after the fact because data never moves cross-region.

Network

All inbound traffic is TLS-terminated at the edge. The database is not publicly reachable — the application server communicates with it over a private network via Supabase's connection pooler. No database port is exposed to the internet.

03Encryption

• In transit. TLS 1.3 minimum, enforced at the CDN layer. HTTP requests are redirected to HTTPS; HSTS is set with a one-year max-age.
• At rest.AES-256 via Supabase's managed encryption. Applies to all workspace content, integration tokens, and uploaded attachments.
• Backups. Supabase automated daily backups are encrypted with the same key material. Rolling 30-day retention. Deletion from production propagates to backups within 35 days.
• Integration tokens. OAuth tokens for connected tools (PostHog, Linear, Slack, etc.) are stored encrypted and never exposed in API responses. They are used server-side only.

04Authentication & access

Sign-in

Findry uses passwordless magic-link email and Google OAuth. There are no passwords to leak. Magic links expire after 15 minutes and are single-use.

Sessions

Sessions are stored in Supabase Auth, rotated on each use, and expire after 7 days of inactivity. Signing out from one device invalidates that session only; a “sign out everywhere” option revokes all sessions.

Row-level security

Every table in the Findry database has Supabase Row Level Security enabled. A query from workspace A cannot return rows belonging to workspace B at the database level — not just the application level. Multi-tenancy isolation is enforced in the data layer.

Internal access

Paulo (the sole employee) has read access to the database for debugging purposes. He does not have write access to production data outside of normal application flows. Direct database writes for support purposes require a logged reason. This policy will be formalised into a proper access-log requirement as the team grows.

Pulse share links

Pulse shares are protected by a hashed passcode embedded in the URL. The passcode is not stored in plaintext. Anyone with the link can view the share; there is no additional login. Treat Pulse share links like you would a shared Google Doc with link-based access.

05Application security

• Input sanitisation. All user content is sanitised before storage and escaped on render. We use parameterised queries throughout; there are no raw SQL string concatenations.
• CSP. A Content Security Policy header is set on all responses, blocking inline script injection and restricting third-party resource origins.
• CSRF. State-changing requests require authentication tokens that are not accessible to cross-origin pages.
• Dependency scanning. pnpm audit runs in CI on every pull request. High and critical advisories block the merge.
• Secrets management. All secrets live in Vercel environment variables, not in the repository. The repository is private. There are no hardcoded credentials anywhere in the codebase.

06Your evidence never trains a foundation model

Findry uses Anthropic's API for optional AI features — signal clustering, hypothesis drafting, and digest narratives. When content is sent to Anthropic's API, it is not used to train Anthropic's models. Anthropic's commercial API terms state that inputs and outputs submitted via the API are not used for training by default. Findry's API usage is configured with zero data retention, meaning content sent during inference is not stored by Anthropic beyond the duration of the request. The authoritative subprocessor entry is on the sub-processors page.

App-layer reinforcements

The guarantee holds at the application layer too. Every workspace-scoped entity in Findry carries a required workspace_id. All database queries are routed through scoped access controls — a query from workspace A cannot touch workspace B's evidence. AI features operate within this same per-workspace isolation: signal clustering sends only the signals belonging to the requesting workspace, and each workspace's AI token consumption is tracked and budgeted independently. No cross-workspace data mingles at any layer.

This is a structural advantage a horizontal AI chatbot cannot replicate: your evidence chain lives in an isolated, no-train workspace, and the isolation is enforced at the data layer — not just in policy.

07Monitoring & incidents

Error monitoring

Runtime errors are captured by Sentry with PII scrubbing enabled. Error events do not contain workspace content — only stack traces and anonymised context. Paulo is paged for severity P0/P1 events.

Availability

Uptime is monitored via Vercel's built-in checks plus an external synthetic monitor. A public status page is on the roadmap for post-launch.

Incident response

In the event of a confirmed breach or data exposure, affected workspaces will be notified within 72 hours — meeting the GDPR notification window. The notification will describe what was exposed, how, and what steps were taken. We will not send vague “we take your security seriously” notices.

08Compliance roadmap

• SOC 2 Type II. In scope for the Enterprise tier. We are collecting audit evidence from day one, targeting a formal audit in Q1 2027.
• GDPR. Implemented: data minimisation, lawful basis documentation, subject-access requests in-app, 72-hour breach window. Pending: Data Processing Agreement template for enterprise customers.
• CCPA. Implemented: no data sale, opt-out of telemetry, right to delete in-app.
• Penetration testing. External pen tests scheduled quarterly beginning Q3 2026 (first test at public launch).

If your organisation requires a specific compliance artefact that isn't listed here, write to security@findry.io. We'll tell you honestly whether we have it or when we expect to.

09Responsible disclosure

If you discover a security vulnerability in Findry, please report it to security@findry.io before disclosing it publicly. We will:

• Acknowledge your report within one business day.
• Confirm whether we can reproduce the issue within five business days.
• Keep you informed as we work on a fix.
• Credit you in the release notes if you'd like.

We do not currently operate a bug bounty programme. We will not take legal action against good-faith security researchers.

This security page is a working draft. It reflects our actual practices as of the date above. A reviewed version will ship before public launch.