Overview
Ask2Do is a chat assistant that reads (and, on explicit approval, writes) the customer's own operational database. The threat model we care about most is the one a vendor-security reviewer asks first: where does our data live, and who can see it? The short answer is that read results and writes flow through the sidecar that the customer chooses — either a binary the customer runs themselves, or a cloud-hosted process we run on their behalf — and the durable audit record lives in a table on the customer's own database, in both modes.
Deployment modes
The choice between modes is the single biggest lever determining where your DB credentials live. Both modes are first-class; both ship the same audit log and the same write-approval flow.
Self-hosted sidecar
A small Go binary that the customer runs on their own infrastructure (a VPS, a container, a sidecar pod, an on-prem box — wherever their database is reachable). The binary holds the DSN. Our cloud orchestrator never sees the DSN and never sees raw rows from the database. The cloud's view is limited to the question the user asked, the SQL the model proposed, and the small typed tool-call payloads needed to route a reply.
Cloud-hosted sidecar
For teams without a host to run a binary (typical Supabase / Neon / RDS / serverless setups), we run the sidecar against the customer's DSN. The DSN is encrypted at rest with NaCl secretbox using a 32-byte key held in the cloud environment. The key is rotatable without re-asking the customer for the DSN. Plaintext DSN exists only in process memory while a connection is active — never on disk, never in operational logs, never in backups. See cloud-hosted sidecar docs for the operational detail.
Audit log
The durable audit record of every approved write is written to the ask2do_audit table in the customer's own database, hash-chained per tenant. The chain links each entry to the previous one so a tampered or deleted row breaks the chain and is detectable on review.
This holds in cloud-hosted mode too: even when we host the sidecar, the audit table is created on the customer's DB and the record of what happened stays on infrastructure the customer owns. If the customer walks away from Ask2Do, the audit history is still theirs.
Authentication and roles
Every WebSocket message between the widget and our cloud carries a short-lived JWT minted by the cloud's /auth/token endpoint. The customer's backend mints this JWT from their long-term tenant key — the tenant key never reaches the browser. The JWT carries a signed role claim. The cloud enforces the role on every message; the widget bundle in the browser cannot escalate beyond the role that was baked into its token at issue time.
Tenant keys are stored as argon2id hashes (m=64MB, t=3, p=4). The raw key is shown to the customer once, at issue time, and never lands on disk again.
Write approval flow
Read-only queries that the SQL parser accepts as SELECT-only auto-run and stream their results back to the chat. Any statement that mutates state — INSERT, UPDATE, and the narrow set of DDL we permit — pauses on a preview card in the widget. The preview card shows the generated SQL and the bound parameters. An admin clicks Approve before the statement ever reaches the database.
DELETE, DROP, TRUNCATE, and ALTER are rejected at the parser, not by policy. The approval card cannot be used to run them.
What we never store or log
Operational logs across the cloud orchestrator and the sidecar are intentionally narrow. They include the tenant id, the query type (e.g. SELECT, INSERT), latency, and outcome (success / parser-reject / approval-pending / error). They do not include:
- The raw DSN, in any form.
- Query result rows or individual column values.
- The bound parameter values for a query (we record the shape, not the contents).
- The customer's admin-panel user passwords, session cookies, or files.
Conversation transcripts retained on our cloud (the user's questions and the AI's answers) are deleted after 90 days. See the Privacy Policy for the full retention schedule.
Subprocessors
We use a small set of carefully chosen sub-processors — EU hosting, CDN / edge, AI model inference, payment processing, and transactional email. The subprocessor list enumerates each one, its role, and the data it sees. Customers are notified at least 30 days before a new sub-processor is added.
Vulnerability disclosure
Report security issues to security@ask2do.com. We follow a 90-day coordinated disclosure policy: we acknowledge reports within two business days, keep the reporter informed of progress, and aim to ship a fix before public disclosure. We don't pursue good-faith security researchers who follow this policy.
For confirmed personal-data breaches we notify affected customers within 72 hours of becoming aware, per our Privacy Policy.
Compliance status
We'd rather be straight about where we are than claim a certification we haven't earned. Current status:
- SOC 2 Type II — on the roadmap. Not yet audited.
- ISO 27001 — not pursued at this stage.
- HIPAA — Ask2Do is not designed for Protected Health Information and we do not sign BAAs.
- GDPR — platform data lives in the EU. Our standard Data Processing Agreement is available on request for B2B customers.
Contact
Security reports: security@ask2do.com
Vendor-review questionnaires & DPA: enterprise@ask2do.com
General support: hello@ask2do.com
Engineering detail on the architecture lives in the security model doc and the audit log schema.