Security & data handling

Your documents, the results we produce, and the audit records of who reviewed them are yours. We process them only to run the workflows you ask us to run — we do not use your data to train models, we do not pass it to a provider who will, and we do not sell or share it.

Each account's work runs in its own isolated context. Access is scoped per account and enforced by PostgreSQL row-level security — the database refuses cross-account rows, rather than every query having to remember to filter for them.

Data is encrypted in transit (TLS) and at rest. Stored credentials are encrypted with per-account keys derived from a master key; API keys are stored hashed, never in plaintext.

We agree retention windows with you and delete run artifacts — replays, screenshots, extracted data — on that schedule, including on request. Tell us your requirement and we'll put it in writing.

Files you upload are kept as well as the text taken out of them, so that marks can be written back into your own document and so a file can be re-read if our parsing improves. Those source files are deleted automatically thirty days after upload by default, and immediately when you delete the document. The deadline is fixed per file when it arrives, so a later change to our policy never shortens a window you were already given.

Internal access to customer data is restricted to what operating the service requires. Account activity is written to an append-only audit log — who ran what, when, and what came back. Update and delete are revoked on that table, so it cannot be quietly rewritten, including by us.

• Sign-in — Google sign-in, email + password, and scoped API keys. Directory-federated SSO (SAML, SCIM provisioning) is on the roadmap.
• SOC 2 Type II — Not certified. The controls above are documented and open to your review; there is no report to send you yet, and we will not imply otherwise.
• ISO 27001 — Not certified.
• GDPR / UK GDPR — A legal obligation rather than a certificate, and one we are subject to. Nobody issues a GDPR badge; what you can actually hold us to is the data processing agreement below.
• Data processing agreement — available on request and reviewed with your legal team before rollout.

We would rather you read this than find out later. Our control documentation is available for your review now, and we will say so here on the day an audit is actually complete — not when one is scheduled.

Every provider that touches your data, named — all 5 of them. Everything that stores your data is US-region; the one global entry hosts front-end code and holds none of it. If that changes, this list changes with it.

• Anthropic — The language model used for extraction and drafting. It never receives your stored credentials. (United States)
• Railway — Application and worker compute, and the job queue. (United States (US East))
• Supabase — Managed PostgreSQL — accounts, runs, reports, the audit log. (United States (AWS us-east-2))
• Cloudflare — Object storage for exports and run artifacts, and inbound email routing. (United States)
• Vercel — Hosting for this site and the product front end. No customer data is stored here. (Global edge)

Primary-source data — SEC filings, sanctions lists, the Companies House register — is read directly from the issuing authority, not through an aggregator. That is a security property as well as an accuracy one: there is no intermediary holding a copy of what you looked up.

Screening is a workflow about people, so being vague here would be evasive. All of it, including the category vendors usually leave out:

• Your users — Name, email, and the audit trail of what they ran.
  Needed to operate the account you are paying for.
• Screening subjects — The name and identifiers you submit, plus whatever the public lists return against them — including sanctions and adverse-media records naming individuals.
  Processed on your instruction, from published official sources, to answer the screening question you asked.
• Third parties in public registers — A UK company screen can return persons with significant control, which for an individual PSC is a named person's data.
  Public register, reused under Open Government Licence v3.0, and cited to the register in the report itself.

We are a processor for the first two: you decide who gets screened and why, and we run it. Subject-access and erasure requests reaching us are routed to you as the controller, and we will help you answer them.