Trust & Privacy

No training on your data, ever

Your transcripts, artifacts, Vault content, and writing samples are never used to train models — ours or anyone else's. The model providers we use are configured so that your content is not used for their training either (see Subprocessors below).

UK/EU data residency

Your data is stored in the UK/EU. Our database (Neon Postgres) is pinned to the eu-west-2 (London) region, and the application runs on Vercel. The region is fixed at creation rather than migrated later.

Client-side redaction before anything is sent

Redaction runs in your browser. When it is on, customer names and other PII are removed from a transcript before it ever leaves your machine — even files you “upload” are read locally and never sent as files. What the server stores is the text as submitted: the redacted version when redaction is on.

Redaction is a real, labelled control with a review step, and each call honestly records whether it was redacted before sending. If you turn it off, we tell you plainly that the raw transcript will leave your browser and be stored unredacted.

The boundary is client-trusted. For pasted and uploaded transcripts the redaction runs entirely on your device and we store exactly what your browser submits — we never receive the raw text to re-check it. The raw transcript lives only in your browser’s memory; the single thing sent to us is the final (redacted-when-on) text. That means the guarantee is enforced by the client, by design, not re-verified on our servers.

Connected sources are different. When you connect Gmail or Calendar, the provider sends that content to our server, which redacts it server-side before it is stored or processed. So the “raw never leaves your device” guarantee applies to paste and upload; for connected sources the raw content transits our server in memory for the redaction pass and only the redacted text is kept.

What each processor sees

The only third party that receives transcript content is Anthropic, which generates and reviews your artifacts. When the Answer Vault is enabled, chunks of Vault content are also sent to Scaleway's EU-sovereign Generative APIs to compute embeddings. Both are configured for no-training and zero/short data retention. Content sent to these processors is post-redaction.

Adding any new third party that receives your content is treated as a security review, not a routine change.

The public RFP demo: what is kept

/rfp answers a security questionnaire with no signup and no account. The spreadsheet is parsed in your browser and never uploaded. When you ask for answers, the question texts and the text extracted from your source document are sent to us, used for that one request, and dropped when it ends — no database row ever holds what you send. What is kept instead, none of it your content:

• A rate-limit counter. Keyed to a SHA-256 hash of your IP address joined to the UTC date — not the address itself, and a different key on a different date, so two days’ rows cannot be lined up against each other. The window is hourly, so one visitor can produce up to 24 rows in a day. A row is that hash, the action name, the hour it covers, a count, and when it was last written. A daily job deletes rows old enough that they can no longer affect a decision.
• A shared daily token total. One row per calendar day for the whole demo, under a fixed id — __public_rfp__ — that every visitor shares. It is what caps the demo’s spend for the day. Because it is shared, it says nothing about any one visitor.
• A run summary from our server. When a run finishes we send one analytics event, rfp_answers_shown, carrying six fields: how many questions were asked, how many were answered, how many came back as flagged gaps, how many failed, whether the daily budget had been reached, and how many source documents there were. It is recorded against the same shared __public_rfp__ id, so it is not attributed to you.
• Browser analytics, under an id for your browser. This is the one that is about you rather than about the run. PostHog’s browser SDK runs on every page of this site, /rfp included, and gives your browser a persistent random id it keeps between visits. A page view is recorded when you open the page. Six funnel events can follow, in two groups sent at different moments and under different rules. Four are sent by /rfp itself: rfp_uploaded, rfp_analyzed, rfp_source_added and rfp_signup_started. Those four are held in the tab and sent only once you press the button that drafts the answers, so if you drop a file and leave, they are never sent at all; the page view is not held back, because arriving on a page is not the same as dropping a file on it. The other two are sent later, and only if you sign up: rfp_claimed when the run left in this browser is brought into your new account, and rfp_claim_failed when that attempt does not work. Those two fire inside the signed-in app rather than on /rfp, at the moment the attempt finishes, and neither is held back by anything — by then you have chosen to create an account, and the no-network promise that holds the first four is not in force there. By that point your browser id has also been linked to your account. All six carry counts, timings, byte sizes and the questionnaire’s file format; the two claim events also carry how many documents, questions and answers were carried across, which attempt it was, and whether that attempt succeeded, was refused outright, or was given up on. Never a question, a filename, or a line of a document.

While /rfp is on screen we switch off the capture surfaces that fire on a click or a DOM change: autocapture, rageclicks, dead clicks, heatmaps, web-vitals, session recording, and exception capture. The page’s promise is that dropping a questionnaire causes no network request at all, and a beacon carrying no content would still break it. The page view is the deliberate exception, and this is the page that says so.

Analytics is sent to /ingest on this domain, which is a reverse proxy to PostHog’s EU cloud. A network tab therefore shows our domain rather than theirs, which is why it is written down here.

Hard delete — no soft-delete

When you delete your account, your data is hard-deleted. Deleting your user record cascades through every deal, call, artifact, version, Vault item, embedding, and questionnaire you own — there are no soft-delete flags hiding your content after the fact. You can do this yourself from your Account page. It is immediate and irreversible.

Transcript content is never logged

We log metadata only — identifiers, durations, token counts, and sanitized error messages. Transcript or artifact content is never written to logs, error messages, analytics events, or URLs.

Security posture

• UK/EU data residency (Neon eu-west-2, London).
• Authentication and session management via Clerk.
• Client-side PII redaction before content leaves the browser, on by default.
• AI calls are bounded server-side: timeouts, retries, token budgets, and per-user daily spend caps.
• Metadata-only logging; content never logged.
• Hard deletes, enforced at the database layer.

We do not currently hold SOC 2 or ISO 27001 certification. Formal certification is on our roadmap; we will only claim it here once it is actually in place.

Subprocessors

The third parties that process your data on our behalf:

• Anthropic — AI generation and review of artifacts. Receives transcript content (post-redaction). No training on your data.
• Scaleway (EU-sovereign) — Vault embeddings, only when the Answer Vault is enabled. Receives Vault content (post-redaction). No training; zero/short retention.
• Neon — Postgres database hosting (eu-west-2, London). Stores your content at rest in-region.
• Vercel — application hosting.
• Clerk — authentication and identity.