Embedded Analytics Security: RLS, Tenant Isolation & Tokens

Embedded analytics security is harder than securing an internal BI dashboard because the users viewing the data are often your customers, not your employees.

A secure implementation has to answer several questions at once:

• Who is the user
• Which tenant do they belong to
• Which dashboards can they open
• Which rows and datasets can they query
• Which actions are they allowed to perform
• What happens if a token is copied, modified or expires

A platform can support SSO and still expose the wrong customer's data if authorization is configured incorrectly.

That is why embedded analytics security should be evaluated as a system rather than a checklist of acronyms.

Key takeaways

A secure embedded analytics setup should:

• authenticate users through a trusted identity layer
• derive tenant context from server-side application state
• enforce row-level and resource-level permissions below the UI
• issue short-lived, least-privilege credentials to the browser
• preserve the same authorization boundary across dashboards, exports, APIs, self-service analytics and AI.

If you need the broader product context first, start with what embedded analytics is and our guide to implementing multi-tenant analytics.

Embedded analytics security at a glance

A production setup usually needs several layers working together.

Security layer	What it controls
Authentication	Who the user is
Authorization	Which analytics resources the user can access
Tenant isolation	Which customer's data the user can see
Row-level security	Which rows inside shared datasets are visible
Feature permissions	Which actions the user can perform
Token security	How temporary access is delegated
Infrastructure security	Where data is processed and how systems connect
Auditability	How access and changes can be reviewed

The exact implementation differs between vendors.

Power BI Embedded, for example, supports row-level security, object-level security and workspace-based isolation. Microsoft recommends different isolation models depending on the number and size of customers.

Luzmo uses temporary Embed Authorization tokens to grant application users access to specific dashboards, datasets and features while applying tenant-specific data rules.

The architecture changes, but the evaluation questions stay similar.

Secure every path to the data

Tenant isolation should survive every route a user can take to reach analytics data:

Dashboard → API → Export → Background job → AI query

If one path uses a weaker authorization context, the application no longer has consistent tenant isolation. This is why embedded analytics security should be enforced at query time and at the authorization layer rather than only in the dashboard UI.

1. Separate authentication from analytics authorization

The first security question is: how does the analytics platform know who the user is?

The second is: how does it decide what that user may access?

Those are separate concerns.

Your own SaaS application may authenticate the user through SSO, OAuth, OpenID Connect or another identity system. The analytics platform then needs enough trusted context to enforce the correct permissions.

A user being logged into your product does not automatically mean they should be able to query every dashboard or dataset connected to it.

The safest architecture keeps privileged credentials on the server.

Luzmo's Embed Authorization documentation is explicit about this. An Organization Owner's API key-token pair should be used server-side to create a short-lived Embed Authorization token for the end user. The long-lived API credentials should never be exposed in the browser.

That is an important security boundary. If a browser receives only a temporary token with limited rights, the user cannot simply modify the frontend request and grant themselves broader resource access.

Checklist

Ask the vendor:

• Where are privileged credentials stored
• Is end-user access delegated through short-lived tokens
• Can those tokens be scoped to specific resources
• Can permissions be changed without exposing administrative credentials
• What happens when a token expires
• Can tokens be revoked or invalidated

A solution that requires a master API secret in frontend JavaScript should be treated as a serious red flag.

2. Treat tenant isolation as a first-class security requirement

Multi-tenant SaaS creates a simple security rule: Customer A must never see Customer B's data.

How that rule is implemented depends on the data architecture. Common models include:

• one shared dataset with tenant-level filtering
• one dataset per customer
• separate schemas
• separate databases
• separate analytics workspaces or semantic models.

None is automatically correct for every SaaS product.

Microsoft, for example, documents both RLS-based isolation and workspace-based isolation for Power BI Embedded. Dynamic RLS can work for shared models, while workspace-based isolation can give larger customers separate semantic models and reports.

Luzmo also supports several multi-tenant patterns. Its multi-tenant analytics guidance describes dynamic tenant filtering for shared datasets, while its developer documentation supports connection overrides when different tenants use different data sources.

This distinction matters because "supports multi-tenancy" is too vague to evaluate.

A buyer should ask: how does your platform map my tenant identifier to the data that user is allowed to query?

If the vendor cannot explain that clearly, keep digging.

