Security overview — written to be forwarded
Built so your IT team says yes.
The short version, for the business reader DataAssist-IO lets your team ask questions of your company data from Claude, ChatGPT, or any MCP client. Your data arrives one of three ways — you send it to us, we read your storage, or we query your warehouse or database directly — and it can read, never write. Anything you send us is stored encrypted in your organization's isolated workspace. Anything we read from your systems is read in place — read-only, never copied. Every question is logged for your admins. The rest of this page shows exactly how — no badges, no hand-waving. Forward it as-is to whoever needs to approve it.
How your data is handled
Three ways in, three honest promises
Data you send us is stored — encrypted, in your organization's isolated workspace. Your own storage and your warehouse or database are never copied — read in place, read-only. We never blur those claims into one.
Architecture
Every question passes a gate before it touches your data
This is the whole path, end to end. Every SQL statement is parsed and validated before execution — single SELECT-only statements, nothing else. Writes are rejected at the gate; they never reach your data.
Belt and braces: connect with a read-only database login you create, and the gate becomes your second line of defense, not your only one.
The blunt version
What we do. What we never do.
Screenshot this table for the approval thread — every line is a property of how the product is built.
What we do
- ✓Validate every query before it runs — SELECT-only; anything else is rejected at the gate.
- ✓Encrypt your connection credentials at rest (authenticated encryption), and use TLS with certificate checks by default for new connections.
- ✓Log every question — who asked, what they asked, and when — visible to your admins.
- ✓Isolate every organization, hard — storage, metadata, and credentials are scoped to your org, and deleting a table deletes its stored data.
- ✓Scope tables per team when you want it — each team sees exactly the tables you grant, nothing more.
What we never do
- ✗Never copy what we connect to — your cloud storage and your warehouse or database are read in place, every time.
- ✗Never take write access — read-only by construction, from the validation gate down to a read-only session at the engine itself, where supported.
- ✗Never train AI models on your data — it is used only to answer your organization's own questions.
- ✗Never share or sell your data — to anyone, for any reason.
- ✗Never claim a certification we don't hold — see the honest note further down.
Access control
Who can see what — and who decides
Access is enforced on the server for every request — the same rules apply whether someone asks from Claude, ChatGPT, or the app itself.
Two roles, clean split
Admins connect sources, choose which tables to expose, and manage people. Viewers ask questions. Role checks run server-side on every call.
Team-scoped tables
Put a viewer in a team and they see only the tables that team is granted — in their AI client and in the app. Sales sees sales data; finance sees finance data.
Email verification first
Nobody signs in until their address is verified — including users an admin adds by hand. An unverified account can't reach any data.
Login lockout
Five wrong passwords lock the account for 15 minutes — and emailed one-time sign-in codes are attempt-capped and rate-limited too. Brute force doesn't get a run-up.
AI clients connect through standard OAuth — each person signs in as themselves, tokens expire and rotate, and disabling a user cuts their access everywhere at once. No shared API keys to leak.
Audit
Every question logged — who, what, when
Every tool call an AI client makes is written to a structured audit trail with user attribution — who asked, what ran, when, and whether it succeeded — readable by your admins in the app, including the attempts that were rejected at the gate.
| When | Who | Question | Tool | Status |
|---|---|---|---|---|
| 09:14 | asha@yourco.com | “Which invoices are overdue right now?” | query_data | ✓ answered |
| 09:16 | asha@yourco.com | “Top 10 accounts by pipeline this quarter?” | query_data | ✓ answered |
| 09:23 | rohan@yourco.com | UPDATE orders SET … — attempted write | query_data | ✗ rejected |
| 09:31 | marco@yourco.com | “What tables can I query?” | list_tables | ✓ answered |
Rows above are illustrative — the real page shows your organization's actual calls, filterable by user. An org-level switch controls whether full question-and-answer payloads are also captured, for teams with stricter data-handling rules.
No compliance badges — on purpose.
We don't yet hold formal certifications, and we won't pretend otherwise with a row of borrowed badge icons.
Here is exactly what we do instead — everything on this page: SELECT-only validation, read-only connections, credentials encrypted at rest, TLS by default, hard per-org isolation, team-scoped tables, and a full audit log.
And you don't have to take our word for any of it: every claim above is verifiable in a free account — connect a throwaway source, try to make the AI write to it, and read the audit trail yourself.
Security questions
The four questions IT asks first
Short answers here — the sections above carry the detail.
Can the AI change or delete anything in our database?
Do you train AI models on our data, or share it with anyone?
Where does our data actually live?
How can our IT team verify these claims?
UPDATE or DROP — watch it get rejected at the gate,
and see the rejected attempt appear in the audit log with the who, what, and when.Get the yes, then get the answers.
Forward this page to IT, connect a source, and ask your first question — your first 30 are on us.
Start free — 30 questions on us30 free questions · no credit card · read-only access · ~10-minute setup