Your data stays yours.
Intellrise keeps each account's data to that account — by an account column and a filter on every query rather than a database of its own, which the isolation panel below states plainly — and runs on your own AI key. Your credentials and your AI key are encrypted by us; the answers we keep are protected by our host's at-rest encryption instead — the first panel below says which is which, and why the two are not the same promise. On an ordinary question, what we send the model is your question, your table and column names, and the SQL — not the rows it returns. The names themselves do leave, and for a business whose tabs are named after its clients the names are the data — the bring-your-own-key panel below says what actually helps. Real rows reach your AI provider in exactly two cases, both named further down this page, and that provider is the one you chose and pay. What we keep is the answer, in your account, deletable.
What we encrypt, and what our host encrypts
Two layers, and a vendor review should have both, because they are not the same promise. We encrypt your data-source credentials and your AI key ourselves, with AES-256-GCM, before they reach the database — your key is only ever shown back to you masked. Everything else we keep — your chat history including the rows each answer returned, the reports and dashboards you save, and the files you upload — is stored as ordinary columns in our PostgreSQL database, which our host Neon encrypts at rest with AES-256 and reaches only over TLS (neon.com/docs/security/security-overview, read 29 August 2026). That is disk-level protection by our host, not a second lock we hold: at the database layer those answers are readable to us, while your credentials and key are not. If your review requires application-level encryption of the answers themselves, we do not have it today — that is worth raising with us before you connect rather than after. Where it physically sits, since we name our host on a dozen pages and had never once said this: the database is Neon on AWS ap-southeast-1 and the servers that reach it are Render's Singapore region — so your data is held in Singapore, not in the EU and not in the US. If your review needs an EU or UK region, we cannot offer one today.
Per-account isolation
One PostgreSQL database, not one per customer: every row carries the account it belongs to, and every query filters on it. That is logical isolation enforced in our application code — not a separate database, not a separate schema, and not database-level row security, none of which we use. It is a different risk profile from physical separation, so if your review requires that, we do not have it today.
We keep the answer, not your database
We don't use your business data to train our AI models, ever — and because the analysis runs on your own provider key, we have to be equally plain about the half we don't control: what your provider does with what it receives is set by its terms, and on a free tier those terms often do allow training. The bring-your-own-key panel on this page quotes them and says which key to use for confidential data. We keep no standing copy of what you connect: PostgreSQL, MySQL and Redshift sources are attached read-only and queried in place; SQL Server, Snowflake, BigQuery and Databricks are read into memory for the session instead, and a Google Sheet is re-read from the Sheets API each session. What does persist is the answer: the rows a query returns are saved with that message in your chat history, and again in any report or dashboard you save. Files you upload are kept in full, because a file has nowhere else to live. All of it sits in your account, and you can delete it anytime.
Bring your own AI key
Every request runs on your own provider key, so your data goes to your provider account rather than ours, and we never train on it. What leaves, precisely: your question, your table and column names, and the SQL. Query results are not sent to the model except in the two cases named next — otherwise it is told only whether the query ran and how many rows came back. Those two cases: AI Semantic Schema Learning on Pro: connecting or refreshing a source sends up to three sample rows per table so the model can work out what each column means — that step does not run on the free tier. And if a Gemini call fails part-way through an answer, the retry carries up to ten rows of the result it already has; the OpenAI and Anthropic paths have no such fallback. Both are listed in the connect guide. One consequence of running on your key is worth saying here rather than leaving for a vendor review to find: it is your provider's terms, not ours, that decide what happens to the data once it arrives — and those terms change with the tier. Google's Gemini API terms (effective 23 March 2026, read 28 August 2026) say that for Unpaid Services "Google uses the content you submit to the Services and any generated responses to provide, improve, and develop Google products and services and machine learning technologies", and the same page says "Do not submit sensitive, confidential, or personal information to the Unpaid Services." Between those two sentences Google's terms carry a third that a vendor review will ask about and that we had left out: "To help with quality and improve our products, human reviewers may read, annotate, and process your API input and output." Google says it takes steps first — "disconnecting this data from your Google Account, API key, and Cloud project before reviewers see or annotate it" — which unlinks who sent it, not what it says, so your table and column names are still in what a reviewer would read. On the paid tier — a key on a Cloud project with an active billing account — those terms instead say "Google doesn't use your prompts ... or responses to improve our products". The paid branch has a cost of its own, and it belongs next to the recommendation rather than in a footnote: the same terms say "For Paid Services, Google logs prompts and responses for a limited period of time", for abuse detection and any legally required disclosure. And if you are in the EEA, Switzerland or the UK, the paid terms apply to the free quota as well. The same terms carry a second sentence about the EEA, in a different section, and it points the other way: under "Use Restrictions", Google says "You may use only Paid Services when making API Clients available to users in the European Economic Area, Switzerland, or the United Kingdom" (read 31 August 2026). Whether that binds a bring-your-own-key setup like this one — where the key and the Google Cloud project are yours, and our software calls Google with them — we do not have a settled answer, and we are not going to invent one. Both sentences sit in the same document at ai.google.dev/gemini-api/terms; if you are in one of those three places, read that one yourself and have whoever signs off on your vendors read it too. We point new users at a free Gemini key because it is the fastest route to an answer from your own data. If that data is confidential, use a billing-enabled key, or a provider whose terms you have already cleared. And one limit of the reassurance at the top of this paragraph, because it does not hold for everyone: names are part of what leaves. If your tab is called "Acme Corp 2026 orders" or a column header is a client's name, then for you the names are the data — we cannot strip them, since the model needs them to write the SQL, so the honest options are to rename before connecting, withhold that table from the role you connect with, or use a key whose terms you have cleared. Renaming has a limit worth knowing before you rely on it: your question text goes to the provider too, so calling the tab Client A buys you nothing if you then type the client's real name into the question.
Transparent execution
You always see the exact SQL that ran. On complex questions — joins, cross-source queries, multi-step work — you get the query plan in plain English and approve it before anything runs. Simple lookups and aggregations run straight away. What keeps those safe is not us: it is the read-only user you connect with — and when you connect we check whether you used one, by asking your database what that account is allowed to do and showing you the answer. That is a report, not a gate: a writable account still connects, because the check is there to tell you something, not to lock you out. On our side a keyword guard refuses write statements before any query runs — eighteen keywords matched as text, a blocklist rather than a SQL parser, so it is the second line and your grant is the first.
What we store
We keep what an answer produced — never a standing copy of the source it came from.
- Your account (name, email) — Neon at-rest encryption; your password is only ever a bcrypt hash
- Your chat history — including the rows each answer returned — Neon at-rest encryption
- The reports & dashboards you choose to save — Neon at-rest encryption
- Your connection settings + AI key — encrypted by us with AES-256-GCM before storage
- Saved field/metric descriptions — Neon at-rest encryption
- Files you upload (CSV/Excel) — the file itself, until you delete it; kept in the same database, Neon at-rest encryption
- A standing copy of your connected database or Sheet — Postgres, MySQL and Redshift are queried in place; SQL Server, Snowflake, BigQuery and Databricks are read into memory per session and dropped with it
- Any row you didn't ask about — only what an answer returns is kept
- Anything used to train an AI model
The providers we rely on
A short list, named — and what each one actually receives, because that is the column a data-processing schedule asks for and a category label does not answer.
The database itself — everything in the We-store list above sits here.
Runs the app, so an answer passes through it in memory while it is produced. What it keeps is our application log: account emails, record ids and error messages.
Your email address and the message body — a verification code, a password-reset link, a share link, or a trial notice. No query results are ever emailed.
Crash reports: exception type, stack trace and 10% of performance traces. We turn off the SDK's PII option, so no headers, cookies or IP addresses. Two further things were reaching Sentry until 29 August 2026, and both are off as of that date. On 28 August this panel said we had not turned off local-variable capture, which the Python SDK turns on by default — a request failing inside code holding your rows could carry those values into the crash report. Writing that down is what made us go and read the rest of it, and there was a second one we had not seen: the FastAPI integration attaches the JSON request body to every error event, and the PII option does not cover it, so on the screen where you add a source that body is your database password. Both are single lines in the file that starts our API, deployed 29 August 2026. What a crash report holds now: which line of our code broke, what the error said, and which endpoint it was — no values out of your data, and no request body. Errors from the app in your browser reach Sentry too; session replay is switched off there, and the JavaScript SDK has no local-variable capture to switch off. Two reviewers reading this panel separately both asked the same next question, and the panel did not answer it: what happened to the reports from before 29 August. So on 1 September 2026 we opened the account and read it, rather than reasoning about it — including the half that is still open. The instrument is Sentry's own usage accounting: the per-project, per-day counts of what it accepted, which outlive the events themselves. Our plan keeps events for 30 days. By that accounting our API has sent 45 error reports in total, every one of them between 3 June and 16 July 2026 and none since, and all 45 aged out weeks ago. Both defects above applied only to error reports from the API, so on that side the window closed on 16 July, six weeks before we wrote the fix. Before you take that zero at face value, here is the check we owed you and ran, because a silent SDK and a quiet service produce the same number: the same accounting shows the API's Sentry client still transmitting on most days since, including today — 54 payloads on 20 August, then 4, 3, 1, 2 and 3 across the days after it, and 2 today. The pipe is live, so the zero is an absence of errors rather than an absence of reporting. The half that is not closed is the browser. Twenty-two browser errors from 5 and 6 August are still stored, and two of them show Sentry's own password filter having fired on the way in — so something password-shaped did leave a browser in August, after the API window had closed, and what is kept is the record of the removal rather than the value. We have read all twenty-two: no connection string, no API key, no token. We are not going to write that there is nothing left to delete, because there are twenty-two things and what we actually did was judge them harmless — if you would rather they were gone, ask and we will delete them and show you the result. And the honest shape of that last defect is that the thing which caught it runs on Sentry's servers after the data arrives, not in our code before it leaves; today we rely on theirs. If you connect a source and later want to know what your own account has generated, ask and we will read it out the same way.
Nothing at all until you accept the cookie banner — capture is off by default. After that: page views, your email and name, named product events (signed up, trial started, source connected, AI key added, first chart, upgrade clicked), and one thing we had not been naming here — the visible label of whatever you click, which PostHog calls autocapture and which we leave switched on. So we went and read what it has collected rather than telling you what it should collect: across every autocapture event of the last 30 days there are 23 distinct labels, all of them interface text — Connect, Test, New Chat, Add AI Key and the like — and not one is a table name, a column name, SQL or a result cell. No input values are captured at all (checked 31 August 2026). Session replay is off. The residual risk is ours to state: this is a general click recorder, so what protects you is where the buttons are, not a rule that stops it.
Your billing details, entered on their checkout — they never reach us. We receive back the subscription status.
Your question, your table and column names, and the SQL — plus real rows in the two cases named above. On your key, under your contract with them.
One of those seven is not ours. Intellrise does not supply the AI model — you connect your own API key for a provider you choose, so the model call is billed to your account and processed under your contract with that provider, not ours. If a vendor review asks which AI company we send your schema to, the answer is the one you picked.
This is the same list as section 5 of our Privacy Policy, which stays the canonical version. Operated by Intellrise Technologies (SSM 202603145414), Malaysia. Our Terms, Privacy and Refund pages are available below.
Questions about security?
Get your end-to-end AI business intelligence now.
Ask in plain English, pin the answer to a dashboard, export it as CSV, Excel, PDF or PowerPoint — on the free tier that whole loop runs on one database source plus Google Sheets, and the field definitions you save carry into every later session, including after a schema refresh. One exception you should hear from us rather than discover: on a Google Sheet, re-running the tab picker — even only to add a tab — clears the definitions saved for that source and reads its schema fresh. Connecting a database is the technical part: a read-only user and network access, once. If your numbers live in a spreadsheet, none of that applies: put the file in a Google Sheet and it connects on the free tier, with no read-only user and no open port. Uploading a CSV or Excel file directly is a Pro feature, and every new account gets 14 days of Pro with no card. The one thing no plan waives is your own AI provider key, and a Google Gemini key is free to create.
Every new account starts on a 14-day Pro trial with no card. After it lapses, the free tier stays free.