3. Use row-level security for shared data models

Row-level security restricts which records a user can access within a shared dataset.

Imagine a table containing data for 200 customers:

tenant_id	revenue	orders
acme	125000	480
northwind	89000	312
globex	201000	670

A user from Acme should query only rows associated with tenant_id = acme.

The important part is where that restriction is enforced. In a secure design, tenant restrictions should be applied at query time or in the semantic and data access layer rather than trusted to presentation-layer controls.

A visible dashboard filter is not the same thing as row-level security. If a customer can remove a frontend filter and retrieve another tenant's rows, the implementation is not secure.

Power BI RLS applies security rules to the semantic model. Microsoft explicitly separates RLS, which filters rows, from object-level security, which hides tables or columns.

Luzmo applies data filters as part of the Embed Authorization context. Its authorization examples show how server-side filters can be attached to an embed token so tenant-specific data restrictions travel with the authorization context.

That is the level at which a security review should happen: query-layer security and query-time enforcement, not merely what the dashboard happens to display.

Do not rely on UI filters for security

A dashboard filter answers: what does this user want to look at?

A security filter answers: what is this user allowed to look at?

Those are different questions. Users may be allowed to change the first one. They should not be able to bypass the second.

4. Scope tokens to the minimum required access

Tokens should grant the least privilege required for the user to perform their task.

A viewer who only needs one dashboard should not receive permissions to modify datasets. A customer who can create their own dashboard may need broader query rights, but still should not automatically gain administrative access.

Luzmo supports several access levels for embed users, including read, use, modify and own rights. Its current Embed Authorization documentation also defines viewer, designer and owner roles for embedded experiences.

That gives product teams a way to separate viewing analytics from creating analytics from administering analytics resources. The same principle should be tested regardless of vendor.

Security review questions

Ask:

• Can viewers query arbitrary datasets
• Can self-service users modify shared resources
• Can one role duplicate or share dashboards
• Can permissions be scoped to collections or individual datasets
• Can an embed token grant more access than the server-side credential that created it

The safest default is to grant only the permissions the current workflow requires.

5. Keep tenant context server-side

A common mistake in embedded systems is trusting tenant identifiers supplied only by the browser. For example:

If changing that value to tenant_id=globex is enough to retrieve Globex data, the system has no real tenant isolation.

Tenant context should be derived from trusted application identity and passed into the analytics authorization layer from the server.

Luzmo's Embed Authorization model supports a suborganization value that maps users to a customer or tenant. The same authorization request can also carry parameter overrides or filters used to restrict multi-tenant data. This is a stronger model than letting the browser decide which tenant it belongs to.

The rule is simple: the client can request a view. The server should decide the security context.

For a concrete implementation pattern, our guide to embedding dashboards in a SaaS product shows how tenant-aware authorization fits into the wider embedding flow.

6. Understand how embedded filters are combined

Security filters often become complicated once products support:

• dashboard filters
• user-specific filters
• group filters
• tenant filters
• parameters
• drilldowns
• saved views.

The important question is what happens when they interact.

Luzmo's current authorization documentation explains that several filter sources can be merged when an embed token queries a dataset. Authorization-token filters and dashboard interactivity filters are combined, while user and group-level filters follow defined precedence rules.

This is the kind of detail worth testing during implementation. Security bugs often appear not because RLS is completely missing, but because two filtering systems interact in an unexpected way.

A good test suite should include:

• tenant filter + dashboard filter
• tenant filter + saved view
• tenant filter + export
• tenant filter + self-service query
• tenant filter + AI query
• group permission + direct user permission.

Do not test only the default dashboard state.

7. Test exports, alerts and background jobs separately

A dashboard may enforce permissions correctly while an export or scheduled task uses a different security context. That is easy to overlook.

If customers can export PDF files, download images, receive scheduled reports, create alerts or run asynchronous queries, those workflows should be tested with the same tenant and access rules as the interactive dashboard.

Luzmo's developer documentation specifically notes that periodically triggered features such as exports and alerts can use access associated with the embed user, which is why consistent access configuration matters.

This is exactly the sort of edge case a serious POC should include. A secure dashboard is not enough if a scheduled export can cross tenant boundaries.

8. Do not confuse RLS with object-level security

RLS answers: which rows can the user see?

Object-level security answers: which tables, columns or model objects can the user discover at all?

This distinction is particularly relevant when customers receive self-service analytics. A user might be allowed to see the rows belonging to their company but still should not necessarily see every field in the semantic model.

Microsoft explicitly distinguishes these mechanisms: RLS filters records, while OLS can hide tables or columns.

For vendor evaluation, ask:

• Can sensitive columns be hidden
• Can self-service users inspect the schema
• Can API or AI interfaces expose fields that the dashboard does not display
• Are measures and metadata governed separately from rows

This becomes increasingly important as embedded analytics shifts from fixed dashboards toward self-service exploration.

9. Apply the same security boundary to AI analytics

AI introduces a new interface, but it should not introduce a new permission model.

If an AI assistant converts natural language into SQL, it should not be responsible for deciding which tenant's rows the user may query. That decision should already be enforced underneath the model.

AWS documented this explicitly in a June 2026 write-up of a production multi-tenant LLM analytics system. Its architecture separated cryptographic request signing, semantic validation and programmatic data isolation into independent layers, rather than trusting the LLM to remember security rules, so that a compromised or manipulated model still could not cross a tenant boundary.

That is a strong general principle: never make the language model your security boundary.

The AI can interpret the question. A deterministic authorization layer should still decide what data can be returned.

Luzmo's embedding architecture uses the same temporary authorization model for dashboards, Flex widgets and Luzmo IQ components.

That is an important thing to verify during an AI analytics POC: does the assistant inherit the same dataset and tenant restrictions as the dashboard?

10. Validate security with negative tests

Security testing should not only prove that authorized access works. It should prove that unauthorized access fails.

Test	Expected result
User A requests User B's tenant data	Denied / no rows
Expired token reused	Denied
Token modified client-side	Denied
Viewer attempts dataset modification	Denied
User opens dashboard without dataset access	Denied
Browser changes tenant parameter	Original server-side restriction still applies
Export requests another tenant's data	Denied
AI asks for another customer's records	Denied
Direct API request bypasses dashboard UI	Same authorization still enforced
Tenant B requests a result previously cached for Tenant A	No cross-tenant data returned

These tests matter more than a vendor presentation about "enterprise-grade security." Security controls should survive deliberate misuse.

11. Check what happens when permissions change

Security is not static. Users leave companies. Customers change plans. Admins revoke access. Roles change.

Ask how quickly these changes propagate. A useful authorization design should let the application generate a new restricted context without waiting for long-lived client credentials to expire days later.

Short-lived authorization tokens help here because the application can recreate the user's access context frequently. Luzmo documents Embed Authorization tokens as temporary credentials that are typically requested on each page visit. The authorization API supports an explicit expiry and recommends short-lived tokens; if no expiry is supplied, the current default is 24 hours.

That does not remove the need for revocation and access-management processes, but it reduces the value of a leaked frontend credential compared with exposing a long-lived organization API secret.

12. Check caching and tenant boundaries

Caching can create a separate cross-tenant risk if cached analytics results are not scoped to the correct authorization or tenant context.

Imagine two users requesting the same dashboard. If the system reuses a cached query result without considering which tenant originally generated it, Tenant B could potentially receive data that was computed for Tenant A.

A secure implementation should make sure cached results follow the same tenant and permission rules as live queries.

Questions to ask

• Does tenant identity form part of the cache context
• Can cached query results be shared across tenants
• What happens when permissions change before a cached result expires
• Do dashboards, exports, background jobs and AI queries follow the same cache isolation rules
• Can a user ever receive a cached result produced under a broader permission set

Caching is a performance feature. It should never become a shortcut around query-time authorization.

13. Review platform security separately from data authorization

Tenant isolation is only one part of the procurement conversation. The vendor itself should also be reviewed for:

• security attestations
• encryption
• hosting regions
• incident response
• sub-processors
• audit logs
• backup and disaster recovery
• contractual data protection.

Luzmo's current security and compliance page lists SOC 2 Type II, GDPR support, EU and US data-residency options and multi-tenant isolation among its security and procurement controls.

Procurement and regulatory detail deserves its own treatment, though. This page stays focused on application-level security and tenant-safe access.

A practical embedded analytics security checklist

Before shipping, confirm all of the following.

Identity

• Users authenticate through a trusted identity flow.
• Privileged API credentials remain server-side.
• Temporary end-user credentials can expire.
• Revoked users cannot continue using analytics.

Resource authorization

• Users receive only required dashboard and dataset access.
• Viewer and creator permissions are separated.
• Administrative actions are not exposed to normal customers.
• API access follows the same resource rules as the UI.

Tenant isolation

• Tenant identity comes from trusted application context.
• Changing a URL or frontend parameter cannot switch tenants.
• Shared datasets enforce tenant filters server-side.
• Separate-database tenants route to the correct source.

Data access

• Row-level restrictions cannot be removed through dashboard controls.
• Sensitive tables or fields can be protected when needed.
• Saved views do not weaken security rules.
• Direct API queries respect the same restrictions.

Non-dashboard workflows

• Exports respect tenant restrictions.
• Scheduled reports respect permissions.
• Alerts run in the correct user context.
• AI queries inherit the same access policy.
• Cached results remain tenant-scoped and permission-aware.

Testing

• Unauthorized tenant access is explicitly tested.
• Expired and modified tokens are tested.
• Largest and most privileged roles are tested separately.
• Permission changes and revocation are tested.

If the vendor cannot demonstrate these controls in a realistic POC, compliance badges alone should not close the security question.

How Luzmo handles embedded analytics security

Luzmo's current embedded security architecture is centered around temporary Embed Authorization tokens generated server-side.

The server uses an Organization Owner API key-token pair to create a short-lived authorization context for the application user. The resulting embed credentials can grant access to specific dashboards and datasets, assign roles, apply tenant-specific filters and restrict features.

For multi-tenant deployments, Luzmo supports more than one data model. A shared dataset can use parameterized row-level filtering so each tenant sees only its own records. Products with separate data sources per tenant can use connection overrides to point embedded analytics toward the correct customer source.

The same authorization system is used across embedded dashboards, the dashboard editor, Flex components and Luzmo IQ, which are all part of Luzmo's embedded analytics platform.

Luzmo also positions row-level security, role-based permissions, multi-tenant support and query optimization and caching as part of its embedded analytics architecture. During implementation, those controls should still be validated together so that performance features never weaken tenant-aware authorization.

That matters because the security boundary should not disappear when users move from a fixed dashboard to self-service or AI analytics.

Luzmo also documents access levels for dashboards and datasets and allows feature-level permissions to be changed for embedded users.

From an implementation perspective, the most important rule in the documentation is also the simplest: never expose the Organization API key and token client-side.

15 questions to ask an embedded analytics vendor about security

1. How do you separate authentication from analytics authorization
2. Where are privileged API credentials stored
3. Are end-user tokens short-lived
4. Can tokens be scoped to specific dashboards and datasets
5. How is tenant identity passed into the analytics layer
6. How do you enforce row-level security
7. Can users remove or override tenant filters
8. Can different tenants use different databases or connections
9. Can access differ between viewers and dashboard creators
10. How are exports and scheduled reports authorized
11. Does self-service analytics use the same permissions
12. Does AI inherit the same row-level restrictions
13. Can sensitive columns or model objects be hidden
14. How are expired or revoked credentials handled
15. Can we test cross-tenant access attempts during the POC

A vendor should be able to answer these questions with architecture and documentation, not only with a security badge.

Quick answer: what makes embedded analytics secure?

Embedded analytics is secure when authentication, resource authorization, tenant isolation and data-level permissions are enforced independently of the dashboard UI. The browser should receive only scoped, temporary credentials, while trusted server-side context determines the user's tenant and allowed resources. Query-time enforcement should preserve the same restrictions across dashboards, APIs, exports, scheduled jobs, caches, self-service analytics and AI.

The bottom line

Embedded analytics security is fundamentally about context.

The platform needs to know who the user is, which customer they belong to, which resources they can access and which records they are allowed to query.

SSO solves only the first part.

A secure customer-facing analytics setup also needs scoped authorization, tenant isolation, row-level controls and safe temporary credentials. Those rules should continue to apply when users export reports, build their own dashboards or ask an AI assistant questions.

The best test is not "can Customer A see their dashboard?" It is: "can Customer A find any path, through the UI, API, export or AI, to Customer B's data?"

The correct answer needs to be no.