For a firm's own security plan: what is true today, area by area, and where to check it.
What this is. A security fit sheet: the answers a firm's own security plan or a client's questionnaire asks for, one per area, each stated as it is today and each naming where it can be checked. Last verified against the system on 28 September 2026. Copy it; it is written to be copied.
| Area | Askhive today | Where to check |
|---|---|---|
| Hosting and location | The database, file storage and server functions run on Supabase in United States (AWS us-east-1, Northern Virginia); the web pages and the API gateway run on Vercel in the United States. | share-web/legal/facts.ts REGION; supabase/config.toml; share-web/vercel.json verified 28 September 2026 |
| Encryption in transit | Every connection to askhive.app, r.askhive.app and the API is HTTPS; the site's own domain enforces it and the API refuses plain HTTP. | Vercel's TLS on every domain; supabase/functions/* are reachable only over https verified 28 September 2026 |
| Encryption at rest | Data at rest is encrypted by the hosting provider (AWS, through Supabase). Askhive holds no separate key management of its own and does not claim to. | Supabase platform documentation; nothing in this repository encrypts columns itself verified 28 September 2026 |
| Access control | Every table is protected by row-level security; a firm's seats can read only their own firm's rows, and nothing in the public schema is readable by a client without an explicit policy. | supabase/migrations (RLS on every table); verify/ledger-privacy.mjs asserts every grant and view, nightly verified 28 September 2026 |
| Roles | Five seat roles — owner, admin, professional, reviewer, assistant — with one capability matrix enforced on the server; the assistant never approves, and money is the owner's alone. | supabase/functions/_shared/roles.ts; verify/users-roles.mjs verified 28 September 2026 |
| Two-step sign-in | Authenticator-app two-step sign-in is available to every account; a firm's owner can require it of every seat; every Askhive staff session requires it. | workspaces.two_step_required; supabase/functions/console/index.ts (aal2 on every call); verify/console.mjs verified 28 September 2026 |
| Model provider | Reports are drafted by Anthropic's models over the API; Practice briefs are redacted before they leave (identifiers replaced by tokens and restored afterwards); nothing sent is used to train a model. | supabase/functions/_shared/redaction.ts; the sub-processor list; Anthropic's commercial terms verified 28 September 2026 |
| Secrets | The model key, the payment keys and the mail key live only in the server functions' secret store; the app bundle carries a publishable key that grants nothing on its own. | CLAUDE.md non-negotiable 4; scripts/scan-secrets.sh in CI verified 28 September 2026 |
| Audit trail | Every admin action in a firm and every Askhive staff action is written to an audit table kept for seven years; every approval records who approved and how many facts they verified. | public.workspace_audit, public.staff_audit (retention_policy 7 years); public.events draft_approved verified 28 September 2026 |
| Support access | Askhive staff cannot see a firm's report titles or statuses unless the firm's owner or admin opens a seven-day window from Settings; every look inside it is recorded and shown to the firm. | workspaces.support_access_until; verify/console.mjs; verify/clicks.mjs presses the card verified 28 September 2026 |
| Backups | The DATABASE is backed up daily by the provider — the provider's backups do not include the files in Storage, which are copied nightly into a second bucket on the same project and kept thirty days (from 3 Oct 2026); a restore drill that restores beside production and puts one row back by id is in the repository. Point-in-time recovery is not enabled, so the accepted worst case is up to 24 hours of loss. | verify/restore-drill.sh; runbooks/restore.md verified 28 September 2026 |
| Retention and deletion | Retention periods are rules in a table enforced daily by a scheduled job since 14 September 2026; a person's account deletion deletes the records rather than hiding them; a firm's data is deleted when the firm deletes it. A file is removed from the live store the moment it is deleted. Askhive also keeps its own nightly copy of every file — the provider's database backups hold the records of files, not the files — so a deleted file can still exist in that copy for up to 30 days, until the copy's own retention rule removes it. The copy is a private bucket: no client and no signed-in person can read it, and only a restore run by Askhive can reach it. | public.retention_policy (including the storage_copies rule); verify/retention.mjs; public.delete_account; verify/storage-copies.mjs verified 28 September 2026 |
| Monitoring | Uptime and the engine's health are measured every minute from outside Askhive's own servers, and a failure emails the founder; the status page shows the same measurement. | share-web/api/monitor.ts; askhive.app/status verified 28 September 2026 |
| Vulnerability reports | A security.txt names where to report a vulnerability and a person reads it. | share-web/api/security-txt.ts; askhive.app/.well-known/security.txt verified 28 September 2026 |
| Payments | Practice billing is handled by Stripe; card numbers never reach Askhive. | supabase/functions/stripe-billing; the sub-processor list verified 28 September 2026 |
A questionnaire will ask. These are the honest answers, so a firm knows before it signs rather than after:
When any of these changes, this page changes the same day, because it is generated from the one file that records what is true.