Securely access your data from
anywhere: databases, SOPs, APIs, document repositories and social networks.
Available whenever and wherever you need it.
Assistant
Scripted preview
| Customer | Late | Avg days |
|---|---|---|
| Northwind Foods | 4 | 1.8 |
| Adriatic Retail | 3 | 2.3 |
| Vilna Grocers | 2 | 1.5 |
OrdersSELECT count(*) FILTER (WHERE "ShippedOn" > "PromisedOn"), count(*) FROM "Orders" WHERE "ShippedOn" >= '2026-08-01' AND "ShippedOn" < '2026-09-01'"Orders" cut to its approved columns where "TenantId" = @__ai_tenant, by Sonela, never the modelOrders, CustomersSELECT, grouped by customerOrders, Shipments, WarehousesSELECT comparing handling times by monthInvoices, CustomersSELECT of unpaid invoices past their due dateOrderLines, ProductsSELECT ranking this quarter’s productsSELECTOne assistant, one set of rules and one bill, in the software your staff already use.
Plain English in, read-only SQL out, checked against a grammar that cannot express a write. PostgreSQL, SQL Server and MySQL, each shipped only with its full safety-test suite.
Someone can send a picture of the screen with the question, so “why is this line red?” becomes something they can ask. They choose to every time, and you can stop it altogether.
Read in the browser and transmitted nowhere, today: it is the groundwork the answering path is being built on, and the brief says exactly where it stops.
Your records and your documents, nothing else. Answers never come from what a model remembers about the world, and when your material cannot support one, it says so.
Upload your handbooks and SOPs, and it answers from them. You can start there, with no database connected at all.
Name your public site and it is read in and re-read weekly: same host, up to fifty pages three clicks deep, robots.txt honoured, and page text never reaches a log.
Register an endpoint and say what it is for. When a question calls for it, the assistant calls it and answers from what comes back.
Bring your own and your rows reach only the provider you chose, under your own agreement, paid direct. Run on ours and there is nothing to set up — that model cost is ours, which is what those plans price in.
Before the AI model — yours or ours — reads a question, your records or your systems’ replies, the personal details Sonela recognises become placeholders, and the answer gets the real values back. The brief says where it stops.
When the AI provider answering a question cannot, the next one does. On our key we run more than one, so an outage cannot take your assistant down; on your own, add a second key as its backup.
Bring several keys of your own and share conversations between them by the percentages you set. Each conversation keeps the key it was given, and moves only if that key fails.
Colours, name and greeting are set in your dashboard and reach every page carrying your key at once. Nothing is redeployed and no tag is edited.
Your admin sees what was refused and every change anyone made to the setup. Usage is counts of questions answered, never the conversations.
Three put it in front of your staff and carry everything. The fourth answers anyone on your website, deliberately narrower — the table marks every difference.
One script tag, and it appears inside the screens your staff already work in.
For when a vendor owns your app or the release train is long. Nothing to deploy: you list work addresses and an emailed code lets them in.
The same gateway, the same approved schema and the same read-only rules. What it cannot do is send the screen someone is stuck on, or read the page’s own data: our page is not your application. It is the quicker way in, not the better one, and moving to the tag later repeats nothing.
The hosted page works on a phone the day you switch it on: same link, same code, signed in for thirty days. iOS and Android apps wrap that same page.
Apps built · not in the stores yetThe same one line, on a key you mark public: it answers your visitors from your published material, never from your database.
This is the whole change to your app
<script src="https://api.sonela.ai/sonela.js" defer></script>
| Capability | In your app | Hosted page | Phone app | Public site | API |
|---|---|---|---|---|---|
| Questions into SQL | Yes | Yes | Yes | No | Yes |
| Your documents and SOPs | Yes | Yes | Yes | Yes | Yes |
| Reading your website | Yes | Yes | Yes | Yes | Yes |
| Calling your own APIs | Yes | Yes | Yes | Only the ones you open to visitors | Yes |
| Grounded, or it says so | Yes | Yes | Yes | Yes | Yes |
| Your AI key, or ours | Yes | Yes | Yes | Yes | Yes |
| A backup AI | Yes | Yes | Yes | Yes | Yes |
| Load balancing | Yes | Yes | Yes | Yes | Yes |
| Governance and the record | Yes | Yes | Yes | Yes | Yes |
| A picture of the screen | Yes | No | No | No | No |
| Reading the page's own data | Yes | No | No | No | No |
A server of yours asks the same assistant over an API and gets the answer back as text and tables, or as a stream. It presents a secret key you make in the dashboard, and the key fixes whose records it may ask about, so nothing in a request can widen that. You set each key’s limits and revoke it when you like. Read-only like everything here, on the Growth and Scale plans — the table’s last column is what it carries.
Inside a larger organisation
The team that has to clear a security review before anything new touches the business software. You get the brief your reviewer asks for and a record of every change and refusal — bought with a card, not a procurement cycle.
In a small team
Running a line-of-business app you cannot afford to have answered wrongly. The same product, the same guarantees and the same brief — first-class citizens, not a cut-down tier.
And software vendors, who hand it on across a customer base — a different shape, with a section of its own.
A school runs it for its own people; a government institution is testing it on its public website. Neither is named here until they choose to be.
In production
The people the school has invited ask on the page we host, from a computer or in the app on their phone. It answers from the school’s own records, its written procedures and the latest posts on its social pages — and when someone asks for one of the school’s documents, it fills in the school’s own template, shows them every value, and emails the finished file once they say yes.
In testing
On its public website it answers anyone, with no sign-in, from what the institution has published and the latest posts on its social pages, and it calls the institution’s own API for the answers no page holds.
If you sell software to other businesses, your customers are already separated in your database. Sonela was built to keep them that way, and the ISV guide shows the integration step by step.
One tag across your product; your server names each person’s customer.
In the short-lived token your own server signs for each signed-in person, never on the page, and the key opens nothing without it — so a new customer needs nothing set up in Sonela. Prefer a key per customer, each with its own look? That still works, unlimited on Scale. The ISV guide walks through it.
Every query is rewritten to that customer before it runs.
Not a filter the model is asked to remember: every table reference is rewritten into a tenant-filtered subquery before execution, and the security brief states exactly where that stops.
Name, colours, greeting and logo per key — and on Scale, no mention of Sonela.
Each key carries its own look, so one customer’s assistant need not resemble another’s. White label is on the Scale plan, and it is the same switch the pricing card names.
Sign a short-lived token and only your pages can open a session.
The secret never reaches the browser, so a key lifted from your page source opens nothing. One workspace, many customers, and the door is your own backend.
Two things worth knowing before you plan around it. Scale carries a fixed monthly allowance of question credits, and a whole customer base is exactly the traffic that finds a ceiling — so if yours is large, that is a conversation rather than a checkout. And there is no Sonela login for your customers: you hold the workspace and every switch in it, which is usually the point, but it is yours to administer. Tell us what you are building.
The simplest path is a direct connection: nothing to install, two steps in your dashboard. When your review wants nothing of yours reachable from outside, run the Sonela Gateway instead — the high-security option. The same read-only rules apply either way, and where people meet the assistant is a separate choice: none of the channels changes anything here.
Give us what your database expects at sign-in. We test the connection before we accept it, and there is nothing to install.
On our infrastructure, encrypted, bound to your workspace, and no API of ours reads them back. Your database has to be reachable from the internet for this, and we name no fixed address to allow through a firewall — if yours sits behind one, the gateway below is the way in.
Sonela drafts a manifest of what it can see. Nothing is queried until you approve it.
It reads your schema and drafts the manifest. You hide what shouldn’t be visible, confirm how customers are kept apart — or that the database has one owner — and approve.
One small service, on one server of yours, next to the data it reads. It dials out to us over port 443 and asks whether there is work, so you open no inbound port and nothing connects inward. What it needs to reach your database is configured on your side and stays there, and the read-only checks run there too. The schema step is the same; the gateway reads it from inside your network.
Five stops, in the same order, every time.
In the app they already have open, in the words they would use with a colleague.
It is not guessing at your industry from the outside.
Your data in the shape you approved, the procedures and policies you uploaded, the context you wrote for your workspace — that is the material, and the vocabulary it answers in.
Right then, from your live records — not a copy, not last night’s export.
Only the tables you approved, so a question about anything else has nowhere to go, however well it is put. It sees one customer’s rows — the ones the embed is for — and it can only read them.
The real numbers, or a short table — never a chart to go and read for yourself.
That is the answer. The preview at the top of this page closes on exactly that exchange, and it is the product working rather than failing.
The conversation lives in the browser tab and goes when the tab does.
What they said passes through us and the AI provider composing this one answer, and is written down nowhere — not in a transcript, not in a cache another question could reach. The one exception is theirs to make: reporting an answer offers them a ticked box that sends that one question and that one answer to you, and unticking it reports the answer with no words at all.
Exactly what happens to your data, including the parts most vendors leave out.
Your data
Nothing it runs can write to your database.
An allowlist validator refuses anything that isn't a single SELECT. What survives runs under a three-second statement timeout and a cap of 500 rows — on PostgreSQL and MySQL inside a READ ONLY transaction the database engine itself will not let write. And every transaction is thrown away rather than committed — there is no commit in the query code for any path to reach.
Your data
One customer's rows, and never another's.
Every table reference is rewritten into a tenant-filtered subquery before execution. The tenant identity is bound server-side from a verified token — the browser can't assert it, and the model never sees it.
Your data
No question, no answer, no row of yours is written down here — except an answer someone reports to you.
Answers grounded in your data are structurally uncacheable. In the assistant's panel, the transcript stays in the visitor's browser. Our metering stores counts, latency and token totals — never a question, an answer, or a line of SQL. The one thing we keep is an answer someone reported and chose to send you: that one question and that one reply, read by your workspace and never by us, deleted 100 days later.
Your data
What the gateway needs to reach your data stays inside your network.
Run that way there is nothing for us to store: the field on your workspace holds null, and what we keep is a hash of the gateway's key.
An AI key you bring is encrypted with AES-256-GCM, bound to its own row, and no API we expose reads it back.
Its answers
The rules reach the model before any of your content does.
Everything the workspace supplies — the question someone typed, the procedures you uploaded, the context you set — is handed over under an explicit instruction to treat it as data with no authority to change them.
And it does not have to hold: the read-only grammar and the tenant rewrite run after the model has spoken, so content that talked it into something still cannot write, and still cannot reach another tenant.
Your data
Your server can vouch for who is asking, with a secret that never reaches the browser.
It signs a short-lived token; the assistant refuses to start a session without one. Turn it on and only pages your server has vouched for can open a conversation at all.
Generating the signing secret arms the workspace and breaks nothing that is live; refusing unsigned pages is a separate switch that stays yours. Until you flip it, an anonymous session still answers, held to a per-visitor-address slice of your workspace's own request rate — strangers divide your capacity, never widen it. A vouched session is served at the workspace's full rate, with no per-address slice.
Personal data
The ID numbers Sonela recognises, and the names and contact details your switches mask, reach the AI model — yours or ours — as placeholders, and the real values come back in the answer.
The question, the conversation so far, the rows a query returns and your own systems’ replies — and, on every assistant but a public one, your manuals. Card numbers, IBANs, passwords and ID numbers are masked for every workspace; names, contact details, addresses and company names are switches under Data sources → Personal data in your dashboard, beside a count of what was masked, and a new workspace starts with names and contact details masked. Another switch decides whether the people asking see the real values or the placeholders. When the assistant looks a record up by a masked value, Sonela fills in the real value itself.
Sonela recognises a value by its format and checksum, its column, or the title or label in front of it: a careful heuristic, not a guarantee. A name in an ordinary sentence with none of those reaches the model as written, and so does a screenshot. The security brief lists where it stops.
| Data | What actually happens |
|---|---|
| The question someone types | Reaches Sonela and an AI provider — the one you chose if you brought a key, one of those we run if you did not, and a second of ours only when the first cannot answer. The ID numbers Sonela recognises in it, and the names and contact details your switches mask, reach the provider as placeholders. It is not stored afterwards, unless someone reports the answer to you. |
| Rows returned by a query | Pass through Sonela's memory to compose the answer, and reach that same provider with their personal details masked the same way. Never written to our disks. |
| An answer someone reports | Reporting an answer offers a ticked box that sends that one question and that one answer to you, so you can put it right; unticked, the report arrives with no words at all. Only your workspace reads them — we count reports and never see the text — and they are deleted 100 days later. You can switch reporting off. |
| How your data is reached | Two ways, and you pick. By us, directly, using the sign-in details you gave us: those sit on our infrastructure, encrypted, and no API of ours reads them back. Or, for the strictest reviews, by the gateway you run, from inside your network — what it needs to do that is configured there and stays there. |
| A screenshot someone sends | Reaches that same provider as it was taken, with the one message it was attached to. Never stored, never logged, and it does not join the conversation. |
| Your AI provider key | If you bring one: encrypted at rest, never returned by any API. On Sonela's key: there is none of yours to hold. |
| Written material you upload | Procedures, notes and policies you give the assistant are kept in your workspace — that is what they are for — and go to the same AI provider with the question. Only your workspace can read them; deleting them, or the workspace, removes them. Google Docs, Word and Excel files you sync from Google Drive are kept the same way, read with a service-account key that is encrypted at rest and never returned; a file you delete or stop sharing in Google Drive is removed at the next hourly sync that reads everything you shared, and any file Google has not confirmed for seven days is removed even if no sync could reach it. Posts from public Facebook pages and Instagram profiles you add are kept the same way, the latest ten from each: a scraping provider reads the page for us and is given its address and nothing else of yours. A post you delete from the page is removed within a week, at the page's next full reading, and a page no full reading has confirmed for fourteen days loses its posts. |
| Chat transcripts | In the assistant's panel, held in the visitor's browser for the conversation. We keep no conversation: a reported answer is one exchange out of one, and nothing either side of it. |
| Question or answer text in our metering | Never collected — counts, latency and tokens only. |
| Write access to your data | None, by design. There is no code path that writes. |
We are a data processor. Questions and rows transit us and the AI provider that answers; neither is kept, bar an answer someone reports to you.
Both switches start on, and both are one click to turn off.
The assistant is more useful when it can see what someone is looking at, and it is more exposed for the same reason. Both of those are true at once, so the decision is yours rather than ours — and a trial that hides its useful half is not a trial.
| Switch | What turning it off does |
|---|---|
| Page screenshots On by default | Once the setting reaches the page, no camera in the composer and the code that would take a picture is never loaded. |
| Reading the page's own data On by default | On a production embed the reader is never installed, so nothing is captured at all. Nothing was being transmitted in either state — that half is groundwork, not a live capability. |
Both settings belong to the workspace, and we hold them — a page carrying the assistant cannot quietly restore either.
Every embed in the workspace moves together. Your staff see the guarantees too: a shield in the assistant’s panel opens them in plain words, and when page capture is on, the person being read is told. Where each switch stops exactly, and where it does not, is written out on the security brief.
Three plans, and one choice inside each: bring your own AI key, or run on ours. Pay yearly and get 2 months free. Prices in USD, excluding VAT.
What you pay us is flat and does not move when your usage does. Nothing here is sold by the seat, so the bill does not grow when the team does.
Your own key: you pay that provider directly, under your own
agreement with them — included balances are higher because the model cost is not
ours.
Sonela's key: nothing to set up. Your rows reach the provider we
run, under our agreement, on a model we pick for cost — that cost is ours, which is
why those prices are higher and the included balances lower.
Always on Sonela's AI key
14 days, no card. After 14 days or 320 question credits the workspace pauses — everything you configured (schema, context, settings) survives and resumes the moment you choose a plan.
For a live assistant inside one product or workspace.
For vendors embedding the assistant across a customer base.
Need more, or something on-premise? Tell us what you need.
Three things people weigh us against, and none is the same comparison. Vanna AI is a text-to-SQL framework you assemble and run. Chatbase is an agent platform grounded in the documents you give it. ChatGPT, Claude and Gemini are general assistants, a paid seat for each person, in the vendor’s own app. Sonela answers from your live records the way Vanna does, arrives as one line of code the way Chatbase does, and sits inside your own software rather than in someone else’s app — and the read-only guarantee and the separation between one customer’s rows and another’s are ours to keep rather than yours to wire up. Some rows go their way and are printed that way — everything in their columns comes from their own pages, named under each table.
| What is being compared | Sonela | Vanna AI |
|---|---|---|
| How your staff reach it | Yes. Three channels we run — in your app, a page we host, iOS and Android — carrying the same ten capabilities, branded per workspace from your dashboard. | Embeddable web component — their README shows React, Vue or plain HTML. |
| What it is | Yes. One assistant we run. You configure it rather than build it. | A framework you assemble and run, with a hosted service alongside. MIT-licensed. |
| Run entirely on cloud | Yes. Latest cloud technology, 0 maintenance by you. | No. Self-hosted with local storage. |
| Databases | PostgreSQL, SQL Server, MySQL and all other ANSI RDBMs. | Yes. Ten in their README, including Oracle, Snowflake, BigQuery and ClickHouse. |
| AI models you can bring | Any OpenAI-compatible endpoint, including one you run yourself, plus Gemini — or no key at all, on a plan where we supply the model. | Seven in their README, including Anthropic, Ollama, Bedrock and Mistral. |
| Reading your website | Yes. Name your public site and it is read in — same host, up to fifty pages, robots.txt honoured — and re-read weekly. It answers from it like an uploaded manual. | Not described in their README. Knowledge is what you supply in code. Read 7 Sep 2026. |
| Calling your own APIs | Yes. Configured per workspace from the dashboard, and called when a question needs them. | Custom tools, written in code: extend their Tool class and register it, per their README. Read 7 Sep 2026. |
| Who guarantees a query only reads | Yes. We do, in the product: an allowlist grammar, engine guards, no commit anywhere. | A framework question: a SQL runner per database, policy left to whoever deploys it. |
| Keeping one customer's rows out of another's | Yes. Every table reference rewritten into a tenant-filtered subquery, bound server-side. | Row-level security — their README describes filtering per user permissions. |
| What reaches the AI model | Question, prompt, the rows a query returned, recent turns, an attached screenshot — the personal details Sonela recognises in the question, the turns and the rows as placeholders. | The same shape. Sign-in and connection details never sent. |
| What you pay | Flat monthly or yearly, with an allowance of question credits each month. | $50/mo for 20 questions a day, $500/mo for 300. Rate-limited past the cap. 29 Aug 2026. |
The website and API rows were checked against the vanna-ai/vanna README on 7 September 2026. Everything else was checked on 29 August 2026 against vanna.ai/pricing, vanna.ai/data-security (their version 2.0, last updated October 2025) and the vanna-ai/vanna repository on GitHub. Prices and product facts on someone else's site change without telling us; if a row here has gone stale, tell us and we will fix it.
| What is being compared | Sonela | Chatbase |
|---|---|---|
| Live data, and where the query runs | Yes. Connect directly with nothing to install, or, for the strictest reviews, run the Sonela Gateway: one service on one server inside your own network. There the read-only query runs on your side, against your live data — checked first against a grammar that cannot express a write — and the gateway dials out to us, so there is no inbound port and nothing of yours exposed. The security brief states both in full. | Grounded in material you upload or point it at, held and served from their cloud — a support agent rather than a query against the systems you run. |
| Keeping one customer’s rows out of another’s | Yes. Every table reference is rewritten into a tenant-filtered subquery before the query runs. The rewrite is the system’s, not the model’s — there is no instruction to forget and nothing a question can talk it out of. | A different shape: their agents answer from the material you give them rather than querying your database, so there is no query to rewrite. |
| What it is | One line of code in the software your staff already use, answering from the records inside it — and saying so plainly when it cannot. | An agent platform for customer experience and support, in their own words. Different job, not a smaller one. |
| Who it answers | Your staff, and your site’s visitors on a key you mark public. | Your customers, across the channels they already use. |
| Your documents and your website | Yes. Upload your procedures; point it at your public site and it is read and re-read weekly. | Yes. Files, your website, text, question-and-answer pairs, Notion, and tickets from Salesforce or Zendesk. |
| Calling your own APIs | Yes. Your endpoints become tools the assistant may call, each with its own sign-in held on our side. | Yes. Actions and integrations, with worked examples for orders, invoices and products. |
| Where people reach it | Three channels: in your app, a page we host, and iOS and Android. | Yes. More than we offer: website, WhatsApp, Meta apps, Slack, email and voice. |
| AI models you can bring | Yes. Run on our key, or bring your own from the providers we support. | Yes. A published choice of models from several vendors. |
| Independent certifications | Not yet — we are going through the audits now, and until they are signed we say so rather than imply otherwise. Meanwhile you get the threat model itself, which no certificate gives you. | Yes. Chatbase publishes independent audit and compliance certifications on their site. |
| What you pay | Flat monthly or yearly, with an allowance of question credits each month. | Free for 50 message credits a month; $40/mo for 700, $150/mo for 4,000, $500/mo for 15,000. Extra credits $40 per 1,000; extra agents $25/mo each. 15 Sep 2026. |
Checked on 15 September 2026 against chatbase.co, chatbase.co/pricing and their documentation for data sources. Prices and product facts on someone else’s site change without telling us; if a row here has gone stale, tell us and we will fix it.
| What is being compared | Sonela | ChatGPT, Claude, Gemini |
|---|---|---|
| Where your staff ask it | Yes. Inside the software they already work in, from one script tag in your app — or on a page we host, or on their phone. | In each vendor’s own app on the web, desktop and phone, and inside tools such as Microsoft 365 or Google Workspace. We found no documented way to place it inside your own application; that is a build on their developer platform. |
| Your live database | Yes. Read-only queries against your live records, run over a direct connection or through the gateway inside your network, and checked first against a grammar that cannot express a write. | No built-in link on these plans. A custom connector that someone builds and an admin adds can reach one, and each vendor’s help pages leave its safety to whoever builds it. Google’s own AlloyDB preview says it cannot fully rule out unintended write queries. |
| Keeping one customer’s rows out of another’s | Yes. Every table reference rewritten into a tenant-filtered subquery, bound on our server; the model never sees whose rows they are. | Whatever the connector you build enforces. Google’s AlloyDB preview shows every user the same data rather than filtering per person. |
| Who can use it | Yes. Anyone you put it in front of: your staff, your own customers inside your product, or your website’s visitors on a key you mark public. | People with a paid seat in your workspace: ChatGPT Business is for teams of 2 to 200, Claude Team for 2 to 150. |
| What you pay | Flat monthly or yearly per workspace, with an allowance of question credits each month — not per person. | Per person. ChatGPT Business and Claude Team: $20 a seat a month billed yearly or $25 monthly, with premium seats from $100. Gemini Enterprise Business from $21 a seat a month. |
| Your documents | Yes. Upload your manuals, name your website, or sync files from Google Drive. | Yes. More sources than ours: Google Drive, SharePoint, Slack, GitHub, Microsoft 365 and others, depending on the vendor. |
| Anything else a person asks | Built for questions about your business, answered from your own sources. | Yes. Writing, analysis, code, the open web: a general assistant, which is the point of it. |
| AI models you can bring | Yes. Run on our key, or bring your own from the providers we support. | Each runs its own vendor’s models. |
| Independent certifications | Not yet — we are going through the audits now, and until they are signed we say so rather than imply otherwise. Meanwhile you get the threat model itself. | Yes. All three publish independent audit and compliance certifications. |
Checked on 30 September 2026 against chatgpt.com/pricing, OpenAI’s company knowledge announcement and its help article on developer mode and MCP apps; claude.com/pricing, Anthropic’s help article on custom connectors and trust.anthropic.com; cloud.google.com/gemini-enterprise, Google’s Gemini Enterprise documentation for AlloyDB and the Google Workspace Privacy Hub. Prices and product facts on someone else’s site change without telling us; if a row here has gone stale, tell us and we will fix it.
Anything else, write to us. A person reads it, and a person replies.
An email address. No card, and no AI key — a trial runs on Sonela's key, on a model we pick, under our agreement with the provider. It lasts 14 days or 320 question credits, whichever comes first.
You do not need your data connected on day one. Start by giving the assistant your own written material — procedures, product notes, policies — and it answers from that, and says plainly that it cannot see live records yet. Bring your operational data in through the gateway when you are ready: it is the same workspace, and everything you set up stays set up.
Yes. We host the assistant on a page of our own instead, and you invite people to it by email address — they sign in with a short code, so there are no accounts or passwords for you to manage. The gateway and the schema you approved are unchanged.
Be aware of what it costs: on our page nobody can send the screen they are stuck on, because our page is not your application. That is the one capability the embedded assistant has and this one cannot. It is the quicker way in rather than the better one, and you can move to the script tag later without setting anything up twice.
Yes, on the Growth and Scale plans. Your server sends a question over an API with a secret key you make in the dashboard, and gets the answer back as text and tables, or as a stream. The key fixes which data source it asks through and whose records it asks about, so nothing in a request can widen either.
You set the limits on each key, rotate it, and revoke it whenever you like. We keep only a hash of it, so nobody can read it back, us included. It is read-only, like everything else here, and a key belongs on a server, never in a web page.
No. Three independent layers stop it: the validator only permits a single read query, that query runs under the engine's own guards — on PostgreSQL and MySQL a READ ONLY transaction it will not let write — and the transaction is rolled back rather than committed. Even a compromised model can't write.
To connect directly, your database has to be reachable from the internet: you give us what it expects at sign-in, and we hold those details encrypted, bound to your workspace. If your review wants nothing opened at all, run the gateway, the high-security option: it sits inside your network and dials out to us over port 443, so there is no inbound port to open and nothing of yours exposed to the internet. Whatever it needs to reach your data is configured on your side and stays there; what we hold of it is a hash of the gateway's key, plus the schema manifest you approved. The security brief states both paths in full.
Yes — that is exactly what the Sonela Gateway is for. It is one small service you run on one server inside your own network, next to the data it reads. It reaches out to us and asks whether there is work; we do not dial into it.
Everything that matters happens on your side of the firewall: the gateway checks the query, applies your tenant filter, runs it read-only and sends back the rows. Nothing lands on anyone's desk, and there is nothing for your team to install on staff machines.
Yours or ours — it is a choice on each paid plan, and it moves both the price and the included balance of question credits. Bring your own key and your rows reach only the provider you chose, under the agreement you already hold with them. Run on Sonela's key and they reach the provider we run, under our agreement, on a model we pick for cost. Trials always run on our key, so there is nothing to configure to start one.
PostgreSQL, SQL Server and MySQL today — each shipped only once its full safety-test suite passed. For AI: Gemini, OpenAI, Azure OpenAI, or any OpenAI-compatible endpoint if you bring your own key — or Sonela's key, where we run the provider and choose the model.
Every query is rewritten so each table reference is filtered by tenant before it runs. The tenant identity comes from a token your server signs, never from the browser — so a user editing JavaScript in the page can't reach another tenant's rows.
You are asked exactly once, when you connect: say the database has one owner and the tenant filter is skipped, because there is no second tenant to keep out. Everything else is identical — the read-only guarantees, the approved schema, the metering — and nothing is read from your database until you have answered.
No. We train nothing, and we don't use your data to improve the service for anyone else. Your rows go to the AI provider that answers the question and no further: the one you chose under your own terms if you brought a key, or one of the providers we run under ours if you did not. We hold accounts with more than one so an outage cannot take your assistant down, and a question reaches a second only when the first cannot answer it.
Less of it, and you decide how much less. Before a question and the records that answer it reach the AI model — the one you chose under your own key, or one Sonela runs under ours — Sonela swaps the personal details it recognises for placeholders: names, the part of an email address before the @, phone numbers, and ID, card and bank account numbers. The model answers with the placeholders, and Sonela puts the real values back before the person asking reads the answer, unless you choose to show placeholders; a card number or an IBAN Sonela recognises stays out of the answer, which says one was removed.
Card numbers, IBANs, passwords and ID numbers are masked for every workspace, whatever its settings. Names, contact details, addresses and company names are switches in your dashboard, and a new workspace starts with names and contact details masked. It is a careful heuristic, not a guarantee: a name in an ordinary sentence with nothing to mark it as one reaches the model as written, and so does a screenshot. The security brief lists where it stops.
It says so. Sonela answers from your own material — a query against your live operational data, or the procedures you gave the workspace — so when neither can support an answer it reports that instead of guessing: a wrong number delivered confidently is worse than no number at all.
It fails out loud. A passing glitch — a rate limit, a bad minute at the provider — is retried first; what survives that is reported as a failure, never as a blank answer and never as a guess. Your Usage screen says which questions failed and names the provider's part in plain words — refused, no capacity, retried — while the widget your staff use says only that the assistant is unavailable, because naming your provider's fault to whoever is on the page would describe your setup to a stranger.
Open a workspace yourself and be asking it questions in minutes — or write to us first and we will walk you through it.
14 days, 320 question credits, no card. It won't guess on your data. No AI key to supply — trials run on Sonela's key.