Security & data protection

Row-level security for every Power BI client portal

How every client's data stays isolated, encrypted, and auditable — enforced server-side, not just hidden in the UI.

Row-level security by design

Every embed token is bound to one RLS role. Queries are filtered server-side before a single row reaches the client — the client app never sees, and can never request, another role's data.

Tenant isolation

Company/BU and tenant boundaries are enforced at the data layer — one client's data is never mixed into another's response, even under concurrent load.

Encrypted in transit

All traffic is served over HTTPS/TLS. Custom domains get managed SSL certificates automatically — no manual certificate setup on your end.

Opaque, revocable tokens

Tokens carry no embedded permissions of their own — they're opaque references resolved server-side. Revoking one invalidates it immediately, with no residual access.

Full audit trail

Logins, exports, and views are logged for every portal — ready for your next compliance review, without extra setup.

Responsible disclosure

Found a security issue? Reach us any time at analytics@embedinsight.com — we aim to respond within 1 business day.

EmbedInsight is currently in early access and has not yet completed a formal SOC 2 audit. If that's a hard requirement for your team, let us know and we'll factor it into the roadmap.

How row-level security actually works here

When you generate a client token in EmbedInsight, that token is bound to exactly one RLS role inside your Power BI dataset. When a client opens their portal, the token resolves server-side to that role — the Power BI query itself is filtered before any data leaves the workspace, the same way USERPRINCIPALNAME()-based RLS works natively in Power BI, just with an opaque token standing in for a real Power BI identity.

This means a client can never widen their own access by editing a URL, inspecting the browser's network tab, or reusing another client's link — because there's nothing client-side to edit. The permission boundary lives in the token-to-role binding on the server, not in anything shipped to the browser.

For agencies and partners managing multiple client accounts, the same isolation extends one level up: each tenant's data is scoped independently, so a portal built for one client can never accidentally surface another client's reports, even if both are managed from the same EmbedInsight account.

See it enforced, not just described

Spin up a portal with your own workspace and RLS roles in the free trial.

Start free trial