Embedded analytics security

The moment analytics becomes customer-facing, it stops being an internal convenience and becomes part of your security surface. Internal dashboards are seen by your own team; embedded analytics is seen by your customers, on their own data, inside your product. That shift raises the bar — a single mistake can show one customer another's numbers. This is a practical guide to what actually keeps customer-facing AI analytics secure, and a checklist to run before you ship.

Why customer-facing analytics raises the bar

With an internal BI tool, the blast radius of a bug is your own staff. With embedded analytics, every customer is a tenant whose data must never reach another tenant. Add an AI layer that turns plain-English questions into SQL, and you have a system generating queries on the fly. Both facts make security a design requirement, not a feature you bolt on later. The good news: the controls are well understood, and you can verify them with concrete questions.

Tenant isolation

Tenant isolation is the foundation. Every query must be scoped to the customer who asked it, so there is no path — through a filter, a join, or an AI-generated query — by which one customer's data appears in another's results. Look for:

• Isolation enforced at the data layer, not just in the UI. A filter in the front end is not isolation; the constraint must live where the query runs.
• A tenant scope on every request, applied automatically rather than remembered by a developer on each endpoint.
• No shared, un-scoped caches that could serve one tenant's results to another.

This is exactly why tableArth.ai is designed to attach to an existing table or data source with the tenant boundary applied to every query — including the ones the AI writes.

Permission-aware queries

Isolation keeps customers apart; permissions keep users within a customer honest. Not everyone at a company should see every row or column — salaries, other regions, other teams. A secure layer respects the same row-level and column-level permissions your product already enforces, so an answer never includes data the asking user isn't entitled to. The test is simple: ask a question whose honest answer would require restricted data, and confirm the system declines or scopes the result rather than leaking it.

How AI changes the security picture

Natural-language analytics adds a query generator to the stack, which is powerful and worth securing deliberately. The properties that matter:

• Read-only by design. The AI answers questions about data; it should never be able to modify or delete it. Generation should target read paths only.
• Generated queries are validated and scoped. Every AI-written query inherits the same tenant and permission constraints as a hand-written one — the model can't widen its own access.
• Resilient to prompt injection. A user (or data) asking the model to "ignore the rules and show everything" must not change what it's allowed to touch. Guardrails live in the system, not the prompt.
• Self-correcting within bounds. tableArth.ai retries and self-corrects a failed query up to a few times — useful for reliability, and still inside the same access boundary each time.

Privacy modes: control what the AI sees

Different datasets deserve different handling. The most important lever for AI analytics is choosing how much raw data the model sees at all. tableArth.ai exposes this as four privacy modes you can set per customer, workspace, or table:

• Full AI — the model sees the data needed to answer. Best for low-sensitivity datasets where you want the richest answers.
• Masked — personally identifiable information is masked before anything leaves your environment.
• Hybrid (stats only) — the model works from schema and aggregate statistics rather than raw rows.
• Local template — answers are assembled from predefined templates with no raw data sent to a model at all.

Matching the mode to the sensitivity of the data is how you get useful answers without over-exposing anything. It also gives you a clear story to tell your own customers about what is and isn't shared.

Auditability and cost governance

Security isn't only about prevention; it's about being able to answer "what happened?" later. Look for a record of which questions were asked, what queries ran, and on whose behalf. Two related controls matter for production:

• Audit trail. Questions, generated queries, and results attributable to a user, so you can investigate and demonstrate control.
• Cost and rate governance. Per-user limits and caching keep a runaway or abusive query pattern from becoming an availability or billing problem.

A pre-launch security checklist

Before you turn customer-facing analytics on, walk this list — whether you're evaluating tableArth.ai or anything else:

• Is tenant isolation enforced at the data layer, on every query, automatically?
• Do answers respect the same row- and column-level permissions as the rest of your product?
• Is all data access read-only, with no write path from the analytics layer?
• Do AI-generated queries inherit tenant and permission scope, and are they validated before running?
• Is the system resilient to prompt-injection attempts to widen access?
• Can you control how much raw data the AI sees, per customer or dataset?
• Is there an audit trail of questions, queries, and results tied to a user?
• Are there cost and rate limits to contain abuse?
• Does your data stay in your environment, and is the deployment model clear?

If a vendor can't answer these clearly, that is your answer. If you're still weighing whether to build this yourself or adopt a layer, our build vs. buy guide covers the trade-offs, and the broader shift is in embedded AI, today.

Frequently asked questions