WeTa Analytics protects your data in layers: every request is checked against who you are and what you are allowed to read, each organisation's data is kept separate, you control which AI model may answer questions and what it may see, every figure is computed by the database rather than written by AI, stored files are encrypted, and every change is recorded in an audit trail.
WeTa Analytics lets a team upload data, ask questions in plain language, run predictions and build reports. Behind every one of those features is a question we take seriously: where does the data go, who can see it, and what can the system be made to do that it should not? This article sets out the measures the product follows, plainly, so your IT and security teams can judge it for themselves.
1. Every request passes one door
Every call to the application goes through a single guard before any feature code runs. In order, it checks:
- A valid sign-in. Every route needs a signed token for an active, email-verified account. The only exceptions are the few routes that exist to sign in, sign up, reset a password or report health.
- The licence. The account's organisation must be active with a valid licence.
- The workspace. A request for a workspace the organisation has not licensed is refused.
- That you are you. A user id in a request must be the caller's own.
- Only data you may read. Every dataset, report template, Data Bridge and chat referenced in a request is checked against what the caller is allowed to read: their own, their organisation's, or something explicitly shared with them.
This guard is applied to every route automatically, so a route added tomorrow is covered without anyone remembering to add it. When a request asks for a dataset the caller may not read, the answer is “not found” rather than “forbidden”, so an outsider is never told that another organisation's data exists.
2. Accounts and sign-in
- Passwords are stored as bcrypt hashes. The plain password is never stored.
- Sign-in tokens are signed and expire. Suspending an account invalidates its sessions.
- Sign-in attempts are rate-limited per caller and per account, and a successful sign-in clears the counter.
- New accounts must verify their email address before they can use the product.
- The server refuses to start in production with a placeholder or weak signing secret.
- Cross-origin access must be configured explicitly. A wildcard is never honoured.
3. One organisation cannot reach another's data
- Reading a dataset requires being its owner, being in its organisation, or holding an explicit share made inside the owner's organisation. Changing a dataset requires being its owner.
- Reports belong to the person they were generated for. Being in the same organisation is not enough to open someone else's report.
- Stored files (uploads, report images, PDFs) are reachable only through signed links that expire and are tied to a path, a user and a lifetime. Guessing a file name opens nothing, and attempts to climb out of a folder are refused.
4. You decide what the AI may see
Questions asked in plain language are interpreted with the help of a language model. Which model may answer, and what it may be shown, is a setting for your organisation, and it governs every place the product uses a model: the planner that reads a question, the writer that words an answer, summaries, reports, data stories, explanations and predictions.
- A model inside your own network. Your organisation can be pointed at its own model profile, including a model running on your own infrastructure.
- Schema only. A model can be allowed to see the question and the shape of your table (column names, types and roles) while data values stay out of the request. The rule is deny by default: a request counts as carrying values unless that code path has been reviewed and declared value-free.
- Blocked entirely. Your organisation can forbid any external model. The block is enforced at a single gate the whole application passes through, and a feature that cannot work without a model falls back to ordinary logic or says so, rather than sending data anyway.
Every call to a model is counted, with the model, the feature that made it and the amount used, so usage can be audited and explained. For more on why this matters, see private AI analytics and why localised models matter.
5. Numbers are computed, never guessed
This is a principle of accuracy that doubles as a security measure: the AI never produces a figure. It produces a plan, the plan is checked against what your data can actually express, and the database computes the number. A question the data cannot support is refused by name rather than estimated.
Written summaries are checked against the computed figures too. A sentence carrying a number that was not computed is removed, and a summary that strays from the data is replaced with a plain template. You can read how the question-to-answer path works in our guide to natural language analytics.
6. Generated code runs in a locked box, or not at all
For questions that the standard plan cannot express, the product can let the model write a short analysis in code. That code is treated as untrusted:
- It is written from the shape of the data only. The model never sees your rows.
- Two independently written analyses must agree before a figure is given.
- Before it runs, the code is checked for anything that reaches outside the data, such as file, network or system access, and for columns that do not exist.
- It runs in a separate, short-lived container with no network access, a read-only filesystem, capped memory, dropped privileges and a time limit. A deployment can require that container and refuse to run otherwise.
- An automatic test fails the build if code execution ever creeps into the main application.
- The whole feature stays off unless a deployment turns it on.
7. The server does not dial into your network
Connecting a data source means the server opens a connection to an address somebody typed. Left unchecked, that is a well-known attack (server-side request forgery). Every such connection is checked first: the name is resolved and every address behind it must be public. Internal addresses, private ranges, cloud metadata addresses and similar are refused by name, and the check runs at connection time, every time.
For a database that lives inside your network, the product offers the Data Bridge instead: a small agent installed next to your database that dials out to WeTa Analytics over HTTPS. No inbound port is opened on your side. The agent's token is shown once, stored only as a hash, and can be rotated or revoked, and it travels in a header rather than in a web address, so it never lands in server logs. Live queries through the agent are read-only: anything other than a read is refused by the agent before it reaches your database.
8. Encryption at rest
Two layers, because no single one covers everything:
- Stored files are encrypted by the application. Uploaded originals, workbooks, generated reports, images, exports and trained models are encrypted with AES-256-GCM before they are written, and decrypted when read, under a key held on the server. A copy of the database, a dump or a backup therefore holds unreadable content for all of them. The key can be rotated without downtime.
- Connector credentials (saved data-source passwords, sync passwords, API tokens) are encrypted with a separate key and are never sent back to the browser.
- The analysed rows themselves are protected at the storage layer, by encrypting the disk they live on and the backups, because the database has to filter, group and total them and cannot compute over encrypted values.
9. Audit trail
Every authenticated request that changes something, and every export or download, is written to an audit trail: who did what, in which organisation, to which object. Extra records cover things a request alone cannot say, such as who something was shared with or what was permanently deleted. Entries are scrubbed of anything resembling a secret before they are written, and your data rows are never written into the audit trail.
10. How it is deployed
- The database is never exposed to the internet. It sits on the internal network, and the firewall allows only administrative access and web traffic.
- Encryption in transit is terminated in front of the application.
- Secrets are generated per deployment and never leave the server. The build pipeline has no access to them.
- The database is backed up daily.
- The site sends a content security policy limiting what the application may load, along with HSTS, protection against content-type sniffing, a frame policy and a strict referrer policy.
11. Checked on every change
Security is not a one-time review here. Every change to the code base automatically runs a scan for secrets, a security regression suite covering the protections described above, the full test suite for the application and its interface, a check of dependencies for known high-severity problems, and a production build that must not contain development addresses. If any of those fail, the change does not ship.
What we do not claim
- We do not claim any certification or third-party penetration test. If we earn one, we will say so here.
- No browser-based product can stop a signed-in person from copying what they are allowed to see. The measures above are about who is allowed to see what, and about the system never being turned against itself.
Questions about any of this? Ask us. If something above is not true of your deployment, we would rather know.
Frequently asked questions
Is our data used to train AI models?
No. WeTa Analytics does not train AI models on customer data. You can also restrict what a model may see, or deploy the product inside your own network so nothing leaves it.
Can another customer see our data?
No. Every request is checked against what the caller is allowed to read: their own data, their organisation's data, or something explicitly shared with them. A request for data you may not read returns “not found”, so nobody can even confirm that another organisation's data exists.
Can WeTa Analytics run entirely inside our network?
Yes. WeTa Analytics is available on-premise, inside your own VPC or data centre. For databases that must stay private, the Data Bridge agent sits next to the database and dials out to WeTa Analytics, so you never open an inbound port.
Does the AI ever make up a number?
No. The AI never produces a figure. It produces a plan, the plan is verified against what your data can express, and the database computes the number. A question the data cannot answer is refused rather than estimated.
Do you have ISO 27001 or SOC 2 certification?
We do not claim any certification or third-party penetration test. The measures described here are what the product does, and we are happy to answer a security questionnaire or walk your IT team through any of it.
Reviewing WeTa Analytics with your IT team?
Book a walkthrough and we will answer your security questions against your own requirements.
Request a Demo Download the WeTa Analytics brochure