Multi-tenancy is efficient: one application serves many customers from shared infrastructure, which keeps costs and maintenance down. But the first concern anyone raises about it is security — and rightly so. If you're embedding analytics for your customers, multi-tenant security is the part you cannot afford to get wrong.
This guide focuses on that security question specifically. (For the broader concept, see what multi-tenant analytics is; for the database side, see single-tenant vs multi-tenant databases.)
What is multi-tenant security?
Multi-tenant security is the set of controls that protect each tenant's data in a shared system, so no tenant can ever access or see another tenant's data. The defining trait of multi-tenancy is that customers are logically isolated from one another even though they're physically sharing the same application and often the same database. Multi-tenant security is what makes that logical isolation reliable rather than a hopeful assumption.
Why multi-tenant security is the central concern for embedded analytics
When you embed analytics in a product used by dozens or hundreds of customers, you're giving many organizations access to the same application and often the same datastore. That raises the possibility — by malice or by accident — of one customer seeing data that belongs to another. In analytics, that data is exactly the sensitive material customers care about most: their usage, their revenue, their operations. A single isolation failure isn't a bug; it's a data breach that can expose many customers at once. That's why isolation has to be designed in, not bolted on.
The real multi-tenant security risks
The risks worth focusing on for embedded analytics are concrete:
- Isolation failure. The mechanism meant to separate tenants fails, and one tenant reaches another's data. This is the headline risk.
- Bypassable filtering. Isolation enforced only in the user interface — hiding rows in the front end while the query still returns everything — can be defeated by calling the API directly or editing a request.
- Over-broad access and roles. Permissions that are too coarse let users see more than they should within or across tenants.
- Credential and insider exposure. A vendor that holds credentials to your data, or an over-privileged insider, expands the blast radius if anything is compromised.
- Breach blast radius. When your analytics vendor stores or routes your data through their cloud, a breach of the vendor can become a breach of your customers — a self-hosted model keeps that surface on your own infrastructure.
How tenant data isolation should be enforced
Good multi-tenant security is layered. Authentication confirms who a user is, access control and roles define what they're allowed to reach, and data-level security scopes every query to the right tenant. The decisive question is where that last layer is enforced — because that determines whether it can be bypassed.
| Where isolation is enforced | How it works | Can it be bypassed? |
|---|---|---|
| User interface / front end | Rows are hidden in the UI; the query still returns all data | Yes — via direct API calls or request manipulation |
| Application layer | App code adds tenant filters around each query | Sometimes — one missed code path leaks data |
| Query level (data-level security) | Tenant constraint injected into the SQL at execution | No — the database only returns that tenant's rows |
The takeaway: never rely on UI-only filtering for isolation, prefer enforcement at the query level, and treat self-hosting as a way to shrink the breach surface.
How Yurbi enforces multi-tenant security
Yurbi supports both multi-tenant and single-tenant architectures, and enforces isolation through a four-layer model: authentication, access control, roles, and App Shield data-level security.
- Tenant Mode gives each tenant complete isolation — users see only the data, reports, and users contained within their own tenant, even when everything is stored centrally in one multi-tenant database.
- App Shield provides data-level security set once and enforced everywhere: it injects the tenant's constraints directly into the SQL query at execution time, so isolation holds on every query and can't be bypassed from the front end.
- Dynamic data sources support both a shared multi-tenant database and a database per tenant. A single Yurbi server can serve many isolated single-tenant environments by giving each customer's database its own connection, so you don't need a separate server per tenant.
- Self-hosted. Yurbi runs inside your infrastructure and your data never passes through our servers, which keeps the breach surface on your side.
It's all available at flat, published pricing from $10,000/year. For the full picture, see Yurbi's security model and embedded analytics for SaaS.
Frequently asked questions
What is multi-tenant security?
Multi-tenant security is the set of controls that protect each tenant's data in a shared system, so no tenant can access another's. Customers are logically isolated even though they share the same application and often the same database, and multi-tenant security is what makes that isolation reliable.
What is the biggest multi-tenant security risk?
Isolation failure — one tenant reaching another's data — because a single leak can expose many customers at once. In embedded analytics, the common cause is isolation enforced only in the UI or application layer, which can be bypassed. Enforcing it at the query level removes that risk.
How is tenant data isolated in embedded analytics?
Through layered controls: authentication, access control, roles, and data-level security that scopes every query to the tenant. The strongest approach injects the tenant constraint into the SQL at execution, so the database only ever returns that tenant's rows.
Should tenant isolation be enforced at the query level or the application level?
At the query level. Application-layer filtering depends on every code path applying the filter, and one missed path leaks data. Query-level (data-level) security enforces the constraint in the database on every query, so it can't be bypassed. UI-only filtering should never be relied on for isolation.
How does Yurbi secure multi-tenant data?
With a four-layer model — authentication, access control, roles, and App Shield data-level security. Tenant Mode gives each tenant complete isolation, and App Shield injects tenant constraints into the SQL at execution so isolation can't be bypassed. Dynamic data sources support shared or per-tenant databases, and Yurbi is self-hosted, so data never leaves your infrastructure. Pricing is flat from $10,000/year.
Securing embedded analytics for your customers? See how Yurbi enforces data-level security and powers multi-tenant embedded analytics.
Stop rebuilding your reporting layer.
Embed Yurbi into your product and ship analytics to your customers in weeks — not quarters. Self-hosted, white-labeled, flat annual pricing.
Download Free Trial See a Live Demo
