# Vulnerability disclosure policy If you have found a security issue in Acquainto, we want to hear about it. **Contact: security@acquainto.com** This policy is what `/.well-known/security.txt` points at ([RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html)). Both are served by the API, unauthenticated: - Machine-readable: - This page: The published copy is rendered from this file, so the two cannot disagree. A few references below are to internal documents we do not publish; if one is material to a report you are writing, ask at the address above and we will send the relevant part. ## Who reads this `security@acquainto.com` is a mail alias on `acquainto.com` that forwards to Acquainto's founder, who reads it personally. It is not a shared mailbox and there is no rota. That is a deliberate choice at our size: a separate security mailbox with no owner is the thing that stops being opened by month three, which is the exact failure this policy exists to prevent. Delivery was verified end to end on **2026-09-09** — a message sent to the address was opened and acted on 34 seconds later (ELI-366). Three things follow from that, stated rather than implied: - **Mail arrives and a human reads it.** Not a ticket queue, not an auto-responder. - **There is one monitor and no backup.** The realistic failure mode is that one person being unavailable, not delivery. If you have no acknowledgement after three business days, assume nobody saw it and escalate through any other channel you have for us. - **There is no overnight on-call.** A report filed at 02:00 is read in the morning. The commitments below are in business days for that reason. ## What we commit to - **Acknowledge within 3 business days.** If you do not hear back, assume the mail did not arrive and escalate through any other channel you have. - **Triage within 10 business days**, with an initial severity assessment and an expected fix window. - **Tell you when it is fixed**, and credit you if you want credit. - **We will not pursue legal action** against anyone who follows this policy in good faith. We do not currently run a paid bug bounty. We are a small team and would rather say that plainly than imply a reward that does not exist. ## Scope **In scope** - The Acquainto API, served at `acquainto-api-production.up.railway.app`. `api.acquainto.com` has no DNS record yet, so there is nothing there to test (ELI-454) - The admin application - The embeddable widget bundle and the hosted eflow page - This repository **Out of scope** - Findings against our subprocessors' own infrastructure — report those to Railway, Supabase, OpenRouter, or Google directly. See SUBPROCESSORS.md - Volumetric denial of service, and any test that degrades service for real respondents - Social engineering of our team or our customers - Missing hardening headers or TLS configuration with no demonstrated impact - Automated scanner output with no working proof of concept ## Please do - Give us enough to reproduce: request, response, and the steps in between - Use your own test tenant. If you can reach another tenant's data, **stop at proof of access** — do not enumerate, download, or retain it - Report immediately if you access respondent data by accident, and delete your copy ## Known and already accepted These are documented positions, not findings. Reporting them will get a pointer back to this section: - **Tenant isolation is enforced in application code**, not by row-level security. This is a deliberate, recorded choice — docs/tenant-isolation.md. A concrete query path that actually crosses tenants is very much in scope; the architecture itself is not. - **We do not pin the upstream model provider** that OpenRouter routes to. Documented in SUBPROCESSORS.md. - **Completion emails contain full response content** by design, sent to addresses the tenant configures. ## Maintaining this This file is the single source of the published policy: the API renders from it at runtime, so editing this file changes what a researcher reads. Links to internal documents and tickets are stripped from the published copy — see `packages/api/src/lib/security-policy.ts`. `security.txt` carries an `Expires` field that RFC 9116 caps at one year. `packages/api/src/__tests__/security-txt.test.ts` fails 30 days before that date so the refresh happens as a red-test fix. When it goes red, confirm the mailbox above is still monitored **before** pushing the date — a valid expiry on an unread inbox is the failure this whole file exists to prevent. Re-read "Who reads this" at the same time: it names one person, so it goes stale the day that person changes. If we ever miss the acknowledgement or triage window above, the fix is to change the number here, not to leave a promise standing that we do not keep